Difference between revisions of "LRM strings Support"

From Lingoport Wiki
Jump to: navigation, search
(Created page with "== Example .strings file == <pre> →‎Class = "IBUILabel"; text = "or"; ObjectID = "DTz-P6-Y3D";: "DTz-P6-Y3D.text" = "or"; /* Class = "IBUITextField"; placeholder = "Usern...")
 
(→‎Example Project Definition File)
 
(10 intermediate revisions by 2 users not shown)
Line 12: Line 12:
 
</pre>
  
</pre>
   
  +
== ''strings'' parser type ==
−
== Example Project Definition File ==
  
  +
=== valid IOS .strings syntax ===
  +
Files that use the ''strings'' parser are expected to have valid IOS .strings syntax
   
  +
=== .strings uses the ''strings'' parser type===
−
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
  
  +
When defining a project containing LRM Standard .strings resource files, there is no need to define a ''&lt;parser-type&gt;'' as the ''strings'' parser will always be used.
−
<lrmconf>
  
  +
−
<model-version>2.0.11</model-version>
  
  +
=== unique file extension needs to define ''strings'' parser type ===
−
<project-name>DemoIOS</project-name>
  
  +
If a unique file extension is a valid .strings file, then the ''&lt;parser-type&gt;'' should be ''strings'' in the project definition file.
−
<project-desc>This is a sample LRM Project definition file, configured for IOS resource files</project-desc>
  
  +
−
<!--group-name contains either the company name or the group name. -->
  
  +
== Missed Translations for new files ==
−
<group-name>acme</group-name>
  
  +
By default, LRM will '''ignore''' missed translations; text that is the same in both the base resource file and the target resource file.
−
<!-- Example, linux -->
  
  +
The exception is for a new IOS file; a file that has never been processed by LRM. Typically, when a new IOS base resource file is created, the subsequent target locale files are also created. This means that the target file exists but contains text of the base locale rather than the target locale.
−
<!--<top-level-dir>/var/lib/job/workspace/acme/source</top-level-dir>-->
  
  +
In this case, for IOS files, if the file has not been processed by LRM, then any missed translation will be contained in the next prep kit. Once the file has been processed by LRM, any new missed translations will be ignored.
−
<top-level-dir>C:\acme\source</top-level-dir>
  
  +
−
<detect-errors>
  
  +
== Example of Project Definition for Resources ==
−
<!--If set to '0' (false), then the 'missed translation' error will not be triggered-->
  
  +
The following is an example of strings resource file definitions. See [[Supported_Resource_Bundles#Resource_Extensions| resource extensions]] for more information.
−
<!--if the non-base file has the same text as the base file.-->
  
  +
−
<!--Missed Translation error will still occur if the base file has a different key or if-->
  
  +
<resource-extensions>
−
<!--the base file has changed since it was last prepped.-->
  
−
<missed-trans-error>1</missed-trans-error>
  
−
<parameter-mismatch-error>1</parameter-mismatch-error>
  
−
</detect-errors>
  
−
<!--If you wish to create Track Back resource files, enter the Track Back locale such as `br`-->
  
−
<!--The track back locale is mutually exclusive of the base (default) locale, target locales and pseudo-locale-->
  
−
<track-back-locale>br</track-back-locale>
  
−
<!--If you wish to pseudo-localized your files enter a pseudo-locale-->
  
−
<!--The pseudo-locale is mutually exclusive of the base (default) locale and target locales-->
  
−
<pseudo-locale>eo</pseudo-locale>
  
−
<!--Target locales are the locales where the corresponding resource files will be translated. -->
  
−
<!--These target locales are mutually exclusive of the base (default) locale-->
  
−
<target-locales>
  
−
<locale>es_MX</locale>
  
−
<locale>fr_CA</locale>
  
−
<locale>fr_FR</locale>
  
−
</target-locales>
  
−
<!--Default locale is the base locale. This is the locale where corresponding resource files will not be translated.-->
  
−
<!--The base (default) locale is mutually exclusive of the target locales-->
  
−
<default-locale>en_US</default-locale>
  
−
<resource-extensions>
  
−
<!--The file-name-pattern and/or file-location-pattern indicate the pattern of the-->
  
−
<!--localized file names (file-name-pattern) and the localized folder names (file-location-pattern).-->
  
−
<!--If the names contain the locale then a pattern of 1,c and v will be used.-->
  
−
<!--If the names contain the Locale ID then LCID will be used.-->
  
−
<!--Example pattern using locale-->
  
−
<!-- If your localized resource files use their locale in their names then the locale pattern will-->
  
−
<!-- be used where l stands for language; c for country; v for variant; and the characters between-->
  
−
<!-- are used as the separator characters.-->
  
−
<!-- <file-name-pattern>*_l_c_v</file-name-pattern>-->
  
−
<!--Example pattern using LCID (locale ID)-->
  
−
<!-- If your resource files are under a folder named 'resources' with an LCID suffix separated by an-->
  
−
<!-- underscore, then the pattern would be:-->
  
−
<!-- <file-location-pattern>resources_LCID</file-location-pattern>-->
  
 
<resource-extension>
  
<resource-extension>
  +
'''&lt;!-- parser-type not needed since .strings is a standard LRM extension that maps to the ''strings'' parser type --&gt;'''
−
<extension>strings</extension>
  
  +
'''<extension>strings</extension>'''
−
<file-name-pattern/>
  
−
<!--If the base resource files use the file-name-pattern in their name -->
 +
'''<file-name-pattern/>'''
−
<!--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>'''
−
<use-pattern-on-dflt-locale>1</use-pattern-on-dflt-locale>
 +
'''<file-location-pattern>l_c_v</file-location-pattern>'''
−
<file-location-pattern>l_c_v</file-location-pattern>
 +
'''<use-location-pattern-on-dflt-locale>1</use-location-pattern-on-dflt-locale>'''
  +
'''<base-file-encoding>UTF-8</base-file-encoding>'''
−
<!--If the base resource files use the file-location-pattern in their name -->
  
  +
'''<localized-file-encoding>UTF-8</localized-file-encoding>'''
−
<!--then set use-location-pattern-on-dflt-locale to 1, if not then set to 0-->
  
  +
'''<parameter-regex-pattern><![CDATA[(%([dsf]|(\d+\$[dsf@])|(\.\d+f)|@))|%\{\w+\}]]></parameter-regex-pattern>'''
−
<use-location-pattern-on-dflt-locale>1</use-location-pattern-on-dflt-locale>
  
  +
</resource-extension>
−
<base-file-encoding>UTF-8</base-file-encoding>
  
  +
<resource-extension>
−
<localized-file-encoding>UTF-8</localized-file-encoding>
  
  +
'''''&lt;!-- parser-type is required because .myext is not a standard LRM extension --&gt;'''''
−
<!--Default pattern for strings is '![CDATA[(%([dsf]|(\d+\$[dsf@])|(\.\d+f)|@))|%\{\w+\}]]'-->
  
  +
'''<extension>''myext''</extension>'''
−
<parameter-regex-pattern><![CDATA[(%([dsf]|(\d+\$[dsf@])|(\.\d+f)|@))|%\{\w+\}]]></parameter-regex-pattern>
  
  +
'''''<parser-type>strings</parser-type>'''''
  +
'''<file-name-pattern/>'''
  +
'''<use-pattern-on-dflt-locale>1</use-pattern-on-dflt-locale>'''
  +
'''<file-location-pattern>l_c_v</file-location-pattern>'''
  +
'''<use-location-pattern-on-dflt-locale>1</use-location-pattern-on-dflt-locale>'''
  +
'''<base-file-encoding>UTF-8</base-file-encoding>'''
  +
'''<localized-file-encoding>UTF-8</localized-file-encoding>'''
  +
'''<parameter-regex-pattern><![CDATA[(%([dsf]|(\d+\$[dsf@])|(\.\d+f)|@))|%\{\w+\}]]></parameter-regex-pattern>'''
 
</resource-extension>
  
</resource-extension>
 
</resource-extensions>
  
</resource-extensions>
  +
−
<dirset>
  
  +
== Bad IOS comments don't cause any errors. Why not?==
−
<!--Define the search patterns to include and/or exclude. (Uses Apache Ant pattern search).-->
  
  +
If an IOS file has a comment that is <b>not ended properly</b>, no error is thrown.
−
<!--Examples: -->
  
  +
For example, if a comment doesn't have an ending '''*/''', such as '''/*Bad comment''', then no errors are found.
−
<!-- A. '**/*.properties' matches all .properties files/dirs in a directory tree.-->
  
  +
In other words, the file is still parsed correctly even though the comment is missing the ending syntax. Since the file is parsed correctly, LRM is able to find the key/values.
−
<!-- B. 'test/a??.resx' matches all files/dirs which start with an 'a', -->
  
−
<!-- then two more characters and then '.resx', in a directory called test.-->
  
−
<!-- C. '**' matches everything in a directory tree. -->
  
−
<!-- D. '**/source/**/XYZ*' matches all files/dirs which start with 'XYZ'-->
  
−
<!-- and where there is a parent directory called source (e.g. 'abc/source/def/ghi/XYZ123'). -->
  
−
<includes>
  
−
<!--Directories to include in the search for base resource files -->
  
−
<!--Examples: -->
  
−
<!-- <include-dir>**/source/**</include-dir>-->
  
−
<include-dir>**/**</include-dir>
  
−
</includes>
  
−
<excludes>
  
−
<!--Directories or files to exclude in the search -->
  
−
<!--Examples: -->
  
−
<!-- <exclude-dir-file>**/source/bin/**</exclude-dir-file> -->
  
−
<!-- <exclude-dir-file>**/fileToIgnore.*</exclude-dir-file> -->
  
−
</excludes>
  
−
</dirset>
  
−
</lrmconf>
  

Latest revision as of 20:23, 18 September 2017

Example .strings file


/* Class = "IBUILabel"; text = "or"; ObjectID = "DTz-P6-Y3D"; */
"DTz-P6-Y3D.text" = "or";

/* Class = "IBUITextField"; placeholder = "Username"; ObjectID = "FiC-Ph-wbo"; */
"FiC-Ph-wbo.placeholder" = "Username";

/* Class = "IBUILabel"; text = "The username or password was incorrect."; ObjectID = "tDx-oc-GBE"; */
"tDx-oc-GBE.text" = "The username or \"password\" was incorrect.";

strings parser type

valid IOS .strings syntax

Files that use the strings parser are expected to have valid IOS .strings syntax

.strings uses the strings parser type

When defining a project containing LRM Standard .strings resource files, there is no need to define a <parser-type> as the strings parser will always be used.

unique file extension needs to define strings parser type

If a unique file extension is a valid .strings file, then the <parser-type> should be strings in the project definition file.

Missed Translations for new files

By default, LRM will ignore missed translations; text that is the same in both the base resource file and the target resource file. The exception is for a new IOS file; a file that has never been processed by LRM. Typically, when a new IOS base resource file is created, the subsequent target locale files are also created. This means that the target file exists but contains text of the base locale rather than the target locale. In this case, for IOS files, if the file has not been processed by LRM, then any missed translation will be contained in the next prep kit. Once the file has been processed by LRM, any new missed translations will be ignored.

Example of Project Definition for Resources

The following is an example of strings resource file definitions. See resource extensions for more information. 

  <resource-extensions>
   <resource-extension>
     <!-- parser-type not needed since .strings is a standard LRM extension that maps to the strings parser type -->
     <extension>strings</extension>
     <file-name-pattern/>
     <use-pattern-on-dflt-locale>1</use-pattern-on-dflt-locale>
     <file-location-pattern>l_c_v</file-location-pattern>
     <use-location-pattern-on-dflt-locale>1</use-location-pattern-on-dflt-locale>
     <base-file-encoding>UTF-8</base-file-encoding>
     <localized-file-encoding>UTF-8</localized-file-encoding>
     <parameter-regex-pattern><![CDATA[(%([dsf]|(\d+\$[dsf@])|(\.\d+f)|@))|%\{\w+\}]]></parameter-regex-pattern>
   </resource-extension>
   <resource-extension>
     <!-- parser-type is required because .myext is not a standard LRM extension -->
     <extension>myext</extension>
     <parser-type>strings</parser-type>
     <file-name-pattern/>
     <use-pattern-on-dflt-locale>1</use-pattern-on-dflt-locale>
     <file-location-pattern>l_c_v</file-location-pattern>
     <use-location-pattern-on-dflt-locale>1</use-location-pattern-on-dflt-locale>
     <base-file-encoding>UTF-8</base-file-encoding>
     <localized-file-encoding>UTF-8</localized-file-encoding>
     <parameter-regex-pattern><![CDATA[(%([dsf]|(\d+\$[dsf@])|(\.\d+f)|@))|%\{\w+\}]]></parameter-regex-pattern>
   </resource-extension>
 </resource-extensions>

Bad IOS comments don't cause any errors. Why not?

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, then no errors are found. In other words, the file is still parsed correctly even though the comment is missing the ending syntax. Since the file is parsed correctly, LRM is able to find the key/values.

Retrieved from "http://wiki.lingoport.com/index.php?title=LRM_strings_Support&oldid=90736"