This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
just one short question to be 100% safe. I want to use localisation of my GUI-texts via resource bundles....I know, it is not a must requirement and I know many people on here have just used static final Strings, but I personally prefer resource bundles....
...But wht i am afraid of is: Are resource bundles allowed at all??? I mean, this requires an additional properties file and i am just not sure if this violates any of the restrictions from sun....I am reading the task description over and over again, but i am still not sure....;))...
Did anybody of you passed with proper localisation???...
Roberto Perillo wrote:No need to worry. I'm not sure, but I think Roel used a resource bundle too.
I didn't use a ResourceBundle, just a class with nothing more but all String constants containing messages, labels, captions,... This class could be easily converted using a resource bundle in a next version of the application. I didn't use resource bundles for the simple reason: it's not required
But no need to be afraid: using resource bundles is allowed, there is no reason why it would not. You just have to make sure that when you make the runme.jar you don't forget to include the necessary properties files (otherwise your application may be hard to use and you might lose some points). Also specifying the properties file at startup is not allowed (because only "server", "alone" and <nothing> are allowed according to instructions)
this is what the specifications says: (mine at least)
All configuration must be done via a GUI, and must be persistent between runs of the program. Such configuration information must be stored in a file called suncertify.properties which must be located in the current working directory.
(i guess you can create a properties file programmatically if one doesn't exist)
Jonathan Elkharrat wrote:All configuration must be done via a GUI, and must be persistent between runs of the program. Such configuration information must be stored in a file called suncertify.properties which must be located in the current working directory.
Jonathan, that's about the properties file which contains the configuration settings of your application (database file path, port number, server ip). This file has nothing to do with the properties file(s) you need for localisation through resource bundles.
you're right, but you can also store localisation in properties file as far as i know...
then again, a resource bundle is also a good option. but as you said before, no other argument
is permitted in the program. (but it can give an option in the GUI and store it in the properties)
Jonathan Elkharrat wrote:(but it can give an option in the GUI and store it in the properties)
Your comment confuses me a bit. It seems you have another understanding of localisation than me. Localisation in this context (together with resource bundles) is about translatable strings (menu captions, button labels, info messages,...) depending on the user's locale. I don't see how an option in the GUI can help you unless you mean something like a "choose your language" option (and this preference will be stored in a properties file, together with other configuration settings).
But to make i18n (localisation) work you will have different properties files (1 for each language you want to support) and in your code you use a resource bundle to retrieve the string based on the user's locale. As shown in this tutorial.
Do we really need this localization stuff. Is it worth the bugs that it may attract? What if some really unexpected things happen on the accessor's machine (like an IOException in an attempt to read the properties file into your code). Consider all the things this can bring. Don't people pass by just hard-coding the strings directly into the GUI? Or am I missing something?
OCPJP 6, OCMJD 6
Joined: Feb 13, 2011
wow..interesting how these discussions evolve..;)...
....well, of course the localisation is NOT required and people pass with just string constants....I actually also believe that adding language properties etc. like Jonathan described takes it too far.....I will not provide resource bundles for different languages or Gui options to switch the locales or whatever - all I thought is that I just use a resource bundle, because (1) resource bundles is not much more difficult to implement than String constants and (2) resource bundles are a bit more "professional" and flexible (I would say) than String constants...
Having slept over it, i got also afraid of unexpectable things missing rights to read the property files, SecurityException of the class loader or whatever....because at least I am very very paranoid with this certification process, probably with the String constants you are at least on the safe side....;)
Jonathan Elkharrat wrote:you can also do a:
and fetch properties.get(local+"_option_ok");
you can also hardcode them in several class, each for a different locale and use
the class according to user preference. (class can be used a resource bundle too)
That's true, but then you are doing all the work in your code The beauty of using a ResourceBundle is just that it does all the work for you: you provide a properties file for each locale you want to support and that's it.
Oladeji Oluwasayo wrote:Don't people pass by just hard-coding the strings directly into the GUI? Or am I missing something?
Of course you'll pass with just hard-coding the strings. Localisation is not a must requirement. And the more more complexity or dependencies you add to your project, the more chance you have something might go wrong.