jferrai at us.ibm.com
Tue Jul 1 08:43:25 PDT 2008
We need to make decisions about localization. It's the last big issue that
I know of with the metadata spec.
As I remember, we have talked about 3 different aspects to localization.
Below is a quick discussion of each aspect to localization and then a
proposal for how to proceed.
(1) We have already agreed that various text strings in the metadata are
localizable and that the strings to localize would be identified via the
syntax %%key%%, where key is the lookup index into the localization
tables.The only open issues in this area that I can think of is a
processing model detail. I assume that the way to implement the
substitution is that you find all of the %%whatever%% strings and look for
"whatever" in the localization tables. If "whatever" is there, then perform
the substitution. But what if "whatever" is not in the localization tables?
PROPOSAL: My thinking is that you perform no substitution in this case and
the string %%whatever%% (with the percent signs) appears to the user.
(2) We are in general agreement that we need to support message files,
where there can be a message file for various languages that contains
A few months ago we had a debate about whether the message files should be
__ <message name="yes">oui</message>
or use syntax like Java property files:
The spec as it stands now should the latter approach, although some people
felt strongly that XML would be better.
According to the spec as it stands now, message files would be discoverable
due to file naming, such as "localizations/fr/messages.xml" or
"localizations/messages_fr.txt". We haven't worked out the details on the
discover issues yet.
Since we had our internal discussions, Google Gadgets announced their
approach to localization (
http://code.google.com/apis/gadgets/docs/i18n.html). The use XML. Here is
They promote the convention that message files are named as follows:
<language>_<country>.xml . The default message file is named ALL_ALL.xml
and "ALL" you can say things like "de_ALL.xml". They expect that you will
list all of your localization files in the widget metadata, as in:
<ModulePrefs title="i18n Example">
PROPOSAL: Use the Gadgets approach as our starting point (i.e., support
<messagebundle>, <msg>, and <Locale>). We might add a feature or two on top
of Gadgets, such as allowing the metadata to simply point to the root
directory for the localization files, versus requiring that each
localization file be listed. We also might allow more flexibility in how
localization files are named.
(3) Ability to identify substitution *files* (versus substitution strings).
W3C Widgets (http://dev.w3.org/2006/waf/widgets/#localization) has a
mechanism where you can use localized images or even localized HTML files.
You simply put language-specific directories in the distribution, as in:
es/main.html (Spanish version of main.html. Use this if the locale is "es")
PROPOSAL: We use the W3C approach as our starting point. We might add a
feature or two on top of W3C Widgets, such as allowing our metadata to
define where the substitution files are located.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the IDE