.Net локализация против брендинга - PullRequest
5 голосов
/ 09 октября 2010

Допустим, у меня есть служба WCF, у нее несколько клиентов на нескольких языках. Было бы целесообразно использовать файлы ресурсов и сателлитные сборки для предоставления локализованных строк ресурсов.

Теперь, если эти строки ресурсов станут фирменными, например, два клиента в одной стране, с одним и тем же языком, но с другой терминологией, я бы сделал отдельный файл resx с отдельной сателлитной сборкой, или я что-то упустил?

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

Ответы [ 2 ]

1 голос
/ 12 ноября 2010

Мы столкнулись с теми же проблемами (клиенты смогли адаптировать изначально предоставленный перевод), и спутниковые сборки не решили нашу проблему. Ресурсы и сборки больше подходят для стабильного контента.

В итоге мы сохранили все эти строки ресурсов в базе данных, загрузили и кэшировали их при первом запуске приложения.

0 голосов
/ 12 ноября 2010

Я столкнулся с этой проблемой на одном проекте;Я начал писать свой собственный код для чтения строк из файла XML в том же формате, что и входной файл для компилятора ресурсов.Затем у каждого клиента был список файлов «сообщений», которые нужно попробовать по порядку;мы использовали сообщение из первого файла, который его содержал.(Использование формата файла ресурсов позволяет переводчикам использовать инструменты, к которым они привыкли.)

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

...