views:

20

answers:

1

Hi everybody!

I'm developing a windows mobile application which should work in multiple languages (English, German, French, Russian).

This application is about to be shown to customers (Germans, Russians,...) and we would like to generate data depending on the culture it is setup for.

So: has anybody thought of a way to create data which than is about to be inserted into the dbms at runtime?

For example: tha VAT description for the english version reads "VAT 17.5%" with value 17.5, the german version "Mehrwertsteuer 19%" with value 19, the french version "TVA 19.6%" with value 19.6

Thanks in advance

EDIT

I admit i was not very clear. I need a set of data to be localized. I need a mechanism which somehow reads this "prepared" localized data and inserts into the dbms.

A second thought of mine would be to use a XML file which has the same structure for all the languages (but of course different values), e.g

datafile.en-US.xml

datafile.de-DE.xml

What do you think about this?

A: 

I don't quite know what is your aim, so I could be mistaken here... Anyway, if you planning to distribute your Windows Mobile client application across various countries and one language version is to work in one country, I would suggest using resource files instead SQL DB. You could put messages like "VAT {0}", "TVA {0}" and format them at runtime (depending on programming language it would look different, please find C#/.Net example below) preserving valid cultural format.

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

If you still need to add VAT value to SQL for reference, you can simply add one decimal column which will hold either foreign key to VAT table or simply VAT value...

Update on different VAT values

The problem is that, VAT values differs not only by countries but also depending on what you purchase... Therefore one need to store them in configurable way... Well, if you want to go with SQL DB, you could use additional VAT table with PK spanned across two columns: one CountryID (FK for Country table) and the second RateID (Integer) both uniquely identifying given VAT rate for the country...

Paweł Dyda
Because the amount of data to be inserted is somehow ... "huge", so using resources is out of discussion.
Savvas Sopiadis