|
|
|
- Overview |
|
The Properties Filter is an Okapi component that implements the Okapi Filter Interface for Properties files.
The filter is based on the specifications found in the
java.util.Properties class documentation. It supports also
additional format features for compatibility with other type of properties
files.
The following is an example of a very simple properties file. The translatable text is marked in bold.
# This is a comment Key1 : This the text for Key1 Key2 = This is the text for Key2 Key3 This is the \ text for Key3 Key4:This is the text for key4
The properties for the Properties Filter are the following:
| Property | This Filter |
|---|---|
| INPUTFILE | Yes |
| INPUTSTRING | Yes |
| BILINGUALINPUT | No |
| TEXTBASED | Yes |
| OUTPUTFILE | Yes |
| OUTPUTSTRING | Yes |
| ANCILLARYOUTPUT | No |
| XMLOUTPUT | No |
| RTFOUTPUT | Yes |
| USEKEY | No |
| ISINDEMOMODE | No |
To be compatible with other non-Java properties file, the encoding ISO-8859-1 is not assumed. The filter decides which encoding to use for the input file using the following logic:
The output encoding used is the one specified by the user.
The Properties Filter supports localization directives. They are special comments you can use to override the default behavior of the filter regarding the parts to extract.
The syntax and behavior of the directives are the same across all Okapi filters. See the Localization Directives pages for detail information about what you can do with the mechanism.
Note that the directives override key conditions.
The line-breaks type of the output are the same as the one of the original input.
Use localization directives when they are present -- Set this option to enable the filter to recognize localization directives. If this option is not set, any localization directive in the input file will be ignored.
Extract items outside the scope of localization directives -- Set this option to extract any translatable item that is not within the scope of a localization directive. Selecting to extract or not outside localization directives allows you to mark up fewer parts of the source document. This option is enabled only when the Use localization directives when they are present option is set.
See the Localization Directives section for more details on how the filter deals with directives.
Use Do-Not-Localize list if a DNL file is present -- Set this
option to enable the filter to utilize any Do-Not-Localize list file found along
with a given input file. The DNL file has the path and name as the input file,
with an additional .dnl extension. It contains a list of entries
that should not be extracted. Each entry is made of the resname, restype and
text of a filter item. Use the
DNL List Editing
utility to create and maintained DNL files.
Use the following key condition -- Set this option to extract items based on their keys. You specify a regular expression pattern, if the key matches the pattern, the item is extracted or not depending on the action you specify. Note that directives have precedence over key condition.
Extract only the items with a key matching the specified pattern -- Select this option to extract only the items with keys that match the specified pattern.
Do not extract the items with a key matching the specified pattern -- Select this option to not extract the items with keys that match the specified pattern.
Enter the pattern to test against the key. The pattern must be a valid regular expression. For example, with the following settings:
Use the following key condition = set Extract only the items with a key matching the specified pattern = set Pattern = .*text.*
The extracted text is highlighted:
key1 = Text for key1 text.err1 = Text for text.err1 menu_text_file = Text for menu_text_file
Support additional comments -- Set this option is take in
account other comments style in addition to the strict Java comments
(single-line starting with '#' or '!'). When this
option is set, the filter also recognizes comments single-lines starting with ';',
as well as single-line where '//' is the first no-whitespace
sequence. (Note that // after a = are considered part
of the value of the entry, not a comment).
Mark as inline codes the text parts matching this regular expression -- Set this option to use the specified regular expression to be use against the text of the extracted items. Any match will be converted to an inline code. By default the expression is:
((%(([-0+#]?)[-0+#]?)((\d\$)?)(([\d\*]*)(\.[\d\*]*)?)[dioxXucsfeEgGpn])
|((\\r\\n)|\\a|\\b|\\f|\\n|\\r|\\t|\\v)
|(\{\d.*?\}))
This matches the C-style printf variables (e.g. "%s",
"%2.3f", "%04X", "%1$d", etc.), the escaped sequences:
"\r\n", "\a", "\b",
"\f", "\n", "\r", "\t", and "\v",
as well as the Java MessageFormat patterns (e.g. "{0}",
"{3,number,integer}", etc.)
Edit Expression -- Click this button to edit the regular expression and its options. This button opens the Inline Codes Rules dialog box.
See the Regular Expressions section for more information about the syntax and rules for building regular matching patterns.
Escape all extended characters -- Set this option to convert all
character above U+007F into Unicode escape sequences (\uHHHH). When
this option is not set, only the characters not supported by the output encoding
are escaped.
Special thanks to Christian Lieske for some samples of properties files.