How to localize sql server data? - sql

We have a requirement to develope an application that support multiple languages (English, German, French, Russian) and we know, we can use ASP.NET localization to localize static text of a web form but what would be the approach for data localization of a database in SQL server.
for example my database schema is something like this:
Table-Questions
QID-PK
Question
CreatedBy
Table- Answer
AID-PK
QID- FK
Answer
AddedBy
In the above schema,I want the column "question" from Question table and column "Answer" from Answer table should keep localization value.
How do I achive this.

Add a Language table:
LanguageID-PK
LanguageIdentifier (name as accepted by CultureInfo's constructor, e.g. "de" for German)
Add a TranslatedQuestion table:
TQID-PK
QID-FK
LanguageID
Translation
Likewise, add a TranslatedAnswer table:
TAID-PK
AID-FK
LanguageID
Translation
This way, of course there is nothing in the data model to guarantee that every question/answer has a transation for a given language. But you can always fall back to the untranslated question/answer.

Add a culture column to the table, then repeat the questions and answers in the culture specific format.

Related

Postgres: Is there a way to target specific tables based on your data?

I'm new to SQL and I'm currently thinking about an effective way to build out my database. It's a language learning application and I'm torn between two approaches:
Keeping all of my words, regardless of their language, in one giant words table
Splitting my words into separate tables based on their language, ie: words_french, words_italian, etc.
In the second scenario, are there approaches that I can use (perhaps within Postgres) that would allow me target the words_french table in the event that I'm currently working through french lessons / content and need to lookup associated french words?
I feel like there would be some sort of concat process like so: words_${language} and as of this moment I'd figure i'd have to resolve this within JS or something else on the frontend.
-- also, is breaking words and other content into their respective table_language even a valid approach?
Any ideas?
Use Option 1. Option 2 would be horribly difficult to work with.
Word table:
WordId
Word
Language
1
a
English
2
un
French
As Dimitar Spasovski suggests, if you have a need for additional attributes associated with the language, you should also have a Language table. Then replace the Language column in the Word with LanguageId to make the relationship.
Watching or reading some data modeling or data architecture classes online will help.

DataBase design for store anketing data

my English is not well, so sorry for it.
I want to write the web-app for anketing. I mean, that it must be a site, where user may give answers on different questions. For example, it can be question with text type of answer, or checkbox, or lookup (comboBox).
And my problem is in data base architecture. I read a lot about Entity Attribute Value db pattern, One True Lookup Table I also read. But these patterns has problem (with ms sql) when building a sql-query for data selecting (report).
I hope somebody give me a good suggestion, and tell, what can I do with this proplem.
Thanks!
Almost everything can be represented as a string. Why not store a string in the database e.g. Text Type Answer or "true" "false" or ComboBox Value etc. Then simply convert the value from the database if necessary at runtime or in SQL if writing a query?
I feel Entity Attribute Value pattern is meant more for Entities which can have dynamic fields added etc, not so much for the problem you've posed here.
If necessary you could also add an additional column to the database table to specify the "type" of data being stored. You could then use that column to base your query convert statements on etc.

Internationalization in .NET. Database driven? Resources interactively?

I am working on the internationalization of a CMS in .NET (VB.NET). In the administration part we used resources, but for the clients we want a UI so someone can see the labels and translate them from one language to another.
So, the first thought was to do it database driven with three tables:
Label Translation Language
----- ----------- --------
id id id
name keyname_id name
filename language_id
value
And then create an UI so you can allow the client to first select the filename of the page you want to translate, the label, and then select the language he wants and translate it, and it would be stored in the translations table.
I see here a problem: How would I take from the page all the labels?
I also spotted an example of a resources manager that can translate in an interactive way. This is the example.
The benefits of this solution is that you are working with resources, so everything seems easier because some work is done. On the other hand, this structure can be more difficult to implement, I don't know as I'm not experienced on this.
So, what do you think about these two approaches? What is better for you? Maybe there is a third approach that is easier?
EDIT: I also found this link about Resource-provider model. What do you think about it? Maybe it can be useful,but I don't know, maybe it's too much for my purposes. I am thinking where to start
In LedgerSMB, we went with the following approach:
Application strings (and strings in code) get translated by a standard i18n framework (GNU gettext basically).
Business data gets manual translation in the database. So you can add translations to department names, project names,descriptions of goods and services etc.
Our approach to the problem you say is to join the other tables, so we might have:
CREATE TABLE parts (
id int primary key.... -- autoincrements but not relevant to this example
description text,
...
);
CREATE TABLE language (
code varchar(5) primary key, -- like en_US
name text unique,
);
CREATE TABLE parts_translation (
parts_id int not null references parts(id),
language_code varchar(5) not null references language(code),
translation text
);
Then we can query based on desired language at run time.

Localize dbms demo data

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?
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...

What are best practices for multi-language database design? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
What is the best way to create multi-language database? To create localized table for every table is making design and querying complex, in other case to add column for each language is simple but not dynamic, please help me to understand what is the best choose for enterprise applications
What we do, is to create two tables for each multilingual object.
E.g. the first table contains only language-neutral data (primary key, etc.) and the second table contains one record per language, containing the localized data plus the ISO code of the language.
In some cases we add a DefaultLanguage field, so that we can fall-back to that language if no localized data is available for a specified language.
Example:
Table "Product":
----------------
ID : int
<any other language-neutral fields>
Table "ProductTranslations"
---------------------------
ID : int (foreign key referencing the Product)
Language : varchar (e.g. "en-US", "de-CH")
IsDefault : bit
ProductDescription : nvarchar
<any other localized data>
With this approach, you can handle as many languages as needed (without having to add additional fields for each new language).
Update (2014-12-14): please have a look at this answer, for some additional information about the implementation used to load multilingual data into an application.
I recommend the answer posted by Martin.
But you seem to be concerned about your queries getting too complex:
To create localized table for every table is making design and querying complex...
So you might be thinking, that instead of writing simple queries like this:
SELECT price, name, description FROM Products WHERE price < 100
...you would need to start writing queries like that:
SELECT
p.price, pt.name, pt.description
FROM
Products p JOIN ProductTranslations pt
ON (p.id = pt.id AND pt.lang = "en")
WHERE
price < 100
Not a very pretty perspective.
But instead of doing it manually you should develop your own database access class, that pre-parses the SQL that contains your special localization markup and converts it to the actual SQL you will need to send to the database.
Using that system might look something like this:
db.setLocale("en");
db.query("SELECT p.price, _(p.name), _(p.description)
FROM _(Products p) WHERE price < 100");
And I'm sure you can do even better that that.
The key is to have your tables and fields named in uniform way.
I find this type of approach works for me:
Product ProductDetail Country
========= ================== =========
ProductId ProductDetailId CountryId
- etc - ProductId CountryName
CountryId Language
ProductName - etc -
ProductDescription
- etc -
The ProductDetail table holds all the translations (for product name, description etc..) in the languages you want to support. Depending on your app's requirements, you may wish to break the Country table down to use regional languages too.
I'm using next approach:
Product
ProductID OrderID,...
ProductInfo
ProductID Title Name LanguageID
Language
LanguageID Name Culture,....
Martin's solution is very similar to mine, however how would you handle a default descriptions when the desired translation isn't found ?
Would that require an IFNULL() and another SELECT statement for each field ?
The default translation would be stored in the same table, where a flag like "isDefault" indicates wether that description is the default description in case none has been found for the current language.