i18n/l10n question

[Novice]

This is basically a variant on the "additional logging questions" thread
I just started but with a focus on i18n.

I'd like all of my classes to be locale-sensitive so that all of the
things they are displaying in GUIs, including text and error messages,
are displayed in the user's language (or, more precisely, the language in
the resource bundle that is the "closest fit" to the language of the
user).

Given that my programs instantiate a variety of classes that themselves
display text or error messages, those classes also need to know what
locale the program is using. Would I be right to pass a reference to the
locale of the main program to each class that it instantiates? Or should
I be doing things differently?

Also, what if a class isn't GUI-related at all? Should I still pass a
locale anyway? Again, I'm thinking of things like Enums. I wouldn't
normally expect an Enum to display text of any kind to a user, at least
directly. (The enum might determine that day number 1 in the week is
Monday and pass Monday to a class that displays that but the enum itself
isn't displaying Monday.) What about a holder class (again, assuming I'm
using that term correctly; I described my guess in the "additional
logging questions" thread): I don't see much need for it to ever display
text to a user (or an error message).

And what about logs? I know that the java.util.logging classes provide
for resource bundles so that the messages in the logs can be in other
languages. How common is it for log messages to be in languages other
than English? I have no experience with that. So much computer-related
stuff seems to be in English first (or English only) that I'm not sure if
a European company, say, would write log messages in English even if it
isn't the main local language (in Germany say) or would they often write
them in the local language?

 

[Arne Vajhøj]

This is basically a variant on the "additional logging questions" thread
I just started but with a focus on i18n.

I'd like all of my classes to be locale-sensitive so that all of the
things they are displaying in GUIs, including text and error messages,
are displayed in the user's language (or, more precisely, the language in
the resource bundle that is the "closest fit" to the language of the
user).

Given that my programs instantiate a variety of classes that themselves
display text or error messages, those classes also need to know what
locale the program is using. Would I be right to pass a reference to the
locale of the main program to each class that it instantiates? Or should
I be doing things differently?

I would prefer something global.

Local setDefault seems intended for this usage.

Also, what if a class isn't GUI-related at all? Should I still pass a
locale anyway? Again, I'm thinking of things like Enums. I wouldn't
normally expect an Enum to display text of any kind to a user, at least
directly. (The enum might determine that day number 1 in the week is
Monday and pass Monday to a class that displays that but the enum itself
isn't displaying Monday.) What about a holder class (again, assuming I'm
using that term correctly; I described my guess in the "additional
logging questions" thread): I don't see much need for it to ever display
text to a user (or an error message).

If you use the above, then classes that need it can access the locale.

And what about logs? I know that the java.util.logging classes provide
for resource bundles so that the messages in the logs can be in other
languages. How common is it for log messages to be in languages other
than English? I have no experience with that. So much computer-related
stuff seems to be in English first (or English only) that I'm not sure if
a European company, say, would write log messages in English even if it
isn't the main local language (in Germany say) or would they often write
them in the local language?

You should argue hard to keep logging in English. It may make a lot
of sense to use local language for end user GUI's, but logging is for
developers and developers can read English.

Whether you will succeed or not depends. A few countries are a bit
sensitive about language.

In France and Germany you may be requested to do everything in
French/German.

In Scandinavia then English will be accepted without discussion.

Arne

 

[Novice]

I would prefer something global.

Local setDefault seems intended for this usage.

If I'm following you correctly then, the program that is running should
obtain the desired Locale - probably via JVM parameters -Duser.country
and -Duser.language but maybe from a menu in the GUI - then do
Locale.setDefault(). Then all classes instantiated by that class should
just do Locale.getDefault() locally so that they use the same locale. Is
that about right?

If you use the above, then classes that need it can access the locale.


You should argue hard to keep logging in English. It may make a lot
of sense to use local language for end user GUI's, but logging is for
developers and developers can read English.

That's interesting. I've certainly had the impression from all the people
in technical newsgroups - and even many non-technical ones! - who are
obviously fluent in English even though they are from non-English
speaking countries. But I've travelled a bit too, mostly in Europe, and
have been pleasantly surprised to find out how widely English is spoken,
in countries like the Netherlands or Germany.

Whether you will succeed or not depends. A few countries are a bit
sensitive about language.

In France and Germany you may be requested to do everything in
French/German.

Fair enough. Naturally, if I'm working for someone else, I'll write
whatever language the employer wants.

In Scandinavia then English will be accepted without discussion.

Interesting.I've always been pleasantly surprised to find English in more
places than I expected. I remember meeting a friend's sister once. They
are ethnic Vietnamese but the sister had been living in France since they
left Vietnam and spoke very good English although she had little
education in it. She told me that she'd learned it from technical
manuals. She was a system programmer and apparently they used the English
manuals for that system ;-)

 

[Arne Vajhøj]

If I'm following you correctly then, the program that is running should
obtain the desired Locale - probably via JVM parameters -Duser.country
and -Duser.language but maybe from a menu in the GUI - then do
Locale.setDefault(). Then all classes instantiated by that class should
just do Locale.getDefault() locally so that they use the same locale. Is
that about right?

I think that you need to use the -D's *or* (not and) use Locale.setDefault,
but else yes.

Arne

 

[David Lamb]

I'd like all of my classes to be locale-sensitive so that all of the
things they are displaying in GUIs, including text and error messages,
are displayed in the user's language (or, more precisely, the language in
the resource bundle that is the "closest fit" to the language of the
user).

