Нам нужно начать добавлять интернационализацию в нашу программу. К счастью, пока не все, всего несколько кусочков, но я хочу, чтобы способ, которым мы это делаем, увеличился, чтобы охватить всю программу. Дело в том, что наша программа основана на плагинах, поэтому не все строки принадлежат одному и тому же месту.
Насколько я понимаю, Java ResourceBundle
работает так. Вы создаете класс, который расширяет ResourceBundle
, называемый чем-то вроде MyProgramStrings
, а также языковые классы, называемые MyProgramStrings_fr
, MyProgramStrings_es
и т. Д. Каждый из этих классов отображает ключи (строки) в значения (любой объект). Каждый из этих классов может получить свои данные, но общим местом для них является файл свойств.
Вы просматриваете значения в два этапа: сначала вы получаете правильный пакет, а затем запрашиваете нужную вам строку.
Locale locale = Locale.getDefault(); // or = new Locale("en", "GB");
ResourceBundle rb = ResourceBundle.getBundle("MyProgramStrings", locale);
String wotsitName = rb.getString("wotsit.name");
Однако нам нужно объединить результаты нескольких локалей в одном пространстве ресурсов. Например, плагин должен иметь возможность переопределять уже определенную строку и возвращать это новое значение всякий раз, когда код ищет строку.
Я немного растерялся во всем этом. Кто-нибудь может помочь?
Обновление: Дэвид Уотерс спросил:
Я поставил свой ответ внизу, но мне было бы интересно услышать, как вы решили эту проблему.
Ну, мы еще не очень далеко - долгосрочные WIBNI всегда становятся жертвами последнего кризиса - но мы основываем это на интерфейсе, который реализует плагин, с условием, что ресурсы имеют одно и то же полностью определенное имя в качестве интерфейса.
Таким образом, интерфейс UsersAPI
может иметь различные реализации. Метод getBundle()
в этом интерфейсе по умолчанию возвращает эквивалент ResourceBundle.get("...UsersAPI", locale)
. Этот файл можно заменить или реализации UsersAPI могут переопределить метод, если им нужно что-то более сложное.
Пока что это делает то, что нам нужно, но мы все еще ищем более гибкие решения на основе плагинов.