Correct locale for Indonesia( "id_ID" Vs "in_ID" )?

Question

I am currently using 6.0 version of hybris. Our project is entirely based on Backoffice. Earlier We configured in_ID (languageISOcode_countryISOcode) for indonesia locale and was working fine but now Client has requested to do the locale setup as id_ID for Indonesia locale.

Please note, in languageISOcode is deprecated and id is the updated languageISOcode of Indonesia.

Below is the snippet of code in our hybris:

final Locale locale = cockpitLocaleService.getCurrentLocale();

LOG.info("locale : " + locale); //Here I'm getting in_ID value of locale in all scenario

It is calling Locale.class file of java and If I pass id_ID then also convertOldISOCodes method(inside Locale.class) is converting id_ID to in_ID.

See the code below :

import java.util.Locale;

Locale localeIndonesia = new Locale("id", "ID");

System.out.println(localeIndonesia); //printed in_ID

Could you please help me to get id_ID as locale for Indonesia.

OR

If it's a bug in Java then Is there any way to get id_ID in hybris ?

Marchese

localeplanet.com/java/id-ID/index.html – Canuck

What version of Java are you running? I tested on 1.7.0_79, 1.8.0_181, and 11.0.1, and all three had toLanguageTag() returning id-ID for both Locale.forLanguageTag("id-ID") and Locale.forLanguageTag("in-ID") – Lashay

Hi Andreas, I'm also getting toLanguageTag() as "id-ID" but I need locale value as "id_ID" Can you please help me to get exact value of Indonesia locale as "id_ID" in hybris side OR java side(would also fine). – Marchese

Answer 1

You can use the following code:

Locale locale = new Locale("id", "ID");
System.out.print(locale.toLanguageTag().replace('-', '_')) // printed id_ID

Btw. it is not a bug in Java, but "the problem" with backward compatibility. Java uses the first version of ISO 639. Later the standard has been updated, and some codes have been updated. Java was designed as fully backward compatible, so the authors decided to not update that codes. It is the cause why "id_ID" is changed to "in_ID". Indonesian is not the only code which is used in an old form. At least Hebrew and Yiddish are also used in the old form.

+---------------------------------+
|  Language  | ISO 639 | ISO 3166 |
|------------|---------|----------|
| Indonesian |   IN    |    ID    |
|   Hebrew   |   HE    |    IW    |
|   Yiddish  |   YI    |    JI    |
+---------------------------------+

Brachiate

In Java 17 they broke backward compatibility and now in_ID is mapped to id_ID instead. See bugs.openjdk.org/browse/JDK-8267069 Old behavior can be restored with system property -Djava.locale.useOldISOCodes=true – Triumvir

Answer 2

If you are in a situation, where the localization files are provided with id instead of in and you have no control over it locally to change this, then the following might help you.

I faced the situation that I could not read the localization from the id translation file, because Java automatically changes the id to in internally. Spring ResourceBundleMessageSource relied on accessing the tag provided by the java Locale, and even my best attempts to get id Locale resulted in still getting 'in'. This basically meant that whenever Indonesian language was queried, the necessary in suffixed file was not found and it fell back to default English. As the localizations were generated by a dependency I had no control over the naming and had to work with id.

As Java Locale is final and it aggressively overwrites id with in, there's no easy way to change the behavior.

The ResourceBundleMessageSource itself relies on Locale a lot, so overriding some of methods to change the behavior would be messy at best. Things are more difficult than they seem, because the spring message source uses java.util.ResourceBundle underneath and this relies on the final and rather strict Locale.

So finally I managed to come up with a solution that I simply edited my Maven pom.xml file to use maven-antrun-plugin to copy the id localization files to in

<plugin>
     <groupId>org.apache.maven.plugins</groupId>
     <artifactId>maven-antrun-plugin</artifactId>
     <version>3.0.0</version>
     <executions>
         <execution>             
             <phase>generate-resources</phase>
             <configuration>
                 <target>
                     <copy file="${messagesdir}/myProps_id.properties"
                           tofile="${messagesdir}/myProps_in.properties" />
                 </target>
             </configuration>
             <goals>
                 <goal>run</goal>
             </goals>
         </execution>
     </executions>
</plugin>

This workaround worked for me and is clean in the sense that I didn't have to come up with a hack to override some hardcoded default behavior in Spring or Locale.

Knurled