• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

What is the best solution for allowing customized internationalization?

 
Greenhorn
Posts: 22
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I have a product that I would like to give to the customer. That customer would like the ability to customize some of the internationalized strings that the program uses. I would like it such that these customizations survive an upgrade of the product (ie: they reside in files outside of the product's structure).

I've come up with two possible solutions. They are "using the Locale's variant", and "classpath ordering". There are pros and cons to each solution. There are also other solutions that I haven't thought of.

Which of my solutions do you recommend? What other solutions for my problem are there?

My program uses property files to store the localized prompts.


Using the Locale's Variant
The Locale object has three fields: language, country and variant. When the program needs to display some internationalized text, it gets the locale and sets the variant field to "custom". Using this modified locale, the program then asks java to get the property file for this locale. Therefore, if the original locale was English/Great Britain, then after modifying the locale, java would look for the property resource "prompts_en_GB_custom.properties".

There's a great advantage to this solution: the customer only needs to over-ride the key-value pairs that he wants to customize. If the base "prompts.properties" file contains over 4000 entries and he only needs to modify one, then his custom properties file only contains one entry.

The disadvantage is that the locale's variant field is destroyed (it's always over-ridden to be "custom").


Classpath Ordering
In this solution, a "custom" directory is added to the beginning of the classpath. When the customer wants to customize some of the prompts, they copy the "prompts.properties" file that's specific to their locale to the "custom" directory and then modify the values they want customized.

The reason the entire file needs to be copied over is the way that java resolves resources: it scans the classpath until the filename has been found. In this case, the resource is the file, not the key within the file.

The pros and cons of this solution are the opposite of the previous solution.

Pro: the full locale is respected (the variant field is not destroyed).

Con: the entire file needs to be copied. This is a major con when it comes to upgrades (when I provide a newer version of the product, the customer needs to copy the property file over again, has to keep track themselves which changes they made, and re-apply these changes).


The base difference between the two solutions is that the first gets resolved at a key-value level, while the second gets resolved at a filename level.

So, are there any other possible solutions for customized internationalization? Is there a way that I can allow my customer to have customized locales, but without destroying the Locale's variant, and with the ability to only customize what he needs?

Thanks in advance.

JDG
 
It sure was nice of your sister to lend us her car. Let's show our appreciation by sharing this tiny ad:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic