Difference between revisions of "Supported Resource Bundles"

From Lingoport Wiki
Jump to: navigation, search
(In what format should JSON Files be for LRM Handling ?)
(Resource Extensions)
 
(86 intermediate revisions by 3 users not shown)
Line 1: Line 1:
== What resource file types are supported by LRM?==
+
== What resource file types are supported by Localyzer?==
  +
=== Standard Localyzer extensions ===
The Lingoport Resource Manager supports the following file types:
 
 
<ul>
 
<ul>
  +
<li><b>[[LRM html Support | .htm and .html]]</b> files using the [[LRM_html_Support#html_parser_type | ''html'']] parser</li>
<li><b>[[LRM JSON Support | .json]]</b> (with some restrictions for L10n purposes - See below for format of .json as resource bundles - Mostly JavaScript, and other programming languages)</li>
 
  +
<li><b>[[LRM JSON Support | .json]]</b> (Mostly JavaScript, and other programming languages) using the [[LRM_JSON_Support#json_parser_type | ''json'']] parser</li>
<li><b>.msg</b> (C, C++, ...)</li>
 
  +
<li><b>[[LRM msg Support|.msg]]</b> (C, C++, ...) using the [[LRM_msg_Support#msg_parser_type|''msg'']] parser</li>
<li><b>.po</b> files </li>
 
<li> <b>[[ LRM Properties Support| .properties]]</b> files (for instance, Java-type resources) </li>
+
<li><b>[[LRM po Support|.po]]</b> files using the [[LRM_po_Support#po_parser_type|''po'']] parser</li>
<li><b>[[ LRM resx Support| .resx]]</b> files (used in the .Net world)</li>
+
<li> <b>[[ LRM Properties Support| .properties]]</b> files (Java-type resources) using [[LRM_Properties_Support#properties_parser_type|''properties'']] parser</li>
  +
<li><b>[[ LRM resx Support| .resx]]</b> files (used in the .Net world) using [[LRM_resx_Support#xml_parser_type_using_ResxParser.xml_format_definition|''xml'']] parser and the ResxParser.xml format definition</li>
<li><b>.rc</b> (Delphi, ...)</li>
 
  +
<li><b>[[LRM rc Support|.rc]]</b> (Delphi, ...) using the [[LRM_rc_Support#rc_parser_type|''rc'']] parser</li>
<li><b>.rjs</b> (for JavaScript)</li>
 
<li> <b>.rxml</b> (for xml)</li>
+
<li><b>[[LRM rjs Support|.rjs]]</b> (for JavaScript) using the [[LRM_rjs_Support#js_parser_type|''js'']] parser</li>
  +
<li> <b>[[LRM rxml Support|.rxml]]</b> using the [[LRM_rxml_Support#xml_parser_type_using_RxmlParser.xml_format_definition|''xml'']] parser and the RxmlParser.xml format definition)</li>
<li><b>.strings</b> (Mobile iOS)</li>
 
<li><b>[[LRM Android Support | strings.xml]]</b> (Android)</li>
+
<li><b>[[LRM strings Support|.strings]]</b> (Mobile iOS) using the [[LRM_strings_Support#strings_parser_type|''strings'']] parser</li>
  +
<li><b>[[LRM Android Support | strings.xml]]</b> (Android) using the [[LRM_Android_Support#xml_parser_type_using_AndroidParser.xml_format_definition|''xml'']] parser and the AndroidParser.xml format definition</li>
  +
<li><b>[[LRM text Support | .txt]]</b> files using the [[LRM_text_Support|''text'']] parser</li>
  +
<li><b>[[LRM yaml Support | .yaml, .yml]]</b> using the [[LRM_yaml_Support#Yaml_Parser|''yaml'']] parser</li>
  +
<li><b>[[LRM xhtml Support | .dita, .ditamap]]</b> using the [[LRM xhtml Support|''xhtml'']] parser and the [[Subfolder under locale folder|''Subfolder under locale folder'']] settings</li>
 
</ul>
 
</ul>
   
  +
=== Unique Extensions ===
== How to setup LRM for .properties ==
 
  +
Any file extension can be handled by Localyzer as long as the corresponding parser type is defined. The file must be able to be parsed correctly by the defined parser type or an error will occur. The parser types are:
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.
 
  +
<ul>
For more information, please refer to : http://en.wikipedia.org/wiki/.properties
 
  +
<li><b>[[LRM_Binary_Support| ''binary'']]</b> parser</li>
=== Lingoport Resource Manager Configuration ===
 
  +
<li><b>[[LRM_html_Support#html_parser_type | ''html'']]</b> parser</li>
LRM creates projects using a Project Definition XML file that contains information about the resources and types for translation. Here is a typical .xml definition for projects with .properties files.
 
  +
<li><b>[[LRM_rjs_Support#js_parser_type|''js'']]</b> parser</li>
  +
<li><b>[[LRM_JSON_Support#json_parser_type | ''json'']]</b> parser </li>
  +
<li><b>[[LRM_msg_Support#msg_parser_type|''msg'']]</b> parser</li>
  +
<li><b>[[LRM_po_Support#po_parser_type|''po'']]</b> parser</li>
  +
<li><b>[[LRM_Properties_Support#properties_parser_type|''properties'']]</b> parser</li>
  +
<li><b>[[LRM_rc_Support#rc_parser_type|''rc'']]</b> parser</li>
  +
<li><b>[[LRM_strings_Support#strings_parser_type|''strings'']]</b> parser</li>
  +
<li><b>[[LRM_text_Support|''text'']]</b> parser</li>
  +
<li><b>[[LRM_XML_Support|xml]]</b> parser</li>
  +
<li><b>[[LRM_yaml_Support|yaml]]</b> parser</li>
  +
</ul>
  +
  +
== Localyzer Configuration ==
  +
Localyzer creates projects using a [[Terms_and_Definitions#projectdefn|Project Definition XML]] file that contains information about the resources and types for translation and then calling the [[LRM_Commands_Reference#Project_Commands| Create Project Command]]. Here is a typical .xml definition for projects with .properties files.
  +
  +
Note-a project should be created using '''either''' the project definition file directly or through the Jenkins LRM Plugin.
  +
  +
=== Project Info ===
  +
Project information includes the following:
  +
* Project Name - the repository name. This '''cannot be changed''' once the project is created.
  +
* Project desc - description, if any, for the project
  +
* Group Name - the owner of the repository. This '''cannot be changed''' once the project is created.
  +
* Top Level Directory - The top level directory is an absolute path. Usually it is something like '''<code>/var/lib/jenkins/jobs/Acme.wiley/workspace</code>'''. There are times where there is 1 repository for multiple projects. In this case the top level directory may be '''<code>/var/lib/jenkins/jobs/Acme.wiley/workspace/wileyProject1</code>'''. This value '''cannot be changed''' once the project is created.
  +
  +
==== ProjectDefinition.xml example ====
  +
This example is the project info for the ''wiley'' repository under the ''Acme'' group. (Under git, ''Acme'' would be the owner of the ''wiley'' repo)
  +
&lt;project-name&gt;wiley&lt;/project-name&gt;
  +
&lt;project-desc&gt;Wiley Project&lt;/project-desc&gt;
  +
&lt;group-name&gt;Acme&lt;/group-name&gt;
  +
&lt;top-level-dir&gt;/var/lib/jenkins/jobs/Acme.wiley/workspace&lt;/top-level-dir&gt;
  +
  +
=== Detect Errors Flags ===
  +
These flags direct Localyzer on the types of errors to detect.
  +
* Missed Translations - If set to ''1'', then a ''Missed Translation'' error will occur if the base resource file text is the same as the translated file text. Usually this flag is set to '''0'''.
  +
* Parameter Mismatch Error - If set to ''1'' then a ''Parameter Mismatch'' error will occur if the parameters in the translated file do not match the base resource file parameters.
  +
  +
==== ProjectDefinition.xml example ====
  +
A project setup with the following detect error flags will not detect missed translations but will detect parameter mismatch errors.
  +
  +
&lt;detect-errors&gt;
  +
&lt;missed-trans-error&gt;0&lt;/missed-trans-error&gt;
  +
&lt;parameter-mismatch-error&gt;1&lt;/parameter-mismatch-error&gt;
  +
&lt;detect-errors&gt;
  +
  +
=== Locales ===
   
  +
There are 3 types of java locales, that can be defined in a project:
This will create a project called '''com.company.project''' in the group '''SVNFTP'''. The resource files are located in the '''<code>/var/lib/jenkins/jobs/SVNFTP.com.company.project/workspace</code>''' directory. The resources are targeting six different locales. The resource files to be translated are .properties files.
 
  +
* Pseudo Locale - The locale for the project's pseudo-locale files.
 
  +
* Target locales - Must be exclusive of the project's base and pseudo-locales.
<pre>
 
  +
* Base Locale - The locale of the project's base resource file.
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
 
<lrmconf>
 
<model-version>2.0.12</model-version>
 
<project-name>com.company.project</project-name>
 
<project-desc>This is a sample LRM Project definition file, configured to support Java properties files</project-desc>
 
<!--group-name contains the group name that the LRM license is under-->
 
<group-name>SVNFTP</group-name>
 
<top-level-dir>/var/lib/jenkins/jobs/SVNFTP.com.company.project/workspace</top-level-dir>
 
<detect-errors>
 
<!--If set to '0' (false), then the 'missed translation' error will not be triggered-->
 
<missed-trans-error>0</missed-trans-error>
 
<parameter-mismatch-error>1</parameter-mismatch-error>
 
</detect-errors>
 
<pseudo-locale>eo</pseudo-locale>
 
<target-locales>
 
<locale>fr</locale>
 
<locale>de_DE</locale>
 
<locale>slv</locale>
 
<locale>nob_NO_UNI</locale>
 
<locale>zh_Hant</locale>
 
<locale>ZHT_Hans</locale>
 
</target-locales>
 
<resource-extension>
 
<extension>properties</extension>
 
<file-name-pattern>*_l_c_v</file-name-pattern>
 
<!--If the base resource files use the file-name-pattern in their name -->
 
<!--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>
 
<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>
 
<!--Default pattern for properties is '![CDATA[\{\d+\}|%[ds]]]'-->
 
<parameter-regex-pattern><![CDATA[\{\w+\}|%[ds]]]></parameter-regex-pattern>
 
</resource-extension>
 
</resource-extensions>
 
</lrmconf>
 
</pre>
 
   
  +
==== ProjectDefinition.xml example ====
== What is resx files encoding?==
 
  +
The following defines ''eo'' as the pseudo-locale, ''en'' as the base locale and ''fr_FR'', ''de_DE'' (case sensitive) as the target locales. The locales defined are in the format of a java locale (using underscores) and may not reflect the name of the resource files. The file name patterns are defined [[Supported_Resource_Bundles#Resource_Extensions|here]].
.Net resx files must be UTF-8 encoded, as per the resx schema, Hence, on-boarding resx resource files with LRM must specify the UTF-8 encoding:
 
   
  +
&lt;pseudo-locale&gt;eo&lt;/pseudo-locale&gt;
  +
&lt;target-locales&gt;
  +
&lt;locale&gt;fr_FR&lt;/locale&gt;
  +
&lt;locale&gt;de_DE&lt;/locale&gt;
  +
&lt;/target-locales&gt;
  +
&lt;default-locale&gt;en&lt;/default-locale&gt;
   
  +
=== Resource Extensions ===
https://msdn.microsoft.com/en-us/library/ekyft91f%28v=VS.90%29.aspx
 
  +
A Localyzer project can have multiple extensions defined. The information need per extension is:
  +
* '''extension''' - this can be one of the [[Supported_Resource_Bundles#Standard_LRM_extensions|Localyzer standard extensions]] or a [[Supported_Resource_Bundles#Unique_Extensions|unique extension]].
  +
* '''parser-type''' - A parser-type is required for unique extension.
  +
* '''file name pattern''' - if applicable, this is the pattern for the name of project's resource files. For example, the translated file names ''file1_zh-Hans_HK.rc'', ''file1_fr.rc'' and ''file1_de-de.rc'' would have the pattern ''*_l-c_v''. Where ''l'' is the language, ''c'' is the country/script and ''v'' is the variant/region.
  +
* '''use name pattern on default locale flag'''- If the base resource files use the file-name-pattern in their name then this flag is ''1'' otherwise ''0''. For example, the base resource file ''file1.rc'' does not have a pattern so the flag would be ''0''.
  +
* '''file location pattern''' - if applicable, this is the pattern for the folders containing the resource files. These folder can be of 2 types:
  +
** Language pattern - For example, ''*-l_c_v'' where the folder containing the English resource files could be ''values-en''.
  +
** Microsoft LCID code pattern - For example, ''*_LCID'' where the folder containing the English(US) (en_us) resource files could be ''values_1033''.
  +
:The location pattern may contain a wildcard for directory names. These are all valid location patterns:
  +
:* ''*-l-c-v/*/*'' - directory depth is 3
  +
:* ''*-l-c-v/some*folder'' - directory depth is 2
  +
:* ''*_LCID/*/*/locales'' - directory depth is 4
  +
:The location pattern '''can not''' contain wildcards for directory depth (**). These are '''invalid''' location patterns:
  +
:* ''*-l-c-v/**'' (INVALID)
  +
:* ''*-l-c-v/**/locales'' (INVALID)
  +
* '''use location pattern on default locale flag''' - If the folder, containing the base resource files, use the pattern then this flag is ''1'' otherwise ''0''.
  +
* '''encoding''' for the base and non-base resource files - Usually this will be UTF-8.
  +
* '''parameter-regex-pattern''' - This defines the regex pattern for parameters such as formatting and messaging.
   
  +
==== ProjectDefinition.xml example ====
<pre>
 
  +
The following will define the following directory structure.
<?xml version="1.0" encoding="utf-8"?>
 
<root>
 
<xsd:schema id="root" xmlns="" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
 
xmlns:msdata="urn:schemas-microsoft-com:xml-msdata">
 
<xsd:element name="data">
 
<xsd:complexType>
 
<xsd:sequence>
 
<xsd:element name="value" type="xsd:string" minOccurs="0"
 
msdata:Ordinal="2" />
 
</xsd:sequence>
 
<xsd:attribute name="name" type="xsd:string" />
 
<xsd:attribute name="type" type="xsd:string" />
 
<xsd:attribute name="mimetype" type="xsd:string" />
 
</xsd:complexType>
 
</xsd:element>
 
   
  +
src
</pre>
 
  +
: resources
  +
:: ''file1_en-US.xml''
  +
:: ''file1_fr-FR.xml''
  +
:: ''file1_de-DE.xml''
  +
: values
  +
:: ''example.resx''
  +
: values-1033
  +
:: ''example.resx''
  +
: values-1036
  +
:: ''example.resx''
   
  +
&lt;resource-extensions&gt;
== In what format should JSON Files be for LRM Handling ?==
 
  +
&lt;resource-extension&gt;
The JSON extension is supported in Lingoport Resource Manager (LRM). Well-formed JSON is required and specified by http://www.ietf.org/rfc/rfc4627.txt. In order to detect and import changes, LRM 2.1 requires JSON files to also adhere to the following standards.
 
  +
&lt;extension&gt;resx&lt;/extension&gt;
* The json files must follow this naming convention: '''filename_<locale>.json''' or '''filename_<locale>_<country>.json'''. For example, '''resources_en.json''' or resources_en_US.json, '''resources_fr.json''' or resources_fr_FR.json, etc.
 
  +
&lt;file-name-pattern/&gt;
* '''If you can, avoid duplicate file names'''. Duplications incur more prep kits than necessary.
 
  +
&lt;use-pattern-on-dflt-locale&gt;0&lt;/use-pattern-on-dflt-locale&gt;
*'''Arrays are not allowed in the context of JSON files as resource bundles'''. String references in the code, from an i18n point of view, is unmanageable for JSON arrays. In addition, many L10n vendors do not support JSON arrays. (Sample JSON files are located in LRM-Server-2.1/''samples/JSON_Examples''):
 
  +
&lt;file-location-pattern&gt;*-LCID&lt;/file-location-pattern&gt;
* '''There is only one key/value per line.'''
 
  +
&lt;use-location-pattern-on-dflt-locale&gt;0&lt;/use-location-pattern-on-dflt-locale&gt;
* <b>End-object character (curly bracket) may not exist on the same line as a key/value</b>.
 
  +
&lt;base-file-encoding&gt;UTF-8&lt;/base-file-encoding&gt;
* <b>Values associated with a key must be a string</b>. Numeric and boolean values are not allowed.
 
  +
&lt;localized-file-encoding&gt;UTF-8&lt;/localized-file-encoding&gt;
  +
&lt;parameter-regex-pattern&gt;&lt;![CDATA[%[ds]|%\d+\$[ds]|%\{\w+\}]]&gt;&lt;/parameter-regex-pattern&gt;
  +
&lt;/resource-extension&gt;
  +
&lt;resource-extension&gt;
  +
&lt;extension&gt;xml&lt;/extension&gt;
  +
&lt;file-name-pattern&gt;*_l-c-v&lt;/file-name-pattern&gt;
  +
&lt;use-pattern-on-dflt-locale&gt;1&lt;/use-pattern-on-dflt-locale&gt;
  +
&lt;file-location-pattern/&gt;
  +
&lt;use-location-pattern-on-dflt-locale&gt;0&lt;/use-location-pattern-on-dflt-locale&gt;
  +
&lt;base-file-encoding&gt;UTF-8&lt;/base-file-encoding&gt;
  +
&lt;localized-file-encoding&gt;UTF-8&lt;/localized-file-encoding&gt;
  +
&lt;parameter-regex-pattern&gt;&lt;![CDATA[%d|%s|%\d+\$s|%\d+\$d|%\{\w+\}]]&gt;&lt;/parameter-regex-pattern&gt;
  +
&lt;/resource-extension&gt;
  +
&lt;/resource-extensions&gt;
   
  +
=== Include/Exclude Files/Directories ===
For more detailed information on the above, please go to the [[LRM JSON Support | .json]] support page.
 
  +
The include portion of the project definition can be used to include folder or files from the search for resource files. The default is all folders and files will be included.
   
  +
The exclude portion of the project definition can be used to exclude folder or files from the search for resource files. The default is that no folders/files will be excluded.
== 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.
 
For example, if a comment doesn't have an ending '''*/''', such as '''/*Bad comment'''
 
no errors are found.
 
   
  +
==== ProjectDefinition.xml example ====
This is due to the formatting of iOS. This type of bad comments would typically be created on the base files.
 
  +
The following definition directs the search to only those resource files with ''src'' as a top-level directory. Any resource files under a ''test'' folder will be ignored as well as the ''config.properties'' file.
   
  +
&lt;dirset&gt;
<b>Note</b> ''key/value'' pairs are not effected. Noticed when '''LRM_RESEND''' tag was added,
 
  +
&lt;includes&gt;
the info in the Changed Key values included '''LRM_RESEND'''.
 
  +
&lt;include-dir-file&gt;**/src/**&lt;/include-dir-file&gt;
  +
&lt;/includes&gt;
  +
&lt;excludes&gt;
  +
&lt;exclude-dir-file&gt;**/test/**&lt;/exclude-dir-file&gt;
  +
&lt;exclude-dir-file&gt;**/config.properties&lt;/exclude-dir-file&gt;
  +
&lt;/excludes&gt;
  +
&lt;/dirset&gt;

Latest revision as of 19:53, 9 July 2021

What resource file types are supported by Localyzer?

Standard Localyzer extensions

Unique Extensions

Any file extension can be handled by Localyzer as long as the corresponding parser type is defined. The file must be able to be parsed correctly by the defined parser type or an error will occur. The parser types are:

Localyzer Configuration

Localyzer creates projects using a Project Definition XML file that contains information about the resources and types for translation and then calling the Create Project Command. Here is a typical .xml definition for projects with .properties files.

Note-a project should be created using either the project definition file directly or through the Jenkins LRM Plugin.

Project Info

Project information includes the following:

  • Project Name - the repository name. This cannot be changed once the project is created.
  • Project desc - description, if any, for the project
  • Group Name - the owner of the repository. This cannot be changed once the project is created.
  • Top Level Directory - The top level directory is an absolute path. Usually it is something like /var/lib/jenkins/jobs/Acme.wiley/workspace. There are times where there is 1 repository for multiple projects. In this case the top level directory may be /var/lib/jenkins/jobs/Acme.wiley/workspace/wileyProject1. This value cannot be changed once the project is created.

ProjectDefinition.xml example

This example is the project info for the wiley repository under the Acme group. (Under git, Acme would be the owner of the wiley repo)

<project-name>wiley</project-name>
<project-desc>Wiley Project</project-desc>
<group-name>Acme</group-name>
<top-level-dir>/var/lib/jenkins/jobs/Acme.wiley/workspace</top-level-dir>

Detect Errors Flags

These flags direct Localyzer on the types of errors to detect.

  • Missed Translations - If set to 1, then a Missed Translation error will occur if the base resource file text is the same as the translated file text. Usually this flag is set to 0.
  • Parameter Mismatch Error - If set to 1 then a Parameter Mismatch error will occur if the parameters in the translated file do not match the base resource file parameters.

ProjectDefinition.xml example

A project setup with the following detect error flags will not detect missed translations but will detect parameter mismatch errors.

<detect-errors>
  <missed-trans-error>0</missed-trans-error>
  <parameter-mismatch-error>1</parameter-mismatch-error>
<detect-errors>

Locales

There are 3 types of java locales, that can be defined in a project:

  • Pseudo Locale - The locale for the project's pseudo-locale files.
  • Target locales - Must be exclusive of the project's base and pseudo-locales.
  • Base Locale - The locale of the project's base resource file.

ProjectDefinition.xml example

The following defines eo as the pseudo-locale, en as the base locale and fr_FR, de_DE (case sensitive) as the target locales. The locales defined are in the format of a java locale (using underscores) and may not reflect the name of the resource files. The file name patterns are defined here.

 <pseudo-locale>eo</pseudo-locale>
 <target-locales>
   <locale>fr_FR</locale>
   <locale>de_DE</locale>
 </target-locales>
 <default-locale>en</default-locale>

Resource Extensions

A Localyzer project can have multiple extensions defined. The information need per extension is:

  • extension - this can be one of the Localyzer standard extensions or a unique extension.
  • parser-type - A parser-type is required for unique extension.
  • file name pattern - if applicable, this is the pattern for the name of project's resource files. For example, the translated file names file1_zh-Hans_HK.rc, file1_fr.rc and file1_de-de.rc would have the pattern *_l-c_v. Where l is the language, c is the country/script and v is the variant/region.
  • use name pattern on default locale flag- If the base resource files use the file-name-pattern in their name then this flag is 1 otherwise 0. For example, the base resource file file1.rc does not have a pattern so the flag would be 0.
  • file location pattern - if applicable, this is the pattern for the folders containing the resource files. These folder can be of 2 types:
    • Language pattern - For example, *-l_c_v where the folder containing the English resource files could be values-en.
    • Microsoft LCID code pattern - For example, *_LCID where the folder containing the English(US) (en_us) resource files could be values_1033.
The location pattern may contain a wildcard for directory names. These are all valid location patterns:
  • *-l-c-v/*/* - directory depth is 3
  • *-l-c-v/some*folder - directory depth is 2
  • *_LCID/*/*/locales - directory depth is 4
The location pattern can not contain wildcards for directory depth (**). These are invalid location patterns:
  • *-l-c-v/** (INVALID)
  • *-l-c-v/**/locales (INVALID)
  • use location pattern on default locale flag - If the folder, containing the base resource files, use the pattern then this flag is 1 otherwise 0.
  • encoding for the base and non-base resource files - Usually this will be UTF-8.
  • parameter-regex-pattern - This defines the regex pattern for parameters such as formatting and messaging.

ProjectDefinition.xml example

The following will define the following directory structure.

src

resources
file1_en-US.xml
file1_fr-FR.xml
file1_de-DE.xml
values
example.resx
values-1033
example.resx
values-1036
example.resx
<resource-extensions>
   <resource-extension>
     <extension>resx</extension>
     <file-name-pattern/>
     <use-pattern-on-dflt-locale>0</use-pattern-on-dflt-locale>
     <file-location-pattern>*-LCID</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[%[ds]|%\d+\$[ds]|%\{\w+\}]]></parameter-regex-pattern>
   </resource-extension>
   <resource-extension>
     <extension>xml</extension>
     <file-name-pattern>*_l-c-v</file-name-pattern>
     <use-pattern-on-dflt-locale>1</use-pattern-on-dflt-locale>
     <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[%d|%s|%\d+\$s|%\d+\$d|%\{\w+\}]]></parameter-regex-pattern>
   </resource-extension>
</resource-extensions>

Include/Exclude Files/Directories

The include portion of the project definition can be used to include folder or files from the search for resource files. The default is all folders and files will be included.

The exclude portion of the project definition can be used to exclude folder or files from the search for resource files. The default is that no folders/files will be excluded.

ProjectDefinition.xml example

The following definition directs the search to only those resource files with src as a top-level directory. Any resource files under a test folder will be ignored as well as the config.properties file.

 <dirset>
   <includes>
     <include-dir-file>**/src/**</include-dir-file>
   </includes>
   <excludes>
     <exclude-dir-file>**/test/**</exclude-dir-file>
     <exclude-dir-file>**/config.properties</exclude-dir-file>
   </excludes>
 </dirset>