LRM Fixing Issues

From Lingoport Wiki
Revision as of 16:42, 26 November 2012 by Llawson (talk | contribs)
Jump to: navigation, search

How can I tell if my project is setup correctly?

Once you've created your project run the project inspect report; java -jar lrm-cli.jar -r -pi -pn YourProjectName. This command generates a report, in your reports folder, listing all the base resource files that were found using the search criteria set up in the project definition. Of interest are the files that are listed in the ConfigTestSearch<base_locale>.xml file.

What extensions are supported by LRM?

LRM supports the following extensions:

  • properties - used by Java applications
  • resx - used by .NET applications
  • rc - used by Windows C++ and Delphi applications
  • msg - used by GNU C/C++ applications
  • po - used by PHP applications
  • rjs - custom JavaScript resource file where strings are of the form: var STR_HELLO_1 = "Hello";
  • rxml - custom XML resource file where strings are of the form: <entry xml:space="preserve" key="STR_HELLO_1">Hello</entry>

How do I fix "Error 202 - extension not supported" when updating or creating my project?

Verify that the project definition xml contains a supported extension. A valid extension does not include a period. For example, if the extension is for ".properties" files then the xml value should be <extension>properties</extension> not <extension>.properties</extension>.

How do I fix "Error 215 - incorrect pattern for extension" when updating or creating my project?

There are two supported patterns, LCID or language/country/variant.

  • For LCID - no other alpha characters are allowed except for LCID. For example, you could have a file name pattern "*_LCID" which, in the case of an fr_FR target locale, would result in "myResources_1036.po" as the filename of the translated resource file.
  • For language/country/variant - no other alpha characters are allowed except for l (language), c (country) and v (variant). The variant must be present even if you are not using variants. The order of the characters must be language, country, variant. For example, the file name pattern "*_l_c_v" applied to a base "po" resource file "myResources.po" would result in LRM naming the French in France translated file "myResources_fr_FR.po" before inserting it into the source code tree.

How do I fix "Error 218 - invalid base file encoding" and "Error 219 - invalid localized file encoding" when updating or creating my project?

The supported encodings vary between different implementations of the java platform. For example, the list of supported encodings supported by Java SE 6 is found here http://docs.oracle.com/javase/6/docs/technotes/guides/intl/encoding.doc.html. The encoding that should be copied into the project definition xml is located under column "Canonical Name for java.nio API". Every implementation of Java is required to support the following encodings.

  • US-ASCII
  • ISO-8859-1
  • UTF-8
  • UTF-16BE
  • UTF-16LE
  • UTF-16

When we generate the first prep kit with LRM, will all the base locale resource files be extracted, or only those base locale resource files that have corresponding localized files that have not been translated?

Since none of the base resource files are in the LRM system, all the base locale resource files will be extracted and placed in the appropriate localized prep kit folders. You will then rely on the localization vendor’s translation memory to translate resource files that may have already been translated. If you are confident that the localized files have been translated and do not want to send them to the localization vendor then there is workaround to by-pass the localization vendor and import the files directly into LRM. The prerequisite is that the first prep kit is successful and the base resource files have been copied into the locale-specific folders. For each supported locale:

  • Create an import folder on your hard drive. This folder will contain all your localized files for a particular locale.
  • Copy all the localized files from the source repository for a particular locale into this new import folder.
  • In order to import these localized files into LRM, each file must contain a valid LRM prep kit tag. During kit preparation (--prep-kit), LRM places a comment tag at the top of each resource file that indicates the LRM Project, Kit version and target locale. An example LRM tag is: MyProjectName_1_5.
    • Locate the prep kit folder for this particular locale.
    • The location of a prep kit tag is dependent on the resource extension.
      • properties, po - comment is on the first line. Example: #MyProjectName_1_5
      • resx, rxml - comment is after xml tag. Example: <!--MyProjectName_1_5-->
      • rc, rjs - comment is on the first line. Example: //MyProjectName_1_5
      • msg - comment is on the first line. Example: $MyProjectName_1_5
    • Open up a resource file and copy the LRM tag. You only need to copy one tag per resource extension.
    • Paste this LRM tag into each localized file in your import folder that has the same extension.
  • Run the --import-kit command where the file location is your import folder.
  • If there are localized files that have not been translated then the import will fail. This is an indication that a file needs to be sent to your translation vendor.
    • Create a new folder in your prep kit folder that will contain these files.
    • Copy the non-translated file from your prep kit folder to this new folder. It's important to copy the base resource file that is in the appropriate prep kit folder as it contains the valid prep kit tag.
    • Send these files off for translation
    • Once these files are returned, copy them over to your import folder and run the --import-kit command again. In order for an import to be successful, all localized files must be translated.



