Localyzer Release Notes

The following lists new features in this latest release.

Versions of LRM jar files

Lingoport Suite Release	LRM Release	lrm-cli	lrm-process	lrm-common	lpcommon
Fiji	LRM 6.0	6.0.27	6.0.17	6.0.07	6.0.10
Egypt	LRM 5.1	5.1.19	5.1.06	5.1.02	5.1.18
Denmark	LRM 5.0	5.0.31	5.0.00	5.0.00	5.0.05

Versions of Lingoport Connectors

Lingoport Suite Release	LRM Release	lingoport-ftp-cli	lingoport-lingotek-cli	lingoport-local-cli	lingoport-ws-cli	lingoport-mt-cli	lingoport-memsource-cli	lingoport-xtm-cli
Fiji	LRM 6.0	6.0.04	6.0.04	6.0.03	6.0.06	6.0.20	1.2.0_4	1.0.0_0
Egypt	LRM 5.1	5.1.05	5.1.06	5.1.05	5.1.06		1.0.0_1	1.0.0_0
Denmark	LRM 5.0	5.0.00	5.0.01	5.0.00	5.0.00

Historical Versions

Lingoport Suite Release	LRM Release	lrm-cli	lrm-process	lingoport-ftp-cli	lingoport-lingotek-cli	lingoport-local-cli	lingoport-ws-cli	lrm-common	lpcommon	lingoport-mt-cli	lingoport-memsource-cli	lingoport-xtm-cli
Cyprus	LRM 4.1	4.1.27	4.1.04	4.1.00	4.1.00	4.1.01	4.1.01	4.1.00	4.1.07
Belize	LRM 4.0	4.0.13	4.0.06	4.0.04	4.0.01	4.0.02	4.0.01	4.0.02	4.0.05
	LRM 3.4	3.4.08	3.4.01	3.4.01	3.4.01	3.4.01	3.4.01	3.4.01	3.4.03
	LRM 3.3	3.3.15	3.3.03	3.3.02	3.3.02	3.3.01	3.3.02	3.3.02	3.3.09

LRM 6.0 release - July 2020

• Integration with an AWS Amazon Translate service: Ability to translate LRM resource files using an AWS Amazon Translate service
• Integration with SYSTRAN Pure Neural® Server: Ability to translate LRM resource files using the Systran Pure Neural Machine Translation System
• Support locale at top of file structure: LRM now supports file structures where locales are at the top of the structure (subfolders under locale folder). This allows support for DITA type file structures.

LRM 5.1 release - Dec 2019

• Integration with XTM: XTM can be configured as an LRM local vendor. LRM prep kit will send files out to XTM to be translated, and translated files will be imported into LRM. The configuration details are either at the project or group level.
• Integration with Memsource: Memsource can be configured as an LRM local vendor. LRM prep kit will send files out to Memsource to be translated, and translated files will be imported into LRM. The configuration details are either at the project or group level.
• SDL Trados Plugin for InContext Translation: The Plugin allows translators to view translation targets in their actual context. The application must have already been instrumented and executed to capture context using Lingoport products.
• XHTML Support: Well-formed XML files, such as .dita, can now be parsed using parser type `HTML`. Unlike other resource types, LRM only determines if the base resource file has changed. No comparison is made against the localized files. These files may be pseudo-localized and the number of words counted. More information can be found at html parser
• HTML fragment support: LRM now supports files that contain a HTML fragment. More information can be found at html parser
• Binary parser type: Parser type binary is used for those files that cannot be parsed using any other LRM parser type. Unlike other resource types, LRM only determines if the base resource file has changed. No comparison is made against the localized files. These files cannot be pseudo-localized nor can the number of words be counted.
• Global email configuration file location: The location of the global email configuration files can now be located at either the global, group or project level. This allows for a unique email to be used for a specific group or project. See Sending Emails for more information.
• ICU Message Format errors relaxed: LRM now allows for the concatenation of text and ICU Message Format in a single resource string. Though allowed, it is recommended that the concatenated text be refactored into a complex ICU Message Format. See http://userguide.icu-project.org/formatparse/messages for ICU formatting information.

LRM 5.0 release - May 2019

