Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
Форум программистов > Java: Общие вопросы > Локализация приложений |
Автор: LSD 13.11.2005, 19:04 | ||||||||||
Локализация приложений. Локализация - переработка существующего программного продукта с целью использования его в странах с другим языком. Локализацию включает в себя адаптацию пользовательского интерфейса: система ввода-вывода текста (например ввод текста справо-налево, поддержка соответсвующей раскладки клавиатуры), расположение управляющих элементов (например кнопки в диалогах ориентированны в соответсвии с направлением ввода текста), перевод текстовых сообщений системы. В данной статье рассматривается проблемы перевода текстовых сообщений. Один из основных для локализации классов, это java.util.Locale. Этот класс описывает текущую локаль, локаль - это описание текущего региона, языка и других особенностей. Класс Locale предназначен только для идентификации локали, никаких данных для локализации он не содержит. Самый главный параметр это используемый язык, второй по значимости параметр это страна, и третий параметр это вариант. Вариант не имеет какого-то определенного смысла и предназначен для указания некой дополнительной информации, не описываемой первыми двумя параметрами, например диалекта. Как правило вариант не используется. Из всех параметров обязательным является только язык. Параметр страна является опциональным и предназначен для указания страны пользователя. Язык описывается двухбуквенным кодом http://www.loc.gov/standards/iso639-2/englangn.html, код записывается в нижнем регистре. Страна обозначается двухбуквенным кодом http://www.iso.ch/iso/en/prods-services/iso3166ma/02iso-3166-code-lists/list-en1.html, код записывается в верхнем регистре. Получить список языков и стран можно с помощью Locale.getISOLanguages() и Locale.getISOCountries() соответсвенно. Хотя никаких ограничений на вариант не накладывается, для варианта лучше придерживаться правил формирования идентификаторов в Java, иначе некоторые механизмы могут не работать или работать неправильно. Задача: создать локаль для описания русского языка на Украине:
Локаль по умолчанию устанавливается исходя из установок ОС, получить ее можно Locale.getDefault(). Переопределить локаль по умолчанию можно из кода Locale.setDefault(locale), из командной строки запуска: -Duser.language=ru -Duser.country=RU. Для преобразования чисел, дат и сообщений в строковое представление служал форматтеры (см. java.text.Format), они все поддерживают конструкторы с указанием локали, чтобы форматировать в соответсвии с текущей локалью. Эти классы можно использовать без доработки, они полностью локализованы. Единствеено но, может потребоваться написание своего ResourceBundle для поддержки "экзотического" языка или диалекта. Основная нагрузка по локализации приложений ложится на класс ResourceBundle. Данный класс умеет загружать ресурсы для указанной локали. Для загрузки ресурсов используется ResourceBundle.getBundle(<name>, <locale>, <classLoader>), где:
Задача: загрузить ResourceBundle и отобразить локализованное сообщение об ошибке.
Ресурсы загружаемые ResourceBundle могут хранится либо в текстовых файлах, организованных наподобие properties, либо в виде классов унаследованных от ListResourceBundle (именно отсюда идет требование к именам ресурсов). Ресурсы реализованные в виде наследников ListResourceBundle быстрее загружаются, позволяют хранить не только строки но любые объекты, но для локализации приложения нужен исходный код классов и компилятор. В то время как ResourceBundle реализованные в виде файлов properties могут быть локализованы в любом текстовом редакторе (может понадобится утилита native2ascii). Загрузка ресурсов происходит следующим образом: формируются потенциальные имена для ResourceBundle:
Задача: реализовать приложение с поддержкой русского и английского языков, в качестве умолчального выбрать английский Приложение:
Умольчальный ResourceBundle (он же английский)
ResourceBundle для русского языка
P.S. Как обычно замечания и предложения приветствуются ![]() Если кто переведет текст на еще какой нибудь язык, я покажу как создавать ResourceBundle в виде properties. |
Автор: carper 16.11.2005, 10:27 | ||
LSD
Во-первых, большое спасибо за статью. Во-вторых, не совсем понятно как свой ResourceBundle может помочь с экзотическими форматами, скажем, даты. Мне казалось, что в таких случаях надо создавать свой форматтер? Да, что касается файлов properties. Что-то их необходимость, с учетом их 7-и значной кодировки и извращений при добавлении символов других языков, представляется более чем сомнительной. Тем более, что не вижу какие препятствия и сложности могут возникнуть у переводчика при правке наследника ListResourceBundle? Его дело перевести, а вызов javac ..., особенно с учетом того, что переводить не глядя на получившийся результат нельзя, т.е. все равно переводчику придется устанавливать JAVA, ну не понятно как можно не откомпилировать один класс? В крайнем случае скройте эту часть работы от переводчика. ![]() |
Автор: LSD 16.11.2005, 11:17 | ||||
Я говорил не о формате даты, а о языке. Например хочешь ты писать дату на латыни.
Вообщем да, например Sun полностью перешла на ListResourceBundle. |
Автор: carper 16.11.2005, 11:54 | ||
LSD
Ну, тогда, только остается еще раз поблагодарить за понятную и полезную статью, думаю, что она и так вполне полноценна и без описания properties. Да, почему-то на форумах SUN постоянно тусуется народ с одной и той же проблемой, а именно, у SUN как-то странно описано понятие базового имени класса-наследника ListResourceBundle и многие пытаются задавать base name не указывая имя пакета. Может стоит как-то это акцентировать? И еще, мне кажется использование ResourceBundle, благодаря возможности использовать объекты, дает довольно интересную (хотя и не полностью заменяет) альтернативу таким вещам как Enum для хранения стандартных настроек. Или это не целесообразно, все же нет такого контроля? |
Автор: LSD 16.11.2005, 12:35 | ||
Enum это скорее альтернатива public static final константам. Хранить объекты можно, только надо учитывать, что сколько локалей поддерживается столько объектов может быть порождено. Т.е. если у тебя одна картинка на все языки то класть ее в ResourceBundle не разумно, а вот если ты ее можешь менянять в зависимости от языка, то тогда вполне. |
Автор: PashaOvechkin 17.6.2008, 15:18 |
Хорошая статья! ![]() Но веселей становится когда нужно сменить язык в ран тайме. |