Стратегия локализации

Question

В настоящее время мы обсуждаем две стратегии локализации:

A.Иметь XML-файл для структуры бизнес-объектов с локализованным ключом для отдельного CSV-файла для перевода.

, например./Resources/Schema.xml

в отдельном файле CSV: у нас есть все пары ключ / значение для переводов:

/ Resources / Localized.txt

Model_Title, Title, Title (на французском языке), ...

Таким образом, когда структура изменяется, мы просто меняем XML один раз, пока LocalizedKey на месте.

B.Иметь отдельные XML-файлы для каждого языка в зависимости от культуры.

например.есть два файла: /Resources/en-US/US-Localized.xml /Resources/fr-AU/AU-Localized.xml

Таким образом, они будут иметь одну и ту же схему, но отдельные файлы.Следовательно, пользователь должен убедиться, что схемы совпадают с необходимостью изменить его дважды, в отличие от варианта № 1, где он может просто изменить его один раз.

Однако читаемость здесь намного лучшепоскольку пользователю не нужно отслеживать ключ, внесите изменения.

Каковы ваши мысли / идеи относительно стратегий, которые я предложил?

Спасибо,

Answer 1

В общем, вы должны рассмотреть существующие инструменты, а не начинать с нуля.

В .net мы используем Data-Driven ASP.NET Локализация Поставщик ресурсов и редактор Создано Рик Штраль

Answer 2

Не понятно про среду - сеть?рабочий стол?внутреннее предприятие интегрировано что-то или другое?Есть ли какая-то конкретная причина, по которой вы не используете какую-либо платформу i18n, которую поддерживает ваша цепочка инструментов (gettext, файлы ресурсов .NET ...)?

В общем, я бы сказал, что вы хотите разделить ресурсы по культуре (но чтобы быть честным, fr_AU должен быть редким), чтобы иметь лучшую поддержку и не загружать весь файл для всех версий для разных культур во многих ситуациях.Это особенно верно, если количество поддерживаемых языков / культур превышает десятки и более.

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

Это зависит от того, предоставляете ли вы (как отметили комментаторы) локализованные продукты иликлиенты могут создавать свои собственные локализации.