Рекомендации по локализации Java

У меня есть приложение Java с сервером и клиентом Swing. Теперь мне нужно локализовать пользовательский интерфейс, и, возможно, некоторые из данных должны быть специфичными для локали. Есть несколько вещей в конкретном, о которых я хотел бы услышать ваше мнение.

Как распределить локализованные строки для пользовательского интерфейса в файлах свойств? В моем приложении есть несколько просмотров, и каждый из них имеет несколько панелей. Должен ли я иметь один файл локализации на каждый язык для каждой панели или представления или я должен хранить все переводы для одного языка в одном файле? В настоящее время я склоняюсь к одному файлу для каждого вида и языка, но я не уверен, как я должен обрабатывать некоторые термины, относящиеся к определенному домену, которые появляются во многих местах. Наличие такого же перевода в нескольких файлах звучит не слишком хорошо.
Сервер выдает некоторые исключения, содержащие сообщение, которое должно отображаться пользователю. Я мог бы получить выбранный язык из сеанса и обработать локализацию на сервере, но я считаю, что было бы более элегантно хранить все файлы локализации на клиенте. Я думал о том, чтобы отправлять только ключ локализации с сервера с помощью каких-либо заполнителей для информации об ошибках, которая будет отправляться с исключением. Затем клиент может построить сообщение на основе ключа локализации и заменить заполнители информацией об ошибке. Это звучит как хороший способ справиться с этим, или есть другие варианты? Обычно мои сообщения об исключениях содержат некоторую дополнительную информацию, которая изменяется для каждого случая. Это может быть, например, "Пользователь с именем пользователя Khilon уже существует", и в этом случае строка в файле свойств будет выглядеть примерно так: "Пользователь с именем пользователя {0} уже существует".
Локализация данных - это область, которая наиболее неясна для меня. Поскольку я не уверен, что это когда-нибудь понадобится, я пока не планировал этого. Часть базы данных звучит достаточно прямолинейно, вам просто нужна дополнительная таблица для строк и столбца, чтобы указать, для какой языковой строки является строка. Хотя я не уверен, было бы лучше иметь таблицу локализации для каждой таблицы данных (например, Product и Product_names), или я мог бы использовать одну таблицу для строк локализации для всех таблиц данных. Очень сложная часть - как обрабатывать пользовательский интерфейс, так как в какой-то степени потребовалось бы, чтобы пользователь вводил текст для объекта на нескольких языках. На практике это может означать, например, что рабочий в Финляндии дал бы название объекта на финском и английском языках, а затем работник в другой стране мог бы перевести его на свой родной язык. Если кто-то из вас сделал что-то подобное, я был бы рад услышать, как вы это сделали.

Я очень благодарен всем, кто может поделиться своим опытом со мной.

P.S. Если вам известны какие-либо исключительно хорошие сайты или книги по этому предмету, я буду рад услышать о них. Я, конечно, сделал некоторые поисковые запросы и прочитал некоторые статьи о локализации, но ничего не выдул.

Ответ 1

Собственно, речь идет о интернационализации (i18n), а не о локализации (L10n). По моему опыту, вы на правильном пути.

ad 1). Один файл свойств для каждого вида и локали (необязательный язык, так как вы можете использовать разные переводы для определенных языков в зависимости от страны, т.е. Используя разные строки для английского и американского языков, например, разные локали) является правильным подходом. Поскольку приложения, как правило, развиваются, это может сэкономить немалые деньги, если вы хотите изменить только один вид (поскольку переводчики будут взимать плату за то, что они не будут касаться), им придется фактически найти строки, которые необходимо обновить/недавно переведенный). Также было бы проще использовать инструменты Translation Memory, если вы сделаете это правильно (новые строки в конце файла все время).

ad 2). Лучшей идеей является отправка только ресурсного ключа с сервера или другого процесса; другим подходом может быть присоединение ключа ресурса и, возможно, данных (то есть числового значения) с использованием разделителей, поэтому сообщение можно воссоздать и переформатировать на локальный язык.

ad 3). Я видел несколько подходов к локализации баз данных, но лучший (и это не только мое мнение, но и члены IEEE) заключается в том, чтобы хранить ключи ресурсов и воссоздавать данные на стороне клиента, используя соответствующую локаль. Конечно, это касается предварительно установленных данных, если вы позволите пользователям вводить данные, возникнут другие проблемы... Нет серебряной пули, нужно подумать о том, что лучше всего работает в его/ее контексте. Я бы наклонился к тому, чтобы включить столбец внешнего ключа, который будет идентифицировать язык, но он действительно зависит от типа данных, которые будут сохранены.

К сожалению, i18n не заканчивается здесь, пожалуйста, помните о правильном форматировании дат и номеров, чтобы они были понятны для людей, использующих вашу программу. А также, если у вас есть список строк, порядок сортировки также должен зависеть от языка (он называется сортировкой). Солнце имело (теперь наш любимый Оракул) неплохую трассу i18n, которую вы можете найти здесь: http://download.oracle.com/javase/tutorial/i18n/index.html.

Если вы хотите прочитать хорошую книгу по темам i18n и L10n, это сэкономит вам много лет, изучая эти темы (хотя не обязательно будет учить вас, как ее программировать), есть замечательная книга от Microsoft Press: "Разработка Международное программное обеспечение" - http://www.amazon.com/Developing-International-Software-Dr/dp/0735615837. Он по-прежнему актуальный, хотя и довольно старый.

Ответ 2

1) Я обычно храню все в одном файле и использую имена, которые означают, где используются свойства. Например, я префикс с такими вещами, как "просмотр" и "меню"

view.add_request.title
view.add_request.contact_information.sectionheader
view.add_request.contact_information.first_name.label
view.add_request.contact_information.last_name.label
menu.admin.user_management.add_user.label
menu.admin.user_management.add_role.label

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

3) Раньше я не локализовал данные (обычно это просто метки и статический пользовательский интерфейс), но я, вероятно, склоняюсь к тому, чтобы начать с одной таблицы со всеми локализованными строками и локалями (просто чтобы это было просто), Я не уверен, о чем вы спрашиваете в отношении пользовательского интерфейса, но я бы посоветовал вам убедиться, что любой набор символов, который вы используете, позволяет использовать все языки, которые вы хотите поддерживать. Убедитесь, что вы прочитали статью Джоэла Спольского под заголовком: Абсолютный минимум Каждый разработчик программного обеспечения Абсолютно, положительно должен знать о Unicode и наборах символов (без отговорок!)