Localyzer Release Notes

The following lists new features in this latest release.

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. The parser types available are:
  • html parser
  • js parser
  • json parser
  • msg parser
  • po parser
  • properties parser
  • rc parser
  • strings parser
  • xml parser where the files are parsed using the project's xmlParser.xml configuration file

See [XML Support] 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 [XML 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 [XML Support] for more details.

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.