Set the following values in the Globalyzer String
Externalization view:
Resource File Type: properties
Resource File Frequency: Project
Retrieval Method: getString("[key]")
Use/Generate Static Retrieval Class: Checked
Retrieval Class Package: com.lingoport.demo.java.utils
(Note: Using the Browse... button to fill in Retrieval
Class Name will fill in this section automatically.)
Retrieval Class Name: I18nUtils (Note: use the Browse...
button and begin typing for auto-completion of the class name.)
String Key Next ID: 1
Share Strings: Checked
Externalized String Comment: GLOBALYZER_EXTERNALIZED_TEXT:
Resource File Path: [path to source
files]/com/lingoport/demo/java/resources/exampleResources.properties
(Note: You can browse to the directory for easier setting.)
Resource File Encoding: UTF-8
Your settings should look like this:
Let's look at what these settings mean.
First, note that the term externalize refers to replacing
embedded text in source files with a method call to retrieve the
text from a resource file. Globalyzer's String Externalization
feature automatically extracts embedded display text, such as
button names or error messages, from the source and places the
text in a resource file with a unique key that identifies it.
The Resource File Type is set to properties. This
tells Globalyzer to place externalized strings in a Java-style
resource file. Other options are available for other programming
languages, and new ones are added as Globalyzer continues being
developed. If you need a specific resource type and you don't see
it in the list, please contact us at support@lingoport.com.
The Resource File Frequency is set to Project. This
means that only one resource file will be created for this
project. The other option, Source File, specifies that a
unique resource file will be created for each source file that
contains externalized display text.
The Retrieval Method specifies a fully qualified method
name that will be used to retrieve text from the resource file.
The actual name of this method is generally specific to each
system architecture. In this case, the method
getString("[key]")
is the com.lingoport.demo.java.utils.I18nUtils method name used
in the tutorial example code.
If your framework does not have a resource management class
(like the I18n class in our simple example), using the same
settings, Globalyzer will generate the class. In this case, the
first time Globalyzer externalizes an embedded string, it will
create a default class for string retrieval in the base source
directory.
Either way, a package import statement will be inserted at
the top of each source file when a string is first externalized
from the file.
In the source files, the following pattern is repeated to
retrieve strings from your exampleResources.properties
file:
I18nUtils.getString("ID_TO_RESOURCE")
Note that the I18nUtils class is just a simple example with
a locale set to French in France. For your own projects, the code
will vary depending on your particular system architecture; the
locale object might be created from information in a
configuration file, a database, or through some other mechanism.
As noted previously, each string that is externalized is assigned
a unique identifying key. To ensure uniqueness, the current String
Key Next ID is appended to the identifying key and then
incremented.
By selecting Share Strings , Globalyzer reuses
the same key/value pair for identical embedded strings. In other
words, only one key/value would be generated for each Cancel
string in the application.
The Externalized String Comment field shows the default
comment used when you externalize strings. For example, if you
checked the Automatically Insert Externalized String
Comment option in the Globalyzer Preferences dialog, and
then externalized the string Hello World!, the following
would be inserted in your source code, above the line of code
where the embedded string was found:
/*GLOBALYZER_EXTERNALIZED_TEXT: Hello World!*/
By default, the Resource File Path is set to create
the properties file in the Project's base path. The properties
filename is based on the Project name, for instance here JavaTutorial.properties.
In this section, you modified the path so the properties file
goes under the resources directory with a different name.
Because the Resource File Frequency is set to Project,
this resource file will be used to store the key/value pairs for
the entire Project.
Finally, the Resource File Encoding should be set to UTF-8, as this is
the preferred encoding of properties files. Globalyzer will assume all your resource files
of this type are the same encoding, although it will ensure that if a resource file has
BOM bytes (bytes at the beginning of the file that indicate encoding), it will access the
file properly, regardless the Project's Resource File Encoding setting. To see the
encoding of an individual file, right-click on the file in the Project Explorer view
and select Properties.
Note: In a Java application, you will run the utility native2ascii on your
UTF-8 encoded properties files, which will Unicode-encode each non-ASCII character.
