Difference between revisions of "LRM strings Support"

From Lingoport Wiki
Jump to: navigation, search
(Example Project Definition File)
(Example Project Definition File)
 
(4 intermediate revisions by the same user not shown)
Line 22: Line 22:
 
If a unique file extension is a valid .strings file, then the ''<parser-type>'' should be ''strings'' in the project definition file.
 
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 ==
== Example Project Definition File ==
 
  +
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 ==
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
 
  +
The following is an example of strings resource file definitions. See [[Supported_Resource_Bundles#Resource_Extensions| resource extensions]] for more information.
<lrmconf>
 
  +
<model-version>2.0.11</model-version>
 
  +
<resource-extensions>
<project-name>DemoIOS</project-name>
 
<project-desc>This is a sample LRM Project definition file, configured for IOS resource files</project-desc>
 
<group-name>acme</group-name>
 
<top-level-dir>C:\acme\source</top-level-dir>
 
<detect-errors>
 
<missed-trans-error>0</missed-trans-error>
 
<parameter-mismatch-error>1</parameter-mismatch-error>
 
</detect-errors>
 
<track-back-locale>br</track-back-locale>
 
<pseudo-locale>eo</pseudo-locale>
 
<target-locales>
 
<locale>es_MX</locale>
 
<locale>fr_CA</locale>
 
<locale>fr_FR</locale>
 
</target-locales>
 
<default-locale>en_US</default-locale>
 
<resource-extensions>
 
 
<resource-extension>
 
<resource-extension>
 
'''&lt;!-- parser-type not needed since .strings is a standard LRM extension that maps to the ''strings'' parser type --&gt;'''
 
'''&lt;!-- parser-type not needed since .strings is a standard LRM extension that maps to the ''strings'' parser type --&gt;'''
Line 68: Line 55:
 
</resource-extension>
 
</resource-extension>
 
</resource-extensions>
 
</resource-extensions>
<dirset>
 
<includes>
 
<include-dir-file>**/src/**</include-dir-file>
 
</includes>
 
<excludes>
 
<exclude-dir-file>**/src/test/**</exclude-dir-file>
 
</excludes>
 
</dirset>
 
   
  +
== Bad IOS comments don't cause any errors. Why not?==
</lrmconf>
 
 
== Why don't Bad iOS Comments Trigger Errors?==
 
 
If an IOS file has a comment that is <b>not ended properly</b>, no error is thrown.
 
If an IOS file has a comment that is <b>not ended properly</b>, no error is thrown.
For example, if a comment doesn't have an ending '''*/''', such as '''/*Bad comment'''
+
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.
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.
 
 
<b>Note</b> ''key/value'' pairs are not effected. Noticed when '''LRM_RESEND''' tag was added,
 
the info in the Changed Key values included '''LRM_RESEND'''.
 

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.