Интернационализация строк

Question

В настоящее время мы сохраняем имена стран, городов, состояний, несколько таблиц поиска в базе данных SQL Server. Для интернационализации строк, хранящихся в этих таблицах, каковы наилучшие практики?

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

Answer 1

На самом деле, с точки зрения обслуживания, локализация базы данных может быстро стать кошмаром. Очевидно, что вы не хотите предоставлять переводчикам доступ к вашей базе данных (даже косвенно). Я объясню это через минуту.

Наиболее типичным примером является экстернализация всех строк в так называемых ресурсных файлах и загрузка их на основе локали - кошмар обслуживания, как вы его называете.
типичные форматы файлов ресурсов являются:

• Java .Properties файлы
• Gettext .pot/.po файлы
• XML/XLIFF

Как вы можете видеть, JSON не стоит на мой короткий список.
В любом случае, если вы, как правило, используется стандартный формат файла, переводчики могут использовать свои инструменты:

• MT - машинного перевода для перевода непереведенные части файла (а затем вручную исправить в соответствии с контекстом)
• TM - переводческая память для хранения предыдущих переводов и использовать их при необходимости (это на самом деле то, что будет использоваться первым ...)

в типичном процессе, изменения должны быть сделаны только в файл английского ресурсов (нет ручная модификация la файлы nguage). Если это так, достаточно легко воссоздать языковые файлы, используя инструмент TM, о котором я упоминал ранее.
Теперь, если вам нужно изменить перевод (т. Е. Исправить некоторую неприятную ошибку локализации)?
Очевидно, что вы хотите изменить его в инструменте перевода (а не в файл!), Так что изменения будут использоваться с каждой новой версией английского файла.

Это все еще будет кошмар? :)

Процесс, о котором я упомянул, является стандартным. Это правило 80/20, то есть такой процесс хорош для 80% проектов. Однако есть 20% проектов, которые не вписываются в идеальный процесс - те, которые используют так называемую динамическую локализацию.
Динамическая локализация, я имею в виду, что английские строки меняются очень часто и обычно предоставляются пользователями системы.

Если это так, локализация БД с помощью таблиц поиска - это просто самый простой подход. Но, к сожалению, всегда есть улов.
Уловка - это действительно сложно реализовать. И если у пользователей есть какие-либо средства для изменения содержимого базы данных с использованием текста свободной формы, ваша система подвержена риску. Никогда не используйте типичные уязвимости SQL-инъекций; тех, кого вы можете предотвратить.Но что, если сам механизм БД имеет критический недостаток нулевого дня, который позволит пользователям повысить свои привилегии и выполнить произвольный SQL-запрос? Ты никогда не узнаешь.
Конечно, безопасность - это только одна проблема. Другие проблемы:

• Как предоставить пользователям возможность переводить строки?
• Как отслеживать и обеспечивать полноту перевода?
• Как обеспечить правильность перевода?
• Как мотивировать моих пользователей фактически предоставлять эти переводы?
• Как правильно реализовать механизм перевода?

Эти вещи нельзя воспринимать легкомысленно.
Facebook дает вам возможность переводить пользовательский интерфейс на ваш язык. Они создали специальный инструмент, который позволяет переводить текст на экран (и вы можете использовать разные формы на основе пола и мощности, т. Е. Множественные множественные формы). И знаешь, что? Несмотря на то, что у них так много участников, сайт по-прежнему не переводится на 100% (на мой взгляд) на большинство языков, которые он поддерживает. Правильно ли это переведено? Хорошо, большую часть времени Да.
Самой большой проблемой приседания является вандализм. Есть люди, которые намеренно нарушают перевод (или содержание), Википедию? Вы должны как-то помешать этому.

Теперь о деталях реализации. Эти проблемы могут также присутствовать в типичном сценарии локализации, с файлами ресурсов. Однако они очень распространены, и во многих случаях движок разрешает их для вас (лучший пример - Gettext). При реализации вашего собственного механизма локализации вам необходимо рассмотреть следующие вопросы:

1. Языковой запас. Допустим, ваша система переведена на немецкий язык, а ваш язык по умолчанию - английский. Если пользователь из Австрии (де-AT) приходит, она должна иметь возможность видеть пользовательский интерфейс на немецком языке (de), а не на английском. Это просто.
   Более проблематичным будет китайский упрощенный и китайский традиционный. Если происходит, что ваша система имеет переводы для обоих этих языков (локали zh-Hans и zh-Hant соответственно), вам нужно убедиться, что правильное отставание на месте: zh-CN (Китай) и zh-SG (Сингапур) должны вернуться к ж-Гансу, тогда как zh-TW (Тайвань), zh-HK (Гонконг), а также zh-MO (Макао) должны вернуться к ж-ханту. В случае чистого zh, вероятно, это снова должно быть упрощено на китайском языке.