• InContext Translation: LRM supports Lingoport InContext Translation by instrumenting all base resource files. These instrumented files in conjunction with the InContext Server Configuration are used to decorate the prep kit files in order to display the strings that need to be translated.
• Reordering Translated File Keys: Keys for imported file will be in the same order as the base resource file. Any keys that are in the imported file but not in the base resource file (ghost keys) will be removed. Resource file with the .po type are not reordered.
• Unique File Names: If the project's definition file or Jenkins automation job has the send-unique-file-names flag set to true, then the files in the prep kits will have been converted to unique file names. The prefix of the file in the prep kit is "LID<hash of absolute path>. The LRM Unique File Names feature allows for duplicate file names to be sent in the same prep kit.
• Empty files no longer log a critical error: Files with no key/values will no longer report a critical error. The files will be ignored by LRM until they contain key/values.
• Report project_inspect_files.txt: There is a new report, located in L10nStreamlining/<group>/projects/<project>/reports called project_inspect_files.txt. This file is created during the project inspect process and contains all the expected target files. See Checking Project Definition for an example of the report contents.
• Language tags in JSON: LRM now supports json files that contain a language tag. JSON Language Tags
• Transform Scripts: For those file types which are not supported by LRM, Lingoport provides a scripting framework for advanced users to transform files from the repository into LRM supported types and back.

LRM 4.1 release - Dec. 2018

• Text Parser: LRM now support text files. Unlike other resource types, LRM only determines if the base resource file has changed. No comparison is made against the localized files. A file using the new text parser can be pseudo-localized. More information can be found at text parser
• YAML Parser: LRM now supports 'yaml' type files. More information can be found at yaml parser
• Resource locations: The location pattern (the search pattern that is used to find base resource files) has been expanded to include explicit directory names as well as wildcard names. More information can be found at location pattern
• Ability to instrument pseudo-localized files: There is a new flag in the config_pseudo_loc.xml configuration file that indicates whether the pseudo-localized files should contain instrumentation. Instrumented files are used in conjunction with the Lingoport InContext Reviewer. More information can be found at config_pseudo_loc.xml
• Prep Kit Override: Command option to create a prep kit regardless of changes. More information can be found at LRM override and LRM Process override.

LRM 4.0 release - Aug. 2018

• Introducing Lingoport InContext QA:This new product's goal is to simplify the linguistic process for reviewers who may not have any knowledge of the source code repositories and/or of the translation team. Lingoport InContext QA is a product that leverages Lingoport Resource Manager and allows a reviewer in Google Chrome to enter suggestions to be handled by the translation team.

See Lingoport InContext QA for more details.

• Test FTP Connection Command:The Test FTP Connection command will test the connection configuration for a particular group/project. A test file will be uploaded to the configured location if the connection is successful. For download, all .zip files that are in the configured location will be downloaded to a local folder if the connection is successful. The default behavior is to test the upload configuration. Using option --download will test the download configuration.

LRM 3.4 release - Dec. 2017

• Create Baseline Command: The create baseline command stores all the base resource files so that modified text can be detected. Before the existence of the create baseline command, a 'baseline' was created when the first prep kit was created. The new create baseline command allows for a 'baseline' to occur without creating a prep kit. The baseline command has the following syntax:

java -jar lrm-cli.jar --create-baseline -pn <project name> -gn <group name>

java -jar lrm-cli.jar -cb -pn <project name> -gn <group name>

• TranslationStatus.xml report: Flag added indicating whether a locale has outstanding prep kits.

LRM 3.3 release - Sept. 2017

• Generic XML Parser: LRM uses the xmlParser.xml file to parse any extensions that have a xml parser type. This file is located in the ../L10nStreamlining/group/projects/project/config folder. The xmlParser.xml directs LRM on the location of the keys and values within the xml files as well as whether the key/value is translatable. See XML Support for more details.
• Non-standard extensions support: A project can be defined using a non-standard extension. If an extension is non-standard then a parser type is required. The files will then be parsed using the defined parser type.

See Unique Extensions for more details.

• Local Vendor option for a project. The configuration for the local vendor includes a local output location (where the zip files containing the prep kit files are stored) as well as a local input location (where the zip file containing the translated files are stored).

See Local Vendor Support for more details.

• Send email enhancements:
  • Ability, through java options, to explicitly set a email port and the STARTTLS flag
  • Allow no email authorization. The default protocol will be SMTP.

See Sending Emails for more details.

• LRM Jenkins Plugin:
  • On-board LRM projects directly from Jenkins pluging user interface
  • If another project has the same LRM characteristics, use the plugin copy from feature to fill in the configuration

LRM 3.2 release - May 2017

