1. Getting Started

Some General Assumptions

The base version of the app makes the assumption that localizable database data has been organized in the following way. Each base content table has a corresponding "Localized" table which stores localized string data and a culture code identifier. Even though this is the design we'll use in the setup example, the application can be customized to work with any Db table design.

See below for the example schema we'll be using to demonstrate how to use the application.

Simple Db Schema Design

Lets assume we have a Products table which contains two localizable fields, "ProductName" and "ProductDetails".

We would also have a Localized version of this data stored in a table such as below.

Lets assume our [dbo].[Products] table contains records for common tools.

Given the following SQL query, we can easily return the values for our products in any culture that is supported.

SELECT P.[ProductId] ,L.[ProductName] ,L.[ProductDetails] ,[InternalRefCode] FROM [LocalizationTest].[dbo].[Products] AS P INNER JOIN [dbo].[ProductsLocalized] AS L ON (P.ProductId = L.ProductId) WHERE L.CultureCode = 'fr-FR'

Which would give the following result

Configuration

There are several json configuration files in the DbLocalizer project root which will require editing before you can get up and running.

appSettings.Development.json

For the moment lets just change the ConnectionStrings and CorsOrigins values. However before you change the connection string, you will need to configure the _dbCredentials Dictionary in the DbCredentialsManager class, which can be found in the Entities/DAL directory. So that we don't expose the database username and password in the appSettings file, we store these values in the _dbCredentials Dictionary. These values will be injected when we build the Database objects later. We'll use the example included in the code.

private readonly Dictionary<string, DbCredentials> _dbCredentials = new Dictionary<string, DbCredentials>() { { "LocalizationTest", new DbCredentials() { Username = "TestUser", Password = "@MyTestPassword#"} } };

Now that you've specified the connectionstring name, username and password values in the DbCredentialsManager class, you can now update the appSettings.Development.json "ConnectionStrings" collection. Be sure to leave the string format placeholders, {0}{1}, in place of the user id and password values in your connection string.

"ConnectionStrings": { "LocalizationTest": "Server=localhost;Initial Catalog=LocalizationTest;User Id={0};Password={1};MultipleActiveResultSets=True;TrustServerCertificate=True" },

You can also specify the correct development URL for "CorsOrigins". The other settings we will cover later.

Cultures.json

Here you can add the cultures that you wish to support in your implementation. These cultures will be what are sent to the TMS specifying what languages you wish your content to be translated into.

Databases.json

Here we set preferences and properties that will be used to build a schema representation of your database. It is important not to change the schema of this file as it deserializes to the Database class in the Entities project. Lets look at each one.

• "Name": "LocalizationTest", // The name of your database
• "ConnectionStringName": "LocalizationTest", // This should map exactly to the name of your connection string in appSettings.Development.json
• "SourceLocale": "en-US", // The source language that will be sent to the TMS e.g "en-US"
• "LocalizedTableSuffix": "Localized", // The table suffix identifying a localized table. e.g. "ProductsLocalized"
• "TableExclusions": [] // An array of tables that should not be included in the export
• "ExportDataTypes": [] // The valid column data types that will be evaluated for exporting string data. All other columns will be ignored
• "ColumnExclusions": [] // Columns with valid data types that should not be evaluated during the export (Global - All Tables)
• TableLevelExclusions": {} // Object that contains more granular table level parameters
• "DbTable": [] // An array of tables within the TableLevelExclusions object
• "FullTableName": "[dbo].[Products]" // DbTable property that must contain the fully qualified table name plus schema value
• "ColumnExclusions": [] Table level columns with valid data types that should not be included in the export

smartlingSettings.json

The values required in this file will depend on how you have set up your Smartling account, however it's important not to change the schema of this file as it deserializes to Smartling classes within the Entities project. In particular the values within the "smartling": {} object should not be changed as these map directly to values in the export json file that will be sent to Smartling, allowing it to format the job correctly.

SecureKeysManager CLass

The final step is to set up securing the APIs. There is no log in facility in DbLocalizer so APIs are secured by the use of an App Key to authenticate and produce a valid Bearer Token using a JWTSecretKey value. The Bearer Token must be included with every request to APIs that require authorization.

In the SecurityController there is a commented out API called "GenerateKey" you can use to generate the required key values for the "SecureKeys" Dictionary in the SecureKeysManager class. You will need a new value for each entry e.g.

public static Dictionary<string, string> SecureKeys { get; set; } = new Dictionary<string, string>() { { "jwtSecretKey", "NFL+X6v46RV6zS/AOqDgO9YtyFmutcwtxklNah7YRWw=" }, { "appKey", "oG6kxiWrZoYHafEqvjCTd8apdQW/zTEmPGkpUIELwTs=" }, };

Once you have generated your keys, you should remove the "GenerateKey" API in the SecurityController before deploying to a hosted environment.

Getting The Token

Once you have your AppKey you can gain a valid Bearer Token by calling the "GetToken" API in the SecurityController and passing in "AppKeyValue" value. e.g.