Tonny, thank you so very much for this!

I do have a question. Is this to be only for Indonesian speakers in Indonesia? Or is it for all Indonesian speakers regardless of where they are?. Or another way to ask, should these files be the default files for the language?

If it is for the latter, I'll remove the _ID from the file names. That way it is not location dependent.

Typically we don't put a country code on the property files that are the first for the language, especially when it is the country of origin. That way if a speaker of that language is in another country, they can get the language. For example, if the base files were xyz_pt_PT.properties and there were no xyz_pt.properties then a Portuguese speaker in Brazil with a locale of pt_BR would not get Portuguese. (Portuguese in Portugal and in Brazil are very different dialects, but they can understand each other.)

Hi,

It is for all Indonesian speakers regardless where they are.

However, there are Java bug regarding indonesian locale as you can see from
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6457127

and there is another bug in the past as well (sorry, could not find the url) regarding a mixed up between indonesia(in) and india (in) locale in Java.

So I just follow Sun Documentation regarding Indonesian Locale
http://java.sun.com/javase/6/docs/technotes/guides/intl/locale.doc.html which use in_ID

note: I am not expert in country-language ISO code, I just following Sun Java Doc regarding Indonesian locale. So I am not sure which one (in or in_ID) is the correct one.

The second link provides Indonesian as in_ID with an asterisk which says it comes from the CDRL version 1.4 "as-is."

So, I went and looked and the version 1.7.1 has it correct id_ID. So I looked progressively further back, 1.6, then 1.5, then 1.4 and finally 1.1. All of them have it correct, id_ID.

Using filename_in.properties should work as expected. Though it should be filename_id.properties, which does not work.

There is an identical problem with Hebrew. Java thinks its language code is iw, when it is he. They are merely maintaining these bugs going forward.

In the latest CDRL there is an alias mechanism which looks like it would address this.

I'll experiment to see what is the best naming.

We use the standard ResourceBundle mechanism to get these properties and ResourceBundle uses Locale objects to determine which names it should look at. It uses both a supplied Locale, if there is one, and the default Locale.

In BibleDesktop, we set the default Locale when the program starts if the user has picked a particular locale in which they want to display.

We use that default to get the resources.

Rather than experimenting, I looked at the code for Java 1.4.2 and Java 1.6. Regarding this, both are the same. When creating a new Locale with a language code of either "in" or "id", Java will store "in". It does not know, remember or care that "id" and "in" are aliases of each other. It promptly forgets that "id" was passed into the constructor.

So, for the property files to work as a resource bundle for all Indonesian speakers, we need to name them filename_in.properties. Naming them filename_in_ID.properties will only work when the supplied country is ID.

I'll remove the _ID from the files and check them in.

Thanks for the explanation which indicate the correct one is "in"

Applied quite a while ago. Thanks Tonny!