Localyzer Settings

Edit Localyzer Settings

[Admin, Manager]

Click the 'Edit' button and scroll down to the Localyzer Settings section:

To switch TMS or MT connection, click and select a new connection from the Translation Connection pull down. The set of TMS or MT connections will be those currently configured. The locales with the same exact name will be kept from one Translation Connection to another. (See below Locale Settings)

Left hand side actions

• Validate project: This action will show which source files will be selected for translation and in what way they will be translated. Use this button to verify the Include/Exclude, Locales, Transforms are configured correctly.
• Duplicate project: This action will create a new project with all section configured by default using the settings of the current project. For instance, if a new branch of a project on project is necessary, change the module name and the branch. Idem if another repository has similar type of resource files formats, use the same TMS, and have similar locales.
• Clean up workspace: This will remove the files on disk cloned or updated from the data source, so that the next analysis will start with a brand new set of files from the data source.
• Delete project: This action will remove the project and associated files from the database and the file system.

Locale Settings

• Source Locale: The source locale file are those to be translated.
  • Repository locale code: The locale code of the files in the repository or data source. For US English, the typical configuration for JSON, resx, .properties is 'en' or 'en_US' as the Repository locale code, for instance if the files are in the form "messages_en.properties", "errors_en.properties", "alerts_en.properties" or if the files are under an 'en' directory as in "en/messages.json", "en/errors.json". In the case of an iOS structure, source files tend to be under a directory named 'Base.lproj', hence the screenshot above.
  • Locale name: the spelled out locale in English. This locale name should be the same for all TMS and MT connection so that when switching from one TMS or MT to another, the locales are kept.
  • TMS locale code (or MT locale code): The code used to identify the locale in the TMS or MT. By default, a TMS configuration or an MT configuration will have those preset. They can be changed in the TMS or MT configuration, they cannot be changed in a Localyzer project configuration.

• Pseudo-locale: This is a special locale. If this check box is check, the default pseudo-locale is 'eo' for Esperanto as this locale is accessible by most browser and is rarely used by end users, if ever. This is used to make sure the application has its user facing strings properly externalized into resource files, that the locale switch works correctly, that the layout of the application works in other locale, and that global character sets are showing properly (for instance, Korean or Chinese characters). See: https://lingoport.com/blog/what-is-pseudo-localization/

• Trackback Locale: This special locale is used in conjunction with LocalyzerQA to make linguistic corrections as seen in the running application. See: https://wiki.lingoport.com/LocalyzerQA

• Context Locale: This special locale is used in conjunction with InContext. In order to capture context from a running Web application using the Chrome extension, the application must be running in that locale. The TMS set up for a project must have InContext enable. In the screen shot above, the Translation connection is not set up with InContext, so the Context Locale checkbox does not show. See: https://wiki.lingoport.com/InContext_Capture_Users_Guide

The actual translation target locales are set below the special locales.

Add or replace the target locales using those set on another project, using the drop down.

Add one target locale at a time using the "+ Add target locale" button and select from the list of available locales for this translation connection.

Resource File Formats

This section specified the format of the resource files. When clicking "+ Add resource file format", a drop down shows the standard file formats (resx, iOS, Android, .properties, JSON, etc) and a custom file format for those non standard formats.

A list of default standard naming convention for each standard file format is available. The parameters regular expression indicate what parameters are expected. Parameters must be conserved during translation. For instance, if the regular expression specifies that {user} is a parameter, a string such as "The account for {user} has been deleted" must keep {user} untranslated, as in "Le compte {user} a été supprimé".

Only one format per file type is allowed. If more formats are used in the same workspace, then more projects must be created. For instance, if some JSON files are in the form 'locales/en.json' and 'locales/fr.json', and others are in the form 'en-US/messages.json' and 'fr-FR/message.json', then two separate projects are needed.

For XML files, an XML parser files must be set. Those files are configured in the General Settings > System Files.

For non-standard resource files, a custom transform is necessary. See: https://github.com/lingoport-public/LocWorld44 ; Transforms are configured in the General Settings > System files.

Include/Exclude - Reference material

This section specifies which directory or source files should and/or should not be included.

• Include patterns: Resource files with the ending from the Resource File Format will be taken into account. Typically, a set of directories where those files are located is configured, one directory at a time, so that when new files are added under those directories, they are taken into account. Specific file names can be set to be more precise. If not Include Pattern is set, then all files ending in the File Format extension will be taken into account

• Exclude patterns: Files identified by those patterns will not be part of the set of files to translate. This is especially useful for sub-directories of the Include patterns directories, or special files in the Include patterns, such as 'application.json' or 'build.xml' files.

• Reference Material: Only FTP, Local, and Trados Enterprise TMS connection take reference materials. Those are files which help translator with context or guidelines. The reference material files defined here must be part of the data source, as in a Git repository for instance. Best is to identify each individual reference material file. In the example above, two Excel files are used as reference material and the project uses a Trados Enterprise TMS configuration.

Advanced Settings

• Prep kit configuration
  • Send changes only: If this flag is set, only the subset of the files containing the key/value pairs which need to be translated (new or modified source strings) will be sent to translation. If the this it not set, files containing new of modified strings since the last prep kit will be sent in their entirety.
  • Send separate translation kits for each locale: If this flag is set, a translation kit will be sent per locale; This may be useful with FTP or Upload/Download type TMSs. If this flag is not set, Localyzer will do its best to send a minimum number of prep kits, where each prep kit contains the same content for maximum number of locales.
  • Send InContext info: This flag can only be set for Trados Enterprise when an InContext Server has been configured on that type TMS. The InContext info allows to view the context in Trados Enterprise workbench.

• JSON comment starts with: This text field allows to enter the character placed at the start of a JSON key, indicating the value is a comment. JSON do not include comments as part of their syntax. However, Localyzer needs comments for the LRM Tags (see : https://wiki.lingoport.com/Localyzer_Resource_File_Comments). The de facto standard developers at large use is to put an underscore for those keys, hence the default _ in the text field.
• Language tag pattern:
• Global tags (Comma separated):

• Send kit to translate: this allows to send prep kit to translation on a schedule. Click the button and set how often to send files to be translated.

• Checks
  • Check for missed translation: When checked, a translation with the same value as the source value will raise an issue. It may be useful to turn this check on and off for some troubleshooting
  • Check for parameter mismatch: Parameters are configured in the Resource file format section. Localyzer will raise an issue if parameters identified by the regular expressions found in the source strings are missing in their corresponding translated strings. If unchecked, no such issue will be raised.
  • Check for ICU validation: If set, this flag will catch failed ICU message format. For more information on ICU message format, please see: https://lingoport.com/blog/mastering-icu-message-formats-best-practices-and-pitfalls-to-avoid/

• Import configuration
  • Remove tag on import: When sending a file to be translated, Localyzer adds a verification tag at the top of the file. Some customers like to keep that tag when the translated files are moved back to the data source like GitLab. Others prefer not to have that Localyzer special tag at the top of the translated files.
  • Use post import script: In some special cases, a post import script may be used to address complex situation. To use post import scripts, one must first be set in the General Settings > System Files.

• Custom Git Commit Message
  • Use a custom Git Import message: Some Git data sources use a Linter; Other processes may require special information to be added to the commit message. This allows Localyzer users to set whichever message when committing files, and uses four system variables
  • User context Git message