LRM strings Support - Revision history

Rwilliams: /* Regular Expression */

2025-09-26T15:23:37Z

Regular Expression

← Older revision		Revision as of 15:23, 26 September 2025
Line 46:		Line 46:
	This change will take into account the possibility of there being an integer in the parameter as would be added by XTM so that the source and translations containing the XTM parameter with the integer will be correctly identified as a parameter by Localyzer allowing it to correctly validate parameter mismatches.		This change will take into account the possibility of there being an integer in the parameter as would be added by XTM so that the source and translations containing the XTM parameter with the integer will be correctly identified as a parameter by Localyzer allowing it to correctly validate parameter mismatches.

	Failure to make this change after both the base resource and translations have incorporated the additional integer within their respective parameter(s) will result in ~~a failure~~ to detect a legitimate parameter mismatch for these specific parameters as Localyzer will no longer see them as parameters and simply allow them to pass as normal strings. This results in not having the benefit of parameter mismatch checking for those specific parameters.		Failure to make this change after both the base resource and translations have incorporated the additional integer within their respective parameter(s) will result in the inability to detect a legitimate parameter mismatch for these specific parameters as Localyzer will no longer see them as parameters and simply allow them to pass as normal strings. This results in not having the benefit of parameter mismatch checking for those specific parameters.

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

Rwilliams: /* Regular Expression */

2025-09-26T15:21:51Z

Regular Expression

← Older revision		Revision as of 15:21, 26 September 2025
Line 29:		Line 29:
	== Regular Expression ==		== Regular Expression ==

			When working with and IOS resource file .strings format, the default parameter regex setting will be the following:
			<pre>
			%([dsf]\|(d$[dsf@])\|(.df)\|@)\|%\{w+\}
			</pre>

			This will handle most use cases correctly. However, if the TMS being used is XTM, please consider that XTM will automatically append an integer to the parameters in the returned translations if there currently is not one present in the base resource file. For details on this, please refer to the section :
			* [[XTM_Cloud#XTM_Special_Instructions_-_parameters_.28e.g._.25d.2C_etc.29]]

			As noted in the XTM Cloud Special Instructions, the correct course to handle this is to modify the base resource file so that it has the integers already applied in the parameter(s). At that point the returned translations will be allowed to import without causing a parameter mismatch error due to XTM modifying the parameter automatically.

			There is one additional change that should be made to the parameter regex setting in order to pull this all together. Modify the parameter regex in the project from the default to the below:
			<pre>
			(%([dsf]\|(\d+\$[dsf@])\|(\.\d+f)\|@))\|%\{\w+\}
			</pre>

			This change will take into account the possibility of there being an integer in the parameter as would be added by XTM so that the source and translations containing the XTM parameter with the integer will be correctly identified as a parameter by Localyzer allowing it to correctly validate parameter mismatches.

			Failure to make this change after both the base resource and translations have incorporated the additional integer within their respective parameter(s) will result in a failure to detect a legitimate parameter mismatch for these specific parameters as Localyzer will no longer see them as parameters and simply allow them to pass as normal strings. This results in not having the benefit of parameter mismatch checking for those specific parameters.

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

Olibouban: /* Internal Example of Project Definition for Resources */

2025-09-26T14:26:31Z

Internal Example of Project Definition for Resources

← Older revision		Revision as of 14:26, 26 September 2025
Line 43:		Line 43:

	== '''Internal''' Example of Project Definition for Resources ==		== '''Internal''' Example of Project Definition for Resources ==

			'''This section is for internal checking only, not for Command Center.'''

	The following is an example of strings resource file definitions. See [[Supported_Resource_Bundles#Resource_Extensions\| resource extensions]] for more information.		The following is an example of strings resource file definitions. See [[Supported_Resource_Bundles#Resource_Extensions\| resource extensions]] for more information.

Olibouban at 14:25, 26 September 2025

2025-09-26T14:25:42Z

@@ Line 27: / Line 27: @@
 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 ==
+== Regular Expression ==
 The following is an example of strings resource file definitions. See [[Supported_Resource_Bundles#Resource_Extensions| resource extensions]] for more information.
@@ Line 55: / Line 70: @@
      </resource-extension>
    </resource-extensions>

Llawson: /* Example Project Definition File */

2017-09-18T20:23:20Z

Example Project Definition File

@@ Line 27: / Line 27: @@
 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 Project Definition File ==
+== Example of Project Definition for Resources ==
- <?xml version="1.0" encoding="UTF-8" standalone="no"?>
+   <resource-extensions>
      <resource-extension>
        '''&lt;!-- parser-type not needed since .strings is a standard LRM extension that maps to the ''strings'' parser type --&gt;'''
@@ Line 73: / Line 55: @@
      </resource-extension>
    </resource-extensions>
 == Bad IOS comments don't cause any errors. Why not?==

Llawson: /* Example Project Definition File */

2017-09-13T23:57:51Z

Example Project Definition File

← Older revision		Revision as of 23:57, 13 September 2017
Line 81:		Line 81:
	</excludes>		</excludes>
	</dirset>		</dirset>

	</lrmconf>		</lrmconf>

Llawson: /* Why don't Bad iOS Comments Trigger Errors? */

2017-09-13T18:47:00Z

Why don't Bad iOS Comments Trigger Errors?

← Older revision		Revision as of 18:47, 13 September 2017
Line 84:		Line 84:
	</lrmconf>		</lrmconf>

	== ~~Why~~ don't ~~Bad iOS Comments Trigger Errors~~?==		== Bad IOS comments don't cause any errors. Why not?==
	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.
	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.

	~~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'''~~.

Llawson: /* Missed Translations for new files */

2017-09-13T18:35:54Z

Missed Translations for new files

← Older revision		Revision as of 18:35, 13 September 2017
Line 25:		Line 25:
	By default, LRM will '''ignore''' missed translations; text that is the same in both the base resource file and the target resource 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.		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. ~~(to change the default behavior goto~~		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 Project Definition File ==		== Example Project Definition File ==

Llawson: /* strings parser type */

2017-09-13T18:13:52Z

strings parser type

← Older revision		Revision as of 18:13, 13 September 2017
Line 21:		Line 21:
	=== unique file extension needs to define ''strings'' parser type ===		=== 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.		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. (to change the default behavior goto

	== Example Project Definition File ==		== Example Project Definition File ==

Llawson: /* Example Project Definition File */

2017-09-01T16:19:50Z

Example Project Definition File

@@ Line 11: / Line 11: @@
 "tDx-oc-GBE.text" = "The username or \"password\" was incorrect.";
 </pre>
 == Example Project Definition File ==