I18n convention : key naming and layout
Hi,
I'm quoting an archived post that did not receive answers and i agregate a few ones :
-"I'm thinking of introducing I18N into my project, which is fairly large now, and is continually growing at quite a quick rate, but I'm unsure as to the best wya to implement it.
I know about the details of loading the strings and such, but what do you recommend for laying out the code/resource bundles? What's your experience on this subject?
For example should each class have it's own properties file, and load this from within the actual class, say as a static final variable. Or each package delegate to one central properties file, creating a new class per-package to load up and retrieve strings? Also, where to place the properties files, place them in with the java source files, or in a separate folder, with a folder structure that seems 'logical'(opposed to in package structure)?"
-Are you loading resouce from one central class or calling resourceBundle.getBundle in each internationalized class ?
-Which resource key naming convention are you using ? I figured out two ways :
- mypackage.myclass.button.save_report : pros = clear, hierarchizable / cons = information for reverse ingeneering, no centralization of commons keys such as "OK" or "Cancel", etc.
- save_report : pros/cons inverted
Thanks for sharing your experience !
Message was edited by:
gl-sub
