I wonder if for things like images or sounds which may have different versions for different locales whether still the properties file would be enough as one wouldn't be storing that data in a Java object but rather the data would be in a file. A string would still be sufficient for loading a file as the file name defines the file and the file name is a string.
I am not sure precisely what localised objects may have been meant in the tutorial, but I guess its things which need a more complicated transformation. One which I might imagine to be such an object, although done in the JDK, might be a date.
Michael Whapples On 03/12/10 11:21, John J. Boyer wrote:
Michael, You have about convinced me. I'll take a look at PropertiesResourceBundle. I don't think we will have any localized objects except strings, though there is a slight possibility that we may have images sometime in the future. We can use ListResourceBundle if necessary. But I'll probably go with properties. John On Fri, Dec 03, 2010 at 10:20:28AM +0000, Michael Whapples wrote:John, What is the problem with properties files? I would have said properties files would be a better option for dealing with strings as translators should not need to be Java programmers to translate and it wouldn't require a recompile just to add another locale support. You mentioned having properties files hanging about, what do you mean? It is perfectly possible for properties files to be included in a jar file and to be loaded from there. However as we aren't going to ship a single jar file but rather a directory structure, there may be an advantage to having the properties files outside the jar file so that end users could even add there own translations without having to regenerate the jar file and they could easily share their translation with other users. That Sun tutorial does recognise there are limitations to properties files, if non-string localised objects are needed then a properties file isn't enough. Do we have such a case? Michael Whapples On 03/12/10 03:07, John J. Boyer wrote:One of the first steps in internationalizing will be to make a list of keys. I don't know if the specification has enough information for that, so a partial list may have to do to start. John On Thu, Dec 02, 2010 at 07:57:48PM -0600, John J. Boyer wrote:Alex, I think your offer to do Spanish is great. So unless there is a strong desire somewhere for a different language that will be our second language. I used to speak Spanish fluently, and I know there are some fluent speakers who have been lurking. English will of course be our first language. I'll do that one, so I can get familiar with the localization process and write some code to simplify using it. Dates, numbers and currencies are all handled in the jdk. I think that using subclasses of ResourceBundle would be the best way to do localization. They will get compresed into the jar file, and we won't have properties files hanging around. The process is pretty simple. There has been an inquiry about ussing .po and .pot files for translations. Does anyone know anything about using them in Java? We might allow users to do localization using properties files. That would be another use of the text editor. John On Thu, Dec 02, 2010 at 05:41:26PM -0800, Alex Jurgensen wrote:Hi John, I can do Spanish. Just my suggestion. However, I suggest that we pick the language that either most of the developers here use natively (Besides English) or the lnaguage that most people here suggest. Regards, Alex, On 2010-12-02, at 1:09 PM, John J. Boyer wrote:From the tutorial the process looks rather involved. I want to set up a package containing all the localization stuff. We will have to localize all menu labels, dialog boxes, etc. and we will also have to display numbers and dates in the correct format. I think it would be good if we practiced localizing to English and one other language for now. Instead of just assigning a string to a label we will be calling a method with a key that will return a String in the proper language. What language would people on the list like us to practice with? please give your feedback. Thanks, John -- John J. Boyer; President, Chief Software Developer Abilitiessoft, Inc. http://www.abilitiessoft.com Madison, Wisconsin USA Developing software for people with disabilitiesAlex Jurgensen, VoiceOver Trainer, ASquared21@xxxxxxxxxxxxxxxxx Visit us on the web at: www.vipbc.org-- My websites: GodTouches Digital Ministry, Inc. http://www.godtouches.org Abilitiessoft, Inc. http://www.abilitiessoft.com Location: Madison, WI, USA