• Integration with GlobalLink: GlobalLink integration is now one of our supported packaged TMS connections. The configuration details are either at the project or group level.
• HTML/HTM extensions are supported: Well-formed HTML is required. Unlike other resource types, LRM only determines if the base resource file has changed. No comparison is made against the localized files.
• Ability to set SSL FTP connection implicit or explicit: Flag is located in a project's config_l10n_vendor.properties file.
• Emails contain a link to the project's Dashboard enabling users to view the status of the LRM project
• No restriction on Android resource file names: Pre LRM 3.2, Android file names were restricted to only strings.xml. To preserve this restriction, the project needs to be updated after adding '**/strings.xml' to the include portion of the project definition file.
• Pseudo-localization enhancements

LRM 3.1 release - Dec 2016

• Support of ICU Message Pattern: Icu Message Pattern, as defined by http://icu-project.org, is now supported by LRM. This includes pseudo-localizing resource files that contain an ICU Message Pattern as well as comparing the base resource file patterns against the non-base resource file patterns.
• Continual prepping of project with duplicate file names: The lrm-process prep kit command will continue prepping a new kit until there are no duplicate file names that need be prepped.
• Ability to delete a project even if prep kits exist and files have been imported

LRM 3.0 release - May 2016

• Integration with Worldserver™
  • Worldserver is now one of our OOTB translation vendors. The configuration details are at either the project or group level.
• Integration with Workforce™ (AtTask)
  • Ability to create a project that has tasks for each locale in a prep kit. Additional information such as attaching templates as well as URL links are configurable
• Extending LRM using custom tasks
  • The config_custom_tasks.xml configuration file contains the specific stages where a plugin can be called. Dynamic information is available to the plugin through the LRM Context object (com.lingoport.lrm.customtask.LRMContext). The lrm-customtasktest.jar, located in the samples/CustomTask/ folder of your install directory, contains methods for testing out these different stages.
• Ability to transform .json into .properties for those L10n Vendor that cannot handler .json files
  • If a translation vendor does not support .json files, then these files will be converted to .properties before being sent to the vendor. The files are converted back to .json files during the import process.

LRM 2.2 release - Oct 2015

• Support for ISO 639-1 codes 'id' (Indonesian), 'he' (Hebrew) and 'yi' (Yiddish).
• Support for Script subtags for target locales. These are based on ISO 15924 and indicate the writing system.
  • A list of the codes can found at ISO 15924
• Ability to create 'Track Back' resource files.
  • A track back resource file is a resource file where the value, associated with a key, contains information for developers and/or technical linguists. This information is configurable and the pattern is located in the config_lrm_info.properties located in the 'group' level config folder. The information that can be captured in a track resource file is:
    • file Name denoted with parameter ${filename}
    • file Path denoted with parameter ${filepath}
    • key denoted with parameter ${key}
    • group name denoted with parameter ${group}
    • project name denoted with parameter ${project}

LRM 2.1 release - Aug 2015

JSON extension is supported in The Lingoport Manager (LRM) 2.1 release. Well-formed JSON is required and specified by http://www.ietf.org/rfc/rfc4627.txt. In order to detect and import changes, LRM 2.1 requires JSON files to also adhere to the following standards.

For more information on JSON support, please see JSON Resource Bundles

LRM 2.0 release- Apr 2015

The Lingoport Manager (LRM) 2.0 release allows for seamless integration between source code repositories and translation systems to support continuous globalization. It reduces considerably the manual steps development teams and L10n management may need to handle translation of application resource bundles. The updated framework permits the addition of repository types and of translation systems to match the client's ecosystem.

• Get source code from the repository
• Analyze and report the translation status in the Lingoport Dashboard
• Notify configured recipients of different events via email
• Determine which files need to be sent for translation and shows in the Lingoport Dashboard
• Facilitate sending the necessary files to a configured translation system
• Facilitate receiving translated files
• Import the files back to the repository
• Pseudo-localize base resource bundles

Some of the benefits

• Visibility and clarity of translation for development projects
• Much shorter translation cycles
• Much fewer (none) number of people handling the files back and forth
• Automatic tracking of translation status
• Supports Agile type development
• Supports Continuous Globalization
• Automatic Notification
• Strong checks on translated files and on base (U.S. English typically) files
• Reduced number of errors due to translated files

LRM 1.5 release - Sep 2014

• Android Extension 'xml' is supported
• IOS Extension 'strings' is supported
• Ability to send a translated file for retranslation:
  • LRM_RESEND tag is used above any key in a translated file that is to be retranslated.
  • Error NONBASE_RETRANSLATE_TEXT is reported in the --source-issues report.
  • Any file with an LRM_RESEND tag is reported in the --files-to-prep report.
  • Any file with an LRM_RESEND tag will be in the next prep kit.
