Supported Resource Bundles

What resource bundle types are supported by LRM?

Currently Version 2.1 of the Resource Manager supports the following file types:

• .json (with some restrictions for L10n purposes - See Release Notes 2.1 - Mostly JavaScript, and other programming languages)
• .msg (C, C++, ...)
• .po files
• .properties files (for instance, Java-type resources)
• .resx files (used in the .Net world)
• .rc (Delphi, ...)
• .rjs (for JavaScript)
• .rxml (for xml)
• .strings (Mobile iOS)
• strings.xml (Android)

How to setup LRM for .properties

The encoding of a .properties file is ISO-8859-1, also known as Latin-1. All non-Latin-1 characters must be entered by using Unicode escape characters, e. g. \uHHHH where HHHH is a hexadecimal index of the character in the Unicode character set. This allows for using .properties files as resource bundles for localization. A non-Latin-1 text file can be converted to a correct .properties file by using the native2ascii tool that is shipped with the JDK or by using a tool, such as po2prop, that manages the transformation from a bilingual localization format into .properties escaping. For more information, please refer to : http://en.wikipedia.org/wiki/.properties

Resource Manager Configuration

Typical .xml definition for projects with .properties files.

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<lrmconf>
  <model-version>2.0.12</model-version>
  <project-name>com.company.project</project-name>
  <project-desc>This is a sample LRM Project definition file, configured to support Java properties files</project-desc>
  <!--group-name contains either the company name or the group name-->
  <group-name>SVNFTP</group-name>
  <top-level-dir>/var/lib/jenkins/jobs/SVNFTP.com.company.project/workspace</top-level-dir>
  <detect-errors>
    <!--If set to '0' (false), then the 'missed translation' error will not be triggered-->
    <missed-trans-error>0</missed-trans-error>
    <parameter-mismatch-error>1</parameter-mismatch-error>
  </detect-errors>
  <pseudo-locale>eo</pseudo-locale>
  <target-locales>
    <locale>fr</locale>
    <locale>de_DE</locale>
    <locale>slv</locale>
    <locale>nob_NO_UNI</locale>
    <locale>zh_Hant</locale>
    <locale>ZHT_Hans</locale>
  </target-locales>
    <resource-extension>
      <extension>properties</extension>
      <file-name-pattern>*_l_c_v</file-name-pattern>
      <!--If the base resource files use the file-name-pattern in their name -->
      <!--then set use-pattern-on-dflt-locale to 1, if not then set to 0-->
      <use-pattern-on-dflt-locale>1</use-pattern-on-dflt-locale>
      <file-location-pattern/>
      <use-location-pattern-on-dflt-locale>0</use-location-pattern-on-dflt-locale>
      <base-file-encoding>UTF-8</base-file-encoding>
      <localized-file-encoding>UTF-8</localized-file-encoding>
      <!--Default pattern for properties is '![CDATA[\{\d+\}|%[ds]]]'-->
      <parameter-regex-pattern><![CDATA[\{\w+\}|%[ds]]]></parameter-regex-pattern>
    </resource-extension>
  </resource-extensions>
</lrmconf>

What is resx files encoding?

.Net resx files must be UTF-8 encoded, as per the resx schema, Hence, on-boarding resx resource bundles with LRM must specify the UTF-8 encoding:

https://msdn.microsoft.com/en-us/library/ekyft91f%28v=VS.90%29.aspx

<?xml version="1.0" encoding="utf-8"?>
<root>
    <xsd:schema id="root" xmlns="" xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
xmlns:msdata="urn:schemas-microsoft-com:xml-msdata">
<xsd:element name="data">
     <xsd:complexType>
           <xsd:sequence>
                <xsd:element name="value" type="xsd:string" minOccurs="0"
                    msdata:Ordinal="2" />
            </xsd:sequence>
                <xsd:attribute name="name" type="xsd:string" />
                <xsd:attribute name="type" type="xsd:string" />
                <xsd:attribute name="mimetype" type="xsd:string" />
      </xsd:complexType>
</xsd:element>

In what format should JSON Files be for LRM Handling ?

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.

• The json files must follow this naming convention: filename_<locale>.json or filename_<locale>_<country>.json. For example, resources_en.json or resources_en_US.json, resources_fr.json or resources_fr_FR.json, etc.
• 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

Why don't Bad iOS Comments Trigger Errors?

If an IOS file has a comment that is not ended properly, no error is thrown. For example, if a comment doesn't have an ending */, such as /*Bad comment no errors are found.

This is due to the formatting of iOS. This type of bad comments would typically be created on the base files.

Note key/value pairs are not effected. Noticed when LRM_RESEND tag was added, the info in the Changed Key values included LRM_RESEND.