Create a Localyzer only project

Data Source Settings

For this example, we are using the GitHub repository. Other Data Source types are similar. Enter the credentials, the repository URL, and the branch that is being used for the project.

Project Name

The values on this page are initially filled in based on the repository and can be changed at creation or later while editing.

1. Set the Group Name. Often, this is the same as the Company Name that Command Center was installed with. But it can be almost anything. There is a restriction that it must be the same case. For example, if the Group Name for other projects is ACME (all caps), then another project cannot be created with a group name of 'acme' or 'Acme'.
2. Set the Project Name. Project name must be one word and cannot contain any of the following characters: < > : " * / | ? . % --
3. Set the Module Name. This is defaulted to the branch that the project is using.
4. Tags - tags can be selected from a drop-down list of already created tags or new ones can be created by selecting the plus sign. Projects can have a number of tags associated with them.
5. Select the Project Run Type. A project can be a Globalyzer project, a Localyzer project or both. By default these are unselected. The user cannot select Next until at least one option is selected.

Select Next

Accessors

Select the Users and Teams that will have access to this project. Also verify the users that will receive email notifications for this project.

Click Next

Translation Connections and Locales

Select a Machine Translation, an LLM, or a Translation Management System that will be translating the resource files. These need to have been created before attempting to create a Localyzer project.

Select the source locale and the target locales into which the strings will be translated. Optionally,

• The pseudo-locale, by default 'eo' (Esperanto). It allows to check if strings have been externalized, the layout for expanded strings, etc.
• The trackback locale, by default 'ia' (Interlingua). This works together with LocalyzerQA to determine what exact strings to modify if necessary
• The InContext locale, by default 'la' (Latin). This works together with the InContext Chrome plugin to easily capture context.

Click Next

Resource File Configuration

Select the Resource File Types that are to be translated. Verify that the file pattern is correct.

For example if the base resource file is resource.properties, then the file pattern should be file.properties -> file_fr_FR.properties.

If the base resource file is resource_en_US.properties then the file pattern should be file_en_US.properties -> file_fr_FR.properties.

In our example, the files are JSON files and are under directories named according to the locale, as in en-US or fr-FR.

• Select Use XML parser file or Use custom transform scripts if there are already appropriate files defined in the Setting -> System Files -> XML Parser Files or Transform Folders

Using Custom Resource File Types

In the event that the file types and patterns in your repository don’t match any of the existing options, custom resource types can be configured. To add a custom resource file type, select the Add resource file format button and choose the custom option. Once added, a new row with many options to customize will appear

File Name Pattern

In this following section, the codes used in the file name pattern are based on:

• l is for language, as in de or fr or zh
• c is for country, as in DE or FR or hant
• v is for variant, as in tw

The File name pattern determines how Localyzer parses locale information from the repository filename. Both the file name pattern and the file location pattern can be used together, but only one or the other is required. The pattern must contain l, c, and v, or LCID. The pattern cannot contain /, \\, or any letter other than l, c, or v, or the continuous string LCID. The pattern may contain * as a wildcard to indicate “the rest of the file name,” but it must be the very first character of the pattern. Below are some example file name patterns with a hypothetical properties file that they could map to:

*-l_c-v -> file1-zh_hant-tw.properties

*_l-c-v -> file1_zh-hant-tw.properties

l_c-v -> zh_hant-tw.properties

Additionally under the file name pattern column, you have the option to use the pattern on target locale files only, or to also apply the pattern when searching for the base locale files.

• With Targets only selected, Localyzer will use any non-target file that matches the include and exclude patterns as a base file. This allows for example file1.properties to be used as a base file even when it has nothing in the name to indicate the locale.
• If All locales is selected, then the base target files must also obey the locale pattern; for example if your base locale is en_US, then your base target files would have to look something like file1-en_US.properties, depending on how the file name pattern is configured.

File Location Pattern

The file location pattern determines how Localyzer parses locale information from the file directories. Both the file name pattern and the file location pattern can be used together, but only one or the other is required. The pattern must contain l, c, and v, or LCID. The pattern cannot contain \\. Below are some example file name patterns and how they would map to a directory in which the resource files would be located:

*-l_c-v -> values-zh_hant-tw/

*_l-c-v/some/directory -> values_zh-hant-tw/some/directory/

l_c-v/*/abc -> zh_hant-tw/*/abc/