• Ability to detect whether a project exists: Command --project-exists --project-name xxx will return successfully if the project xxx exists.
• Ability to pseudo-localize project files: Command --pseudo-loc --locale is_IS -f C:\Lingoport\LRM-Client-1.5\lrm_pseudo_loc.xml --project-name xxx will pseudo-localize all xxx project files. In this example, the locale of the pseudo-localized files will be is_IS and the pseudo-localization configuration file that determines how to pseudo-localize is found at C:\Lingoport\LRM-Client-1.5\lrm_pseudo_loc.xml

Should you encounter problems or have questions, please email support@lingoport.com.

LRM 1.4 release - Feb 2014

• Prep Kit Due Date: Set the prep kit due date on a per locale basis. This due date will appear on the PrepKitStatus report.
• Parameter Mismatch Error:
  • For a properties file, a PARAM_MISMATCH error will be reported if the translated file's parameters do not match the non-translated (base) file parameters.
  • Error is reported in the --source-issues report.
  • Error is reported in the --import-issues report.
  • The flag that determines whether to detect parameter mismatch errors is located in the project definition file.
• Modified Text Error: If the non-translated file (base file) has been modified since the last prep, then a MODIFIED_TEXT error will be reported rather than a MISSED_TRANSLATION error.
• Missed Translation Error Detection: A MISSED_TRANSLATION error occurs when the text of the translated file is the same as the base file. The flag that determines whether to detect a MISSED_TRANSLATION error is located in the project definition file.
• Reimport: Allow the user to import a previously imported prep kit file.
• Files to Prep Report: Report on the content of the next prep kit.

LRM 1.3 release

• Ability to create a changes-only prep kit: The option --changes-only has been added to the --prep-kit command in order to create prep kit files that contain only those key/values that have changed since the last prep kit.

LRM 1.2 release

• Ability to ignore programmatic strings when importing a kit: Some resource files may contain strings that should not be translated; for example, the resource file may contain UI directives. To automatically add ignore tags to all keys that were not translated, the option --insert-ignoretags was added to command --import-kit.
• Detect Client/Server mismatch: LRM will now issue an error if the client version is incompatible with the server version.
• Change in location of LRM Project data: When installing the LRM client, user data, such as the lrmUserConfig.xml file as well as the report folders (logs, reports, prep_kit) will now be located in folder Lingoport_Data/LRM under the user's home directory.

LRM 1.1 release

• Start an LRM Project with Translated Files: LRM simplifies the initial setup of a project when you already have some translated resource files. During the first --prep-kit command, LRM will find, verify and incorporate those translated files into your LRM project. Similarly, when a new target locale that already has translated files is added to an LRM project, LRM will validate and incorporate the additional translated files.
• Simplified Project Definition File Creation: A wizard is now available to help you generate your LRM Project Definition XML file. Instead of copying and editing one of our sample project XML files, follow the wizard's clear instructions to create a Project Definition XML file that you can then use with the --create-project command.
• Stricter Import Command: To help ensure that the translated resource files are valid prior to importing them into the source code tree, the --import-kit command now requires a --kit-version option.

LRM 1.0 release

A Product for Development Teams: Lingoport Resource Manager (LRM) is used by development teams to manage the delivery, validation and integration of translated resource files. It is not a translation product or a Content Management System.

• Customize your LRM Project: An application's resource files comprise a single LRM Project. You customize your project by modifying a Project Definition XML file, setting resource file types, target locales, and other information just once for your project.
• LRM Kits contain all needed files for translation: Each time you need translations for your project, create an LRM Kit to send to your localization vendor.
• Kit Version for tracking: Each kit is marked with a version number to track its translation progress and, once returned, is checked against the pre-translated files for errors and omissions.
• Multi-User Project Support: There are two components to Lingoport Resource Manager: a server and a client. The server is installed once, while the client can be installed on many user systems. The server keeps track of Projects and Kits, allowing multiple users to share in the creation and integration of Kits for the same Project.
• LRM's Command Line Interface: Run simple commands or automate scripts to prepare kits for translation and to import translated kits into the source code.
• Improve Processes: LRM will streamline your localization process, reducing risk and increasing quality.
• Interaction with the Lingoport Dashboard: Install and configure the Lingoport Dashboard to show your LRM project's localization status per locale and any potential issues. For details on a specific issue, use the Dashboard's drill-down feature to view the individual lines in the corresponding resource file.
• Continuous Integration Support: Update your Lingoport Dashboard with your LRM project status during a nightly build so that tracking the localization effort is part of your ongoing development.