LRM Properties Support

How to setup LRM for .properties files as well as file extensions using the properties parser type

The encoding of a .properties file is ISO-8859-1, also known as Latin-1. All non-Latin-1 characters must be entered by using Unicode escape characters, e. g. \uHHHH where HHHH is a hexadecimal index of the character in the Unicode character set. This allows for using .properties files as resource bundles for localization. A non-Latin-1 text file can be converted to a correct .properties file by using the native2ascii tool that is shipped with the JDK or by using a tool, such as po2prop, that manages the transformation from a bilingual localization format into .properties escaping. For more information, please refer to : http://en.wikipedia.org/wiki/.properties

Naming Conventions

For optimum use of LRM, we strongly recommend that base files be named uniquely. If you have two files for instance, do not name them both resources.properties. Name them something different, like resources.properties and messages.properties

Properties files are used by applications written in many programming languages, such as Java. Java for instance has a full fledged standard infrastructure to handle resources (strings mostly) from properties files. Typically, an application will have many .properties base files located under different directories. The base file typically does not have a locale suffix as it serves as the default locale when resources are missing in another locale. See https://docs.oracle.com/javase/tutorial/essential/environment/properties.html .

For a base file named resources.properties, the corresponding French file will be in the same directory and the locale will be added to the file name: resources_fr.properties.

For example, for a few locales, the directory structure and file names would be:

 messages.properties
 messages_de.properties
 messages_es.properties
 messages_fr.properties
 messages_ru.properties
 messages_zh.properties

The bold file is the base file (U.S. English in this instance) translated into German, Spanish, French, Russian, and Chinese.

Example of .properties or a file extension using the properties parser type

  byTheFollowingAdministrator= by the following administrator: {0}
  artifactChangeNotification.Ownership=the request for notification of any change to a {0} you own.
  firstLastName={0} {1}
  user.confirm.delete=Are you sure you want to delete {0}?\\n\\nTHERE IS NO UNDO for deleting Users.
  user.editor.save.error=<strong>The User could not be saved.</strong><br/>\
  Please correct the errors identified below and click one of the "Save" buttons.<br/>
  #
  # bind and validation errors
  #
  User.invalidValueError.name=User Name must be a valid email address.

Note:

• \ at the end of a string means the following line is part of that string, as in

  user.editor.save.error=<strong>The User could not be saved.</strong><br/>\
  Please correct the errors identified below and click one of the "Save" buttons.<br/>

• Parameters are typically numbers in braces, as in

 firstLastName={0} {1}

• Comments are specified with a # sign at the beginning of the line

 # bind and validation errors

properties parser type

valid properties syntax

Files that use the properties parser are expected to have valid properties syntax

.properties uses the properties parser type

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

unique file extension needs to define properties parser type

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

Example of Project Definition File

<?xml version="1.0" encoding="UTF-8"?>
<lrmconf>
  <model-version>2.0.11</model-version>
  <group-name>acme</group-name>
  <project-name>DemoJava</project-name>
  <project-desc>This is a sample LRM Project definition file, configured to support Java properties files</project-desc>        
  <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>fr_FR</locale> 
     <locale>fr_CA</locale> 
     <locale>es_MX</locale>
   </target-locales>
   <default-locale>en_US</default-locale> 
   <resources-extensions> 
     <resource-extension>
        <extension>properties</extension>
        <file-name-pattern>*_l_c_v</file-name-pattern>
        <use-pattern-on-dflt-locale>0</use-pattern-on-dflt-locale>             
        <file-location-pattern></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>
        <parameter-regex-pattern><![CDATA[\{\w+\}|%[ds]]]></parameter-regex-pattern>
     </resource-extension>
     <resource-extension>
        <extension>myext</extension>
        <parser-type>properties</parser-type>
        <file-name-pattern>*_l_c_v</file-name-pattern>
        <use-pattern-on-dflt-locale>0</use-pattern-on-dflt-locale>             
        <file-location-pattern></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>
        <parameter-regex-pattern><![CDATA[\{\w+\}|%[ds]]]></parameter-regex-pattern>
     </resource-extension>
  </resources-extensions>
  <dirset>
     <includes>
        <include-dir-file>**/src/**</include-dir-file>
     </includes>
     <excludes>
       <exclude-dir-file>**/src/test/**</exclude-dir-file>
     </excludes>
  </dirset>
</lrmconf>