Supported Resource Bundles

From Lingoport Wiki
Revision as of 23:10, 19 January 2017 by Rdaly (talk | contribs) (In what format should JSON Files be for LRM Handling ?)
Jump to: navigation, search

What resource file types are supported by LRM?

The Lingoport Resource Manager supports the following file types:

  • .json (with some restrictions for L10n purposes - See below for format of .json as resource bundles - 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

Lingoport Resource Manager Configuration

LRM creates projects using a Project Definition XML file that contains information about the resources and types for translation. Here is a typical .xml definition for projects with .properties files.

This will create a project called com.company.project in the group SVNFTP. The resource files are located in the /var/lib/jenkins/jobs/SVNFTP.com.company.project/workspace directory. The resources are targeting six different locales. The resource files to be translated are .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 the group name that the LRM license is under-->
  <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 files 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 ?

The JSON extension is supported in Lingoport Resource Manager (LRM). 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.
  • If you can, avoid duplicate file names. Duplications incur more prep kits than necessary.
  • 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.
  • End-object character (curly bracket) may not exist on the same line as a key/value.
  • Values associated with a key must be a string. Numeric and boolean values are not allowed.

For more detailed information on the above, please go to the .json support page.

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.