Доступно несколько вариантов.
Во-первых, к меткам и элементам пользовательского интерфейса .
Здесь, как правило, возможны два варианта: вы либо используете ресурсы (* .resx), либо разворачиваете свою собственную многоязычную поддержку на уровне базы данных. У них обоих есть свои преимущества и недостатки.
Resoures:
[+] Простое решение, все готово к немедленному использованию. Вы определяете текстовый ресурс в семействе файлов с именами, такими как Orders.en.resx, Orders.fr.resx и т. Д. В коде вы ссылаетесь на эти строки как Resources.Orders.Title. Так что это простое решение для статических элементов пользовательского интерфейса.
[+] Файлы ресурсов - это, по сути, простые XML-документы, которые можно быстро прочитать и проанализировать, так что это не приведет к значительным потерям или снижению производительности.
[-] Если вам нужно что-то изменить, вам придется перекомпилировать проект. Следовательно, это означает, что вам понадобится установить среду разработки (VS) для всех, кто может подумать об обновлении текстов. Затем вам также нужно будет снова развернуть перекомпилированную версию. То же самое касается введения новых языков в систему.
[-] Не будет работать для нетехнических вещей, так как требуется участие специалистов.
Специальное многоязычное решение на основе базы данных:
[-] Потребуется некоторое усилие и время для разработки и реализации
[-] Каждый отдельный текст пользовательского интерфейса будет извлечен из базы данных, что означает падение производительности и дополнительную нагрузку на базу данных
[+] Позволяет динамически изменять текст на лету и удалять / добавлять новые языки. Перекомпиляция или развертывание не требуются.
[+] Теперь огромный плюс. Поскольку для работы с текстами не требуется никаких технических навыков, вы можете передать эту работу в любое место. Вы можете внедрить веб-интерфейс и систему отслеживания изменений для профессиональных сервисных бюро переводов, чтобы исправлять ваши тексты и быстро переводить на любой язык, который вам нужен, после обнаружения новых текстов.
Теперь к динамическим текстам (фактическое содержание).
Здесь вы можете разделить каждый текст, который будет сохранен как дополнительная запись для каждого языка в некоторой таблице, или объединить все переводы в один объект.
Несколько записей:
Представьте себе следующую модель базы данных:
[Language]
-----------------
ID Description
[Translation]
------------------
ID FallbackText
[TranslationText]
--------------------------------
ID TRID LanguageID Text
[Order]
------------------------------------------------
ID TitleTRID DescriptionTRID RemarkTRID
Везде в базе данных, где вам нужно хранить многоязычный текст, вместо этого вы будете ссылаться на некоторый TranslationID. Затем, в зависимости от активного языка, ваша система будет искать подходящий перевод или, если не найден, вернуть текст по умолчанию (обычно устанавливаемый разработчиками).
Одно лицо:
Вы храните все переводы для данного текста в одной строке, используя некоторые средства различения конкретных переводов. XML естественно работает здесь.
<translation>
<en>Order</en>
<de>Bestellung</de>
<fr>Commande</fr>
</translation>
Здесь ваша модель базы данных будет проще, но вам нужно будет проанализировать каждый отдельный текст, чтобы извлечь необходимую версию.
Это широко используемые стратегии. Какой из них будет работать лучше всего, будет зависеть от ваших потребностей и ожидаемых сценариев использования.
Надеюсь, это поможет. :)