Локализация демонстрационных данных dbms

Я разрабатываю мобильное приложение для Windows, которое должно работать на нескольких языках (английский, немецкий, французский, русский).

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

Итак: кто-нибудь придумал способ создания данных, которые затем будут вставлены в СУБД во время выполнения?

Например: описание НДС для английской версии гласит «НДС 17,5%» со значением 17,5, немецкая версия «Mehrwertsteuer 19%» со значением 19, французская версия «TVA 19,6%» со значением 19,6.

заранее спасибо

ИЗМЕНИТЬ

Признаюсь, я не очень ясно выразился. Мне нужен набор данных для локализации. Мне нужен механизм, который как-то считывает эти "подготовленные" локализованные данные и вставляет их в СУБД.

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

файл данных.en-US.xml

файл данных.de-DE.xml

Что Вы думаете об этом?


person Savvas Sopiadis    schedule 26.09.2010    source источник
comment
Для французской версии это, вероятно, должно быть TVA 19,6%...   -  person Paweł Dyda    schedule 27.09.2010


Ответы (1)


Я не совсем понимаю, какова ваша цель, поэтому я могу ошибаться... В любом случае, если вы планируете распространять свое клиентское приложение Windows Mobile в разных странах, и одна языковая версия должна работать в одной стране, я бы предложил использовать файлы ресурсов вместо SQL DB. Вы можете поместить такие сообщения, как "VAT {0}", "TVA {0}" и отформатировать их во время выполнения (в зависимости от языка программирования это будет выглядеть по-разному, см. пример C#/.Net ниже), сохраняя действительный культурный формат.

var vat = string.Format(vatPatternStringFromResources, vatValueFromResources.ToString("P")); // "P" means percentage format

Если вам все еще нужно добавить значение НДС в SQL для справки, вы можете просто добавить один десятичный столбец, который будет содержать либо внешний ключ в таблице НДС, либо просто значение НДС...

Обновление различных значений НДС

Проблема в том, что значения НДС различаются не только по странам, но и в зависимости от того, что вы покупаете... Поэтому их нужно хранить настраиваемым образом... Что ж, если вы хотите использовать SQL DB, вы можете использовать дополнительный НДС таблица с PK, охватывающая два столбца: один CountryID (FK для таблицы стран) и второй RateID (целое число), оба однозначно идентифицируют данную ставку НДС для страны...

person Paweł Dyda    schedule 27.09.2010
comment
Потому что объем вставляемых данных какой-то... огромный, так что использование ресурсов не обсуждается. - person Savvas Sopiadis; 27.09.2010