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

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

Re: i18n/l10n question

Show all headers | View raw

On 29/02/2012 9:46 AM, Novice wrote:
> 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.
>>
> 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.

Back to comp.lang.java.programmer | Previous | Next — Previous 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