Интернационализация в базе данных

Question

Как вы думаете, интернационализация должна выполняться только на уровне кода или в базе данных?

Существуют ли шаблоны проектирования или принятые практики для интернационализации баз данных?

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

Спасибо

Answer 1

Интернационализация распространяется на базу данных, поскольку ваши столбцы смогут хранить данные. NText, NChar, NVarchar вместо Text, Char, Varchar.

Что касается вашего пользовательского интерфейса, для неизменяемых меток файлы ресурсов являются хорошим методом для использования.

Answer 2

Если вы говорите о том, что ваше приложение поддерживает несколько языков на уровне пользовательского интерфейса, тогда есть больше возможностей. Если метки никогда не меняются, за исключением случаев, когда вы выпускаете новую версию, файлы ресурсов, которые внедряются в исполняемый файл или саму сборку, являются лучшим выбором, поскольку они работают быстрее. Если ваши ярлыки, с другой стороны, должны корректироваться пользователями во время выполнения, тогда сохранение переводов в базе данных является хорошим выбором. Что касается самого кода, имен таблиц и полей в базе данных, мы храним их как можно более на английском языке, поскольку английский язык является стандартом де-факто для ИТ-специалистов.

Answer 3

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

Answer 4

Даже такие вещи, как адреса, очень различаются между США и Японией. Одна схема не подойдет для обоих.

Answer 5

Если ваши клиенты японцы и хотят видеть их имена в кандзи и катакане (а иногда и в большинстве формальных гайдзи), вы должны хранить их как Unicode. Обойти это невозможно.

Answer 6

@ hova охватывает технические аспекты, но вы можете рассмотреть вопрос о поддержке системы, показывающей язык, который вы не понимаете.

Один из способов справиться с этим - использовать английский в качестве языка по умолчанию и пользовательскую настройку, которая переключается на другой язык. Таким образом, ваши пользователи поддержки могут войти в систему и увидеть систему естественным образом (предполагая, что английский является их родным языком), а ваши фактические пользователи могут видеть систему на своем родном языке. ИМО, данные всегда должны быть «естественными» - на языке пользователей.

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