How can I prevent a file or folder from being included in the prep kit?

You will need to alter your project definition and exclude the file/folder from the project.

  • Export your project (--export-project -pn YourProjectName). This command exports your LRM project configuration to a file named SetupProjectConfig.xml.
  • Add an <exclude-dir> tag to the SetupProjectConfig.xml file that contains either the file or folder name using the proper Ant formatting directive.
  • xml structure for the exclude dir is:
    <exclude>
    <exclude-dir>...</exclude-dir>
    <exclude>
  • Run the project inspect report to verify that the file or folder was excluded from the search.

Why, when I prep a kit, do I get an error stating that no resource files were found (Error 500)?

It sounds as if your project is not setup correctly. You can view and edit your project definition by running the project inspect report. Configuration settings to check are:

  • <top-level-dir> - this is the path to the source code for this LRM Project. Note that this path must be relative to the base-src-dir setting stored in the lrmUserConfig.xml file. In other words: base-src-dir + top-level-dir = full path to the source code tree for your LRM Project.
  • Patterns for your resource file names:
    • <file-name-pattern>...</file-name-pattern> - verify that the separator characters are correct for your localized resource file names. For example, if your French Canadian localized resource file names are of the form "myResources_fr_CA.properties" then set the following: <file-name-pattern>*_l_c_v</file-name-pattern>.
    • <use-pattern-on-dflt-locale>.</use-pattern-on-dflt-locale> - Set to "1", it indicates you will use base resource files that include the default locale in their filenames. For example, if the default locale is set to "en_US" and the file-name-pattern for "properties" resource files is set to "*_l_c_v", then LRM will look for "myResources_en_US.properties" when creating a kit of files to be sent out for translation. If set to "0", then LRM will look for base resource files that do not have the default locale as part of their filenames. Using our "properties" file example, LRM will look for "myResources.properties" when creating files for translation.
    • <file-location-pattern>...</file-location-pattern> - verify that the separator characters are correct.
  • <include-dir>...</include-dir> - verify that the value is a valid Ant formatting directive. If there is no value then only those files directly under the base-src-dir + top-level-dir will be searched; no recursive search will occur. To include all folders under the full path, enter a value of **/**. You can then exclude other folders by adding additional exclude Ant directives. Format for <include-dir> is:
    <include>
    <include-dir>...</include-dir>
    <include>
  • <exclude-dir>...</exclude-dir> - verify that the value is a valid Ant formatting directive and that you're not excluding valid files/folders. Format for <exclude-dir> is:
    <exclude>
    <exclude-dir>...</exclude-dir>
    <exclude>

Why, when I prep a kit, do I get a report called "OutstandingPrepFiles<target locale>.xml"?

The base files that are listed in this report are files that have been prepped in an earlier kit and have not been imported. These base files have not changed since they were last prepped.

Why, when I prep a kit, do I get a report called "DuplicatePrepFiles<target locale>.xml"?

This is the list of duplicate base file names. A LRM prep kit must contain unique file names as all the files are located in the same folder. The existence of a "DuplicatePrepFiles<target locale>.xml report indicates that at least one more kit will need to be prepared after the current kit has successfully been prepped.

Why, when I prep a kit, do I get a report called "BaseFileSearchErrors<default locale>.xml"?

This report lists all the errors in the base resource files that were found during the preparation of the kit. All errors must be resolved before a kit can be prepared. The possible errors are:

  • ENCODING - the base-file-encoding you set in your LRM Project's definitions xml file does not match. You should fix the encoding of the base resource file and run --prep-kit --dry-run again.
  • DUPLICATE_KEY - there is a duplicate string key in the base resource file. Remove the duplicate and run --prep-kit --dry-run again.
  • EMPTY_KEY - the value has no corresponding key. Either remove the value from the file or add the appropriate key.
  • FILE_TOO_BIG - a base resource file cannot be larger than 16 megabytes. You will need to break up your resource file into multiple files and then run --prep-kit --dry-run again.

This report may also contain warnings. Unlike errors, a kit can be successfully prepared if the base resource files contains warnings. The possible warnings are:

  • EMPTY_VALUE - the string key in the base resource file is set to an empty string. This is just a warning and will not prevent you from creating and sending out a Kit