Path: csiph.com!usenet.pasdenom.info!aioe.org!eternal-september.org!feeder.eternal-september.org!mx04.eternal-september.org!.POSTED!not-for-mail From: David Lamb Newsgroups: comp.lang.java.programmer Subject: Re: i18n/l10n question Date: Sat, 10 Mar 2012 09:13:57 -0500 Organization: A noiseless patient Spider Lines: 49 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Sat, 10 Mar 2012 14:14:06 +0000 (UTC) Injection-Info: mx04.eternal-september.org; posting-host="w5ewJxsRgiUymlDHZo0DiA"; logging-data="17829"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/3PnETucZPWbnHEFcztq9u" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 In-Reply-To: Cancel-Lock: sha1:7xF3Agc9Mx7RvTxZK6O51G6GDVk= Xref: csiph.com comp.lang.java.programmer:12836 On 29/02/2012 9:46 AM, Novice wrote: > David Lamb 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.