My approach might be excessively convoluted, but I think it's
appropriately more general that just getting the default locale.

I have written and experimental program where the user might want to
change locale while running the program, because they were demonstrating
something to a non-native speaker on a machine where they wouldn't want
to exit and restart with new locale parameters. Haven't had a chance to
get very far yet, but I thought it might be useful in my
university-level teaching environment where we get a lot of
international students.

In this case, the individual packages that report to users get told what
the locale is and have to be prepared to have some package-appropriate
collection of Observer class(es) be told to change in mid-stream. A
package would have to register its Observer(s) with a central authority,
which authority then reacts to GUI operations (such as a collection of
language-specific menus, or a dialog box to set locale arbitrarily). Of
course there also has to be some associated method for getting the
localization strings but that's already well understood as involving
property files or XML files.

I really have to get back to that experiment; given all those
international students it ought to be possible to get everything
translated for some small example program.

 

[Novice]

My approach might be excessively convoluted, but I think it's
appropriately more general that just getting the default locale.

I have written and experimental program where the user might want to
change locale while running the program, because they were
demonstrating something to a non-native speaker on a machine where
they wouldn't want to exit and restart with new locale parameters.
Haven't had a chance to get very far yet, but I thought it might be
useful in my university-level teaching environment where we get a lot
of international students.

In this case, the individual packages that report to users get told
what the locale is and have to be prepared to have some
package-appropriate collection of Observer class(es) be told to change
in mid-stream. A package would have to register its Observer(s) with a
central authority, which authority then reacts to GUI operations (such
as a collection of language-specific menus, or a dialog box to set
locale arbitrarily). Of course there also has to be some associated
method for getting the localization strings but that's already well
understood as involving property files or XML files.

That does seem excessively convoluted to me.

I dabbled in changing locales on the fly and actually got it to work with
a lot less effort than you are describing. I simply gave the user a menu
option for language on a JMenuBar with text showing the name of the
language in that language and an appropriate flag so that if the language
was, say Japanese, the menu would say "Japan" in Kanji and have a little
icon of a Japanese flag. One click and the GUI would change to that
language. Of course that is all the user sees which is the easiest part
of the thing. But under the covers, the code isn't that hard either and
didn't involve any XML files or Observers. I simply used the existing
Resource Bundle mechanisms to write Text files (the ones that are
basically just key/value pairs) and, where necessary, Message files (for
text containing variables) and List files (for more complex data like
arrays). I created translated versions of those files with Google
Translate which is free and fast. They are not great translations since
they are basically looking a word up in a dictionary and then seeing what
the equivalent word is in the other language, but a friend who is very
fluent in French told me that its French translations would
comprehensible by French speakers, even if they would scratch their heads
at the unrealistic way that some things were rendered. Then I simply
redrew the text on the GUI using the new language's Resource files.

But I decided that I didn't really need the ability to change the
language on the fly in any real program. The vast majority of
international users will already have their preferred language indicated
in their operating system and Java is perfectly capable of determining
that language very easily when the program starts. So I simply use that
information to grab the appropriate Resources. And the existing Java
mechanisms ensure that if the user prefers a language for which I don't
have a resource bundle, they get either something close - a Francophone
Quebecker may have to settle for a European French bundle - or a default
language, which is English in my case. That's all I really need so my
code is simpler as a result since it doesn't need the menu for choosing
the language and I don't need to redraw the GUI when the language
changes.

My post was really only about recommendations for the best way to pass
the locale from my main class to the classes that are instantiated from
it. And I'm now satisfied that Arne's suggestion of setting the default
locale in the main program and then querying it locally in the
instantiated classes is the best way to go on that, rather than passing a
reference from the main program to its dependents.

I really have to get back to that experiment; given all those
international students it ought to be possible to get everything
translated for some small example program.

If you're looking for really good translations, Google Translate is not
the way to go, at least not yet. Maybe someday it will do top-notch
translations as the AI gets better. I certainly wouldn't translate an
important legal document like a business contract or treaty with it! But
for use in a classroom to demonstrate the ability to localize text, I'd
expect it would be perfectly satisfactory. The students will probably
even get a laugh at some of the translations ;-)

But if you're worried about causing international incidents, you can
always get professional translations done.

 

[David Lamb]

That does seem excessively convoluted to me.

One click and the GUI would change to that
language. Of course that is all the user sees which is the easiest part
of the thing.

Right, and that's pretty much how my GUI behaved too.

But under the covers, the code isn't that hard either and
didn't involve any XML files or Observers. I simply used the existing
Resource Bundle mechanisms to write Text files (the ones that are
basically just key/value pairs)

I currently use resource bundles, too; when I started to look at XML
versions of resource specification, one of the attractions was making
Unicode text easier to use. Most of the rest of the mechanisms were
about the same as yours.

But I decided that I didn't really need the ability to change the
language on the fly in any real program. The vast majority of
international users will already have their preferred language indicated
in their operating system and Java is perfectly capable of determining
that language very easily when the program starts.

For sure -- though I object a little to "real program" (I'd accept
"common"). But I mentioned one very specific circumstance where the OS'
default (or the Java invocation's command line options) wasn't adequate.
If you accept that *sometimes* that's what you want to do, all the
resource file mechanisms remain the same but you add observers so GUI
components know when they have to change. And not all GUI components:
just the "top level" ones that know how to find and modify (or
regenerate) their relevant sub-components.

It's not all that different from what you do; just a little more
flexible for the occasional situation that needs a bit more functionality.