Difference between revisions of "Localyzer Release Notes"

From Lingoport Wiki
Jump to: navigation, search
(LRM 2.1 release)
(LRM 2.1 release)
Line 5: Line 5:
 
*'''Arrays are not allowed in the context of JSON files as resource bundles'''. String references in the code, from an i18n point of view, is unmanageable for JSON arrays. In addition, many L10n vendors do not support JSON arrays. (Sample JSON files are located in LRM-Server-2.1/''samples/JSON_Examples''):
 
*'''Arrays are not allowed in the context of JSON files as resource bundles'''. String references in the code, from an i18n point of view, is unmanageable for JSON arrays. In addition, many L10n vendors do not support JSON arrays. (Sample JSON files are located in LRM-Server-2.1/''samples/JSON_Examples''):
 
* '''There is only one key/value per line.'''
 
* '''There is only one key/value per line.'''
**Valid
 
*** <code>This is my value for key1",</code>
 
*** <code>"key2":"This is my value for key2</code>
 
**Invalid
 
This is my value for key1","key2":"This is my value for key2
 
   
 
**Valid
 
**Valid
"key1":"This is my value for key1",
+
***<code>"key1":"This is my value for key1",
"key2":"This is my value for key2"
+
***"key2":"This is my value for key2"</code>
 
** Invalid
 
** Invalid
 
"key1":"This is my value for key1","key2":"This is my value for key2"
 
"key1":"This is my value for key1","key2":"This is my value for key2"

Revision as of 20:30, 10 August 2015

The following lists new features in this latest release.

LRM 2.1 release

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.

  • Arrays are not allowed in the context of JSON files as resource bundles. String references in the code, from an i18n point of view, is unmanageable for JSON arrays. In addition, many L10n vendors do not support JSON arrays. (Sample JSON files are located in LRM-Server-2.1/samples/JSON_Examples):
  • There is only one key/value per line.
    • Valid
      • "key1":"This is my value for key1",
      • "key2":"This is my value for key2"
    • Invalid
   "key1":"This is my value for key1","key2":"This is my value for key2"
  • End-object character (curly bracket) may not exist on the same line as a key/value.
    • Valid
    "keys": {
    "key1":"This is my value for key1"
    }
    • Invalid
   "keys": {
   "key1":"This is my value for key1"}
  • Values associated with a key must be a string. Numeric and boolean values are not allowed.
    • Valid
   "key1":"0"
    • Invalid
   "key1":0
   "key1": true

LRM 2.0 release

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

  • 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

  • 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.