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 ?
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 |
+---------------------------------+
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With