Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #12526

Re: i18n/l10n question

Show all headers | View raw

David Lamb <dalamb@cs.queensu.ca> wrote in
news:jiigt7$k6c$1@dont-email.me: 

> On 26/02/2012 9:16 PM, Novice wrote:
>> 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.
>
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.

-- 
Novice

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

i18n/l10n question Novice <novice@example..com> - 2012-02-27 02:16 +0000
  Re: i18n/l10n question Arne Vajhøj <arne@vajhoej.dk> - 2012-02-26 21:31 -0500
    Re: i18n/l10n question Novice <novice@example..com> - 2012-02-27 04:30 +0000
      Re: i18n/l10n question Arne Vajhøj <arne@vajhoej.dk> - 2012-02-27 17:01 -0500
  Re: i18n/l10n question David Lamb <dalamb@cs.queensu.ca> - 2012-02-28 07:21 -0500
    Re: i18n/l10n question Novice <novice@example..com> - 2012-02-29 14:46 +0000
      Re: i18n/l10n question David Lamb <dalamb@cs.queensu.ca> - 2012-03-10 09:13 -0500

csiph-web