Supported Resource Bundles
Contents
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)
See <HOME>/lingoport/lrm-server-x.y/samples for sample Project Definition files.
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.
This is the LRM project name that will be created.
<project-name>com.company.project</project-name>
This is the LRM group name that the project will be under.
<group-name>SVNFTP</group-name>
This is the location of the resource files.
<top-level-dir>/var/lib/jenkins/jobs/SVNFTP.com.company.project/workspace</top-level-dir>
This is the locale to translate from
<default-locale>en_US</default-locale>
Here are the locales which will be translated into
<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>
Look for .properties resource files.
<extension>properties</extension>
Here is a sample Project Definition file to create an LRM project. This example is for .properties files. Additional <resource-extension>
stanzas can be added to include other extensions. Samples for the supported extensions can be found in <HOME>/lingoport/lrm-server-x.y/samples.
<?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> <default-locale>en_US</default-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>
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.