Additionally under the file location pattern column, you have the option to use the pattern on target locale files only, or to also apply the pattern when searching for the base locale files.

• With Targets only selected, Localyzer will use any non-target file that matches the include and exclude patterns as a base file. This allows, for example values/ to be used as a directory for base files even when it has nothing in the name to indicate the locale.
• If All locales is selected, then the directories that the base target files must also obey the locale pattern; for example if your base locale is en_US, then your base target files would have to be located in a directory something like values-en_US/, depending on how the file location pattern is configured.

Extension

The extension is the file extension not including the period. For example, the extension of a resource file file1.properties would be properties.

Parser

The parser type can be chosen from any of the parser types built into Localyzer. XML files can be parsed in many different ways, and when the xml parser type is chosen, Localyzer will determine which xml parser to use based on the file extension.

Using an XML Parser File

If a custom xml parser is needed, it can be added to the system as a Settings -> System Files -> XML Parser File. Then when configuring your resource file type, select the XML parser type. Below the resource file configurations, select Use XML parser file and then choose the corresponding system file.

Encoding

The file encoding by which to read and write the files. For example: UTF-8

UTF-8 is the most common encoding value. Select UTF-8 for the encoding unless instructed otherwise.

Parameters

The Parameters column is a regex pattern that defines how Localyzer parses parameters out of the messages within files. Below are the parameters patterns used in some of the default resource types as examples:

• js - \{\d+\}|%[ds]
• json - \{\w+\}|%[ds]
• msg - %\d+%|%[ds]
• po - %\d*[ds]|%\d+
• properties - \{\w+\}|%[ds]
• rc - %\d+
• strings - %d|%s|%\d+\$s|%\d+\$d|%\{\w+\}
• xml - %[ds]|%\d+\$[ds]|%\{\w+\}

Include/Exclude/Reference Patterns

This is used to denote resource locations or to verify that other files are not mistaken for resource files. To remove a directory from either the Include or Exclude patterns, hover over the respective row and select the red trash icon

For example:

If all the resource files are under a folder called locales then the Include Patterns would be **/locales/** If there is a file such as config.json which is not a resource file, then the Exclude Patterns would look like **/config.json

Reference files are specific to Trados Enterprise and provide information or instruction about the translation steps.

Custom Transform Scripts

Custom Transform Scripts are added to the system in Settings -> System Files -> Custom Scripts.

Special On-Boarding

• DITA Project Configuration

Figma to Dev

If a repository file will be used to receive key/value pairs from a Localyzer Figma project, select which Figma project to use and what source file is the destination for the source strings. If the Figma project has translations, the corresponding target files will be generated as well, based on the on-boarding.

• Note: For Localyzer Figma project creation, see: Create_a_Figma_project

In this example, the source and target files more.json will have key/value pairs added from the Localyzer Figma project.

Please follow the recommendations as to when to setup the Figma2Dev configuration and when to switch to a new destination (generated) developer file:

• Figma_to_Dev_Generation_Details#Recommendation

In terms of when development resource files are generated, on the source and target locales, please refer to

• Figma to Dev Generation Details

Click Next

Advanced Localyzer Settings

The default settings cover the majority of the cases. For special use cases, a number of options are available, including the following:

Localyzer Issue Detection

Selecting the Detect prep kit reasons and Detect informational reasons will report more Localyzer issues on the Localyzer report page.

Prep kit configuration

• Send changes only - By default this is set. After a file has been fully translated, then only the changes will be sent to translation.
• Send separate translation kits for each locale - this is unset. When prep kits to be translated are sent to a Translation Management System or Machine Translator, they are sent in one large zip package unless this value is set. Prep kits are returned individually.
• Replace post edit text directly in file - this is unset and will not change the translated files unless it is checked.
• Global tags (comma separated) - what is this?

Custom Git Commit Message All of these options allow the user to customize the Git Commit messages for various processes.

Schedule translations

Files can be scheduled to be sent to translation either every n days or every n weeks on a specific day. For example, below is a schedule to sent files to translation every 2 weeks on a Friday:

Click Next

Validation

The last step before creating the Localyzer project in Command Center allows the use to verify all is correct in the on-boarding. If anything needs to be changed, the user can click on the relevant step, for instance "Locales" to add a locale.

The list of source and target files, as specified by the configuration, is displayed.

If the validation steps shows the correct information, click Create to finalize the process and create the Localyzer project.

Run analyze as the next step and check the Localyzer tab.