Правильный язык для Индонезии ( "id_ID" и "in_ID")?

Question

Я сейчас пользуюсь 6.0 version гибриса. Наш проект полностью основан на Backoffice. Ранее мы настроили in_ID (languageISOcode_countryISOcode) для языкового стандарта Индонезии и работал нормально, но теперь клиент запросил настройку языкового стандарта как id_ID для Индонезии

Пожалуйста, обратите внимание, в languageISOcode устарела, а id обновлен languageISOcode Индонезии

Ниже приведен фрагмент кода в нашем hybris:

final Locale locale = cockpitLocaleService.getCurrentLocale();

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

Это вызывает файл Locale.class Java и, если я передам id_ID тогда также convertOldISOCodes Метод (внутри Locale.class) конвертирует id_ID в in_ID,

Смотрите код ниже:

import java.util.Locale;

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

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

Не могли бы вы помочь мне получить id_ID как локаль для Индонезии.

ИЛИ ЖЕ

Если это ошибка в Java, есть ли способ получить id_ID в гибридах?

Answer 1

Вы можете использовать следующий код:

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

Btw. это не ошибка в Java, а "проблема" с обратной совместимостью. Java использует первую версию ISO 639. Позже стандарт был обновлен, и некоторые коды были обновлены. Java была разработана как полностью обратно совместимая, поэтому авторы решили не обновлять эти коды. Это причина, почему "id_ID" изменяется на "in_ID". Индонезийский не единственный код, который используется в старой форме. По крайней мере, иврит и идиш также используются в старой форме.

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

Answer 2

Если вы находитесь в ситуации, когда файлы локализации предоставляются с id вместо in и у вас нет контроля над этим локально, чтобы изменить это, тогда вам может помочь следующее.

Столкнулся с ситуацией, что не могу прочитать локализацию из id файл перевода, поскольку Java автоматически изменяет id к inвнутренне. весна ResourceBundleMessageSource полагался на доступ к тегу, предоставленному Java Locale, и даже мои лучшие попытки получить idЛокаль привела к тому, что все еще "влезает". Это в основном означало, что всякий раз, когда запрашивался индонезийский язык, необходимые inФайл с суффиксом не был найден, и он вернулся к английскому языку по умолчанию. Поскольку локализации были сгенерированы зависимостью, у меня не было контроля над именованием, и мне пришлось работать с id.

Поскольку языковой стандарт Java является окончательным и агрессивно перезаписывает id с участием in, нет простого способа изменить поведение.

В ResourceBundleMessageSourceсам по себе во многом полагается на Locale, поэтому переопределение некоторых методов для изменения поведения было бы в лучшем случае беспорядочным. Все сложнее, чем кажется, потому что источник весенних сообщений использует java.util.ResourceBundle внизу, и это зависит от окончательного и довольно строгого Locale.

Итак, наконец, мне удалось придумать решение, в котором я просто отредактировал свой файл Maven pom.xml, чтобы использовать maven-antrun-plugin для копирования id файлы локализации в 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>

Этот обходной путь сработал для меня и является чистым в том смысле, что мне не нужно было придумывать хак, чтобы переопределить какое-то жестко заданное поведение по умолчанию в Spring или Locale.