2. Вы хотите повторно использовать общие строки (например, «ОК», «Отмена как подписи к кнопкам»), но в то же время вы не хотите повторно использовать строки в другом контексте (у вас может возникнуть соблазн сделать это, но это создаст ошибку i18n). Первая часть проста, вы просто будете использовать один и тот же ключ ресурса для каждой повторяющейся строки. При условии, что у вас есть ключи ресурсов.
   Самая распространенная ошибка, которую я видел, когда люди пытаются реализовать механизм локализации на базе БД, использует английскую строку в качестве ключа в базе данных.
   Не делайте этого.
   Это не позволит выполнять разные переводы одних и тех же строк в разных контекстах. Например, позвольте мне привести пример диалога Save. На польском языке «Сохранить» на надписи на кнопке - это действие и должно быть переведено в императивное настроение («Запис»). Тот же «Сохранить» в заголовке окна сообщает о том, что произойдет, и его следует перевести как «Записывание».

3. Чтобы усугубить ситуацию, на многих языках имеется более одной множественной формы, поэтому, если вы не перефразируете английское предложение, чтобы избежать проблемы, вам придется принять это во внимание. Это означает, что более одного (до шести) переводов для одного и того же ключа ... Это не так сложно, вы просто использовали бы составной первичный ключ (resource_id, locale_id, мощность) с cardinality, являющийся одним из: ноль, один, два , немногие, многие, другие.

4. Гендер может быть источником проблемы. Возможно, вы захотите, чтобы ваша система была нейтральной по гендерному признаку, насколько это возможно, но в некоторых случаях переводы фактически будут разными в зависимости от пола. Если вы позволите своим пользователям переводить сообщения, это то, что вам, скорее всего, придется обрабатывать.

5. С другой стороны, если вы хотите воспользоваться услугами профессиональных поставщиков переводов, вы не можете просто отправить файл SQL для перевода. Скорее всего, вам понадобится создать механизм импорта/экспорта, чтобы создать один из стандартных форматов файлов ресурсов, которые могут использовать переводчики, чтобы практиковать свое искусство.
   Конечно, вы можете отправить в основном любой формат файла, но он имеет свои последствия. Наиболее очевидным является то, что нестандартный формат файла (например, файл Excel) требует ручного усилия и, как таковой, подвержен ошибкам. Поскольку для этого требуется ручное усилие, переводчики взимают с вас премию и ... для перевода ваших строк потребуется больше времени.
   ОК, вы можете интегрировать БД непосредственно с системами ТМ и МТ (однако вы никогда не должны позволять текстовому переводу на машине использовать свой интерфейс перед лингвистической проверкой), но это также будет довольно напряженным.

Выполняется ли ваш проект в 80% случаев использования? Вы должны сами ответить на этот вопрос.

Edit: Как избежать перераспределения, когда ресурсы изменить

Если ресурсы меняются чаще, чем код делает, это ясно указывает, что следует реализовать динамическую локализацию (в основном DB управляемый один).

С другой стороны, иногда мы не хотим повторно развертывать все приложение только потому, что были изменены файлы ресурсов. Это совершенно понятно.
Существует много способов справиться с такой ситуацией, самым простым способом, вероятно, будет создание микросервиса, который будет читать файлы свойств и возвращать их по требованию. Он может использоваться некоторой частью кода приложения для локализации диска (т. Е. Генерировать файлы JSON по запросу). Конечно, это означает дополнительную сложность и необходимость передислокации микросервиса, но код приложения (war, ear, jar?) Останется неизменным.

В Java 8 другой подход возможно: ResourceBundle.Control класс реализует Service Provider Interface, так что в теории можно было бы просто создать специальный файл JAR с настраиваемым ResourceBundle.Control реализации, которая будет читать файлы ресурсов из разных мест (диск, флягу, веб сервис, где угодно). Это можно использовать для обеспечения того, чтобы только файлы ресурсов нужно было перераспределить, а не все приложение.

К сожалению, как всегда, все зависит от контекста; в определенных технологиях будут работать разные подходы. И, как обычно, избегать одного означает увеличение сложности другого.