This question already has answers here:
Closed 12 years ago.
Possible Duplicates:
Create a webpage with Multilanguage in PHP
PHP - how to translate a website into multiple languages?
I want to make a site which will have 3 languages - e.g. English, Arabic and Italian;
the content sure will be different from one language to another.
Should I make different table for each language, e.g.:
en_articles
ar_articles
it_articles
each with the same article in different language,
or make one table articles like this:
article_id
article_en_title
article_ar_title
article_it_title
Please advise me.
Create a table with a list of languages, and an articles table with a language column. That way, if you add a new language, you only need to add it to the languages table.
Example:
table `languages`:
| id | name |
================
| 1 | English |
| 2 | Arabic |
| 3 | Italian |
table `articles` (only relevant columns):
| language_id | title | content |
=======================================================================
| 1 | Some title | Some content in English |
| 3 | Ascia | Dio mio! C'e' un' ascia nella mia testa! |
| 1 | Axe | Oh my god! There's an axe in my head! |
This way, you won't need to change the database schema when adding languages. As you can see, there is one articles table with one content column - significantly simpler to use than multiple article tables or multiple content columns.
If you are very sure that you are going to work only with 3 languages, the best option is to use one table, with three columns, one for language:
article_id
article_en_title
article_ar_title
article_it_title
If eventually you need to add other language, only add other column.
If you think that you are going to add other languages, o you want to use the code for others web with differents languages, I think that the best solution is to use 3 tables, one for the languages, one for the articles and other table for relation them
table "languages"
language_iso
language_name
table "articles"
article_id
article_name (Internal name for the article)
table "articles_x_languages"
article_id
language_iso
article_title
article_text
I'm assuming that you are going to have each article in the three languages. Example:
Languages
language_iso | language_name
en | English
ar | Arabic
it | Italian
Articles
article_id | article_name
1 | Sample 1
2 | Sample 2
Articles_x_languages
article_id | language_iso | article_title | article_text
1 | en | english title | Lorem ipsum ..
1 | ar | arabic title | Lorem ipsum ..
1 | it | italian title | Lorem ipsum ..
2 | en | english title | Lorem ipsum ..
2 | ar | arabic title | Lorem ipsum ..
2 | it | italian title | Lorem ipsum ..
I would suggest that you create only one table for the articles and put a column for the language. So, if you need to add a new language you don't need to change anything in your db
When you use PHP, you can see here: http://www.bitrepository.com/php-how-to-add-multi-language-support-to-a-website.html
If you are writing your website using java you might want to search about JAVA ResourceBundle, here is an example : http://java.sun.com/docs/books/tutorial/i18n/resbundle/propfile.html
If you are working with asp.NET you might want to check this: http://msdn.microsoft.com/en-us/library/ms228208.
If you work with ASP.Net , look at here
http://msdn.microsoft.com/en-us/library/c6zyy3s9.aspx
Related
I need to design a db model for a backend module where user can translate page content into multiple languages. The things that will be translated are basic words, phrases, link names, titles, field names, field values. They should also be grouped so i can find them by group name. For example if there is a select field on page with different colors as options then i should be able to select all of them by group name.
So here is what i have at the moment:
lang
+----+---------+
| id | name |
+----+---------+
| 1 | english |
| 2 | german |
+----+---------+
lang_entity
+----+------------+-------------+-------+-------+
| id | module | group | name | order |
+----+------------+-------------+-------+-------+
| 1 | general | | hello | 0 |
| 2 | accounting | colorSelect | one | 1 |
| 3 | accounting | colorSelect | two | 2 |
| 4 | accounting | colorSelect | three | 3 |
+----+------------+-------------+-------+-------+
lang_entity_translation
+----+---------+----------------+-------------+
| id | lang_id | lang_entity_id | translation |
+----+---------+----------------+-------------+
| 1 | 1 | 1 | Hello |
| 2 | 2 | 1 | Guten tag |
| 3 | 1 | 2 | One |
| 4 | 2 | 2 | Ein |
| 5 | 1 | 3 | Two |
| 6 | 2 | 3 | Zwei |
| 7 | 1 | 4 | Three |
| 8 | 2 | 4 | Drei |
+----+---------+----------------+-------------+
So lang table holds different languages.
Table lang_entity has entities that can be translated for different languages.
Module row is just to group them by page modules in the backend translating module. Also this gives me possiblity to have entities with same name for different modules.
Group as mentioned is needed for selects and maybe some other places where multiple values are going to be used. This also gives me an option to allow user to add and order entities in one group.
And table lang_entity_translation holds the translations for each entity in each language.
So my question is are visible flaws in this kind of a design? Would you reccomend something different?
Also a bonus question: I really dont like the lang_entity table name, do you have a better idea of a table name that would hold all the words/phrases that are translated? :)
Edit: similar, but not a duplicate. The linked question is about translating dynamic products and having a seperate table for each translated type. Im talking about translating whole page content, including groups in a single table.
I don't understand the order column of lang_entity, but then I probably don't need to.
The setup looks sane, but make sure you add foreign key constraints from lang_entity_translation to language and lang_entity.
As for naming, I would call the table phrase or translatable.
We had similar situation. This was 7 years before.
We had different column for different language. Like for name we had
Name_Eng,Name_Ger,Name_Spa .We had 7-10 language.
We had common id for name for all language.
Based on the Language selection from UI we passed the language code to Back end In the Stored proc it was appended to the column Name
Example, we will be passing "Eng" if English is selected and we form the column name as Name_Eng and fetch the data. we were using dynamic query.
Is it bad idea to hold translation in database and display words translation based on user settings. I imagined something like this:
mysql
lang | greeting
spanish | ola
english | hi
for example
$sql=mysql_query("SELECT * FROM lang where lang='spanish'");
and then just echo that value in proper div
You can have 1 table for your languages
id_lang | label
1 | English
2 | Spanish
3 | French
And then each your other tables can have a second key id like this for exemple :
traduction_table
id | id_lang | value
1 | 1 | Hi
2 | 2 | Ola
3 | 3 | Salut
You need tu have primary keys on id and id_lang.
Then you just have to make your SQL requests correctly, like :
select * from traduction_table where ID = 1 and id_lang = ??
Where ?? is replaced by the user language ofc.
From my experience, best is maintaining what I call "interface" texts (English "cancel",Spanish "cancelar",...) with .po files (gettext standard)
On the other hand, all texts likely to be editable by the user, they should be stored in database. Per example, if it is a site which needs to publish a description in different languages, and this description needs to be edited/maintained by the user, and not by the programmer, then you should store the translations in database. And yes,somehing like that table you said is a good idea.
This way you don't need to add columns for extra languages.
id | text | lang
------------------------
1 | ola |spanish
2 | hi |english
I am trying to build an English and French website by pulling the information from a MySQL table but I am stuck. I think that kind of query is too advance for me. My idea is having a table with both language translated and assign them with an ID.
Here's the table lang
+--------+-------------------+----------------------+
| id | English | French |
+--------+-------------------+----------------------+
| 1 | Verbal Warning | Avis verbal |
| 2 | Written Warning | Avis écrit |
| 3 | Evaluation | Évaluation |
| 4 | Other (specify) | Autres (spécifiez) |
+--------+-------------------+----------------------+
Then I have another table that people inputs 'Topic' into the database. So when I switch the page to French the content of the table will display in French.
+-----------+---------+
| EMP_ID | Topic |
+-----------+---------+
| 845689 | 4 |
| 185648 | 3 |
| 485497 | 1 |
| 416798 | 2 |
+-----------+---------+
I want the ouput to be this in a table when we're on the English page
+-----------+------------------+
| EMP_ID | Topic |
+-----------+------------------+
| 845689 | Other (specify) |
| 185648 | Evaluation |
| 485497 | Verbal Warning |
| 416798 | Written Warning |
+-----------+------------------+
then this when it's the French page is selected.
+-----------+---------------------+
| EMP_ID | Topic |
+-----------+---------------------+
| 845689 | Autres (spécifiez) |
| 185648 | Évaluation |
| 485497 | Avis verbal |
| 416798 | Avis écrit |
+-----------+---------------------+
Is there a way to make it work or there's easier ways to display
As suggested in another answer, it would be better to store your language strings in files, and use Javascript to load them. I would suggest to use i18next, which is a very useful and easy-to-use JS library. It would really be simple :
/* en.json */
{
"home":{
"title":"Hello, world !",
"welcomeMessage":"Welcome to my great website !"
}
}
/* fr.json */
{
"home":{
"title":"Bonjour !",
"welcomeMessage":"Bienvenue sur mon superbe site web"
}
}
In your html code :
<!-- head and other stuffs... -->
<script type="text/javascript" src="i18next.js"></script>
<body onload="translate()">
<h1 i18n-data="home.title"></h1>
<p i18n-data="home.welcomeMessage"></p>
</body>
In your functions JS file :
function translate() {
i18n.init({
resGetPath:'en.json',
getAsync:false
}).done(function(){
$('[data-i18n]').i18n();
});
}
This way, your website will run faster (less database calls), and it will be easier to add/update some strings. Hope it will help :)
There is no reason to keep lang schema in DB, try to include files with your lang instead.
Well you shouldn't change the table content each time someone loads the page that would be a performance catastrophe ;-) But you can make a SQL Join Query.
If you are on the french page you do
SELECT l.French FROM topic AS t
JOIN lang AS l ON t.Topic = l.id
WHERE t.EMP_ID = $emp_id;
and on the english you do
SELECT l.English FROM topic AS t
JOIN lang AS l ON t.Topic = l.id
WHERE t.EMP_ID = $emp_id;
I think the easiest way will be to create a view per language:
For French:
CREATE VIEW empl_fr
AS
SELECT
emp.EMP_ID as EMP_ID
, lang.French as Topic
FROM employee emp, language lang
WHERE emp.Topic = lang.id
For English:
CREATE VIEW empl_en
AS
SELECT
emp.EMP_ID as EMP_ID
, lang.English as Topic
FROM employee emp, language lang
WHERE emp.Topic = lang.id
and then you can query your topics like:
SELECT * FROM empl_fr
or
SELECT * FROM empl_en
The more suffisticated way will be to create a view with both languages and query your view with a language parameter
To make your site extensible and easy to support future, additional languages; I’d suggest using MySQL in its intended fashion and create a relational schema.
If you have topics, and topic titles are to be translatable, then you’ll need three tables: a topics table, a languages table, and a table that joins the two.
Your topics table is easy: you just need a primary key, and any other language-independent columns (such as created, modified etc). For the languages table, store again a primary key, the language name, and maybe an ISO short code for consistent naming/identification.
Finally, your join table (could be called languages_topics) is where the associations happen. You would have two foreign keys (topic_id and language_id) and another column that actually holds the localised value.
For example, if English is language ID 1 and French is language ID 2, then your table could look as follows:
+----------+-------------+----------------+
| topic_id | language_id | value |
+----------+-------------+----------------+
| 1 | 1 | Verbal Warning |
| 1 | 2 | Avis verbal |
+----------+-------------+----------------+
As you can see, a topic can have multiple rows in this table, with a record per language to offer up the translations.
I know this maybe doesn’t exactly answer your question, but should set you on the right path on how best to store your data. Languages can easily be added in the future without needing to modify your database schema.
I am trying to create a table in a more accurate and professional manner.
I need two fields TITLE and DESCRIPTION for two languages, but I'm not quite sure if I won't add a third language after a while.
Which one would you prefer?
-----------------------------------------------------------
id | title_en | title_ge | description_en | description_ge
-----------------------------------------------------------
...|..........|..........|................|................
-----------------------------------------------------------
or
---------------------------
id | titles | descriptions
---------------------------
...|serialized| serialized
---------------------------
where serialized is like this
array(
'en' => 'title for english',
'ge' => 'title for georgian'
)
Or any other suggestions? Thanks for future recomendations.
I would do it in a combination of two tables.
Your first table should include titles and description in just english. Similar to what you have right now.
Your secondary table will include translations. With a structure something like:
-----------------------------------
doc_id | lang | title | description
-----------------------------------
You would put a primary key that would include both doc_id and lang and fulltext indexes on title and description.
This way you could construct a query that would fallback to the original english text if a translation for the language you are looking for does not exist, as well as limit your searching to one specific language or another.
I would create a table with four fields
(id,title,description,language)
--------------------------------------
id | titles | descriptions | language
---------------------------------------
1 |title in en| desc in en | en
----------------------------------------
2 |title in ge| desc in ge | ge
I'm currently building an application that would recommend website base on their tag.
On my website when a user registers, it will fill out an interests. So this is a sample interest:
football, model trains, hockey
So this is separated by commas. So when the user clicks on register that will be saved in my database. This is the design of my database.
userID | name | interest
001 | John Doe | sports, model trains, hockey
So on the other hand, I also have users in my sites who uploads website URLs and also creates a tag related to it. So this is my database design for that:
postID | title | tags
001 | techcrunch.com | technology,softwares,startups
002 | nba.com | basketball,sports,all-star
003 | tmz.com | gossip, showbiz
So the logic for this one is that, I wanted to recommend NBA.com to user John Doe since NBA.com has a tag of sports and John Doe's interest has a sports tag.
Do you have any idea how to do that one? Just a follow up question, Is the database design correct or should I create a new table to store all the tags. Something like that (not sure though).
Your help would be greatly appreciated and rewarded! Thanks in advance! :)
I would have normalized the database so that you have tags in a separate table and relationship tables to connect with it. As such:
User table:
UserId Name
001 John Does
TagUserRelation
UserId TagId
001 001
Tag table:
TagId TagName
001 Sports
TagUrlRelation
TagId Url
001 nba.com
001 nhl.com
To increase performance I would have continued by creating indexed views with the necessary joins and implementing stored procedures to work with them.
An alternative, as mentioned, is full text search but this will be much slower and generally not considered good database design in this case.
this can be done by using full text search
refer here
You should create two separate table which hold single tags, several for each person or post.
You can create a multi-column primary key for it if you wish.
userID | interest
001 | sports
001 | model trains
001 | hockey
...
and the same way for posts:
postID | tags
003 | gossip
003 | showbiz
...
This greatly enhances your chances to write efficient SQL.
It would be much better to store the tags separately. So that you have a table for the tags and two more tables - one for the relationship between users and tags, and one for the relationship between posts and tags.
users
----------------------------------------
userId | name | password | ....
1 | John Doe | $p$fgA |
tags
--------------------
tagId | tagname
1 | basketball
2 | hockey
user_interests
----------------------------
id | user_id | tag_id
1 | 1 | 1
2 | 1 | 2
post_tags
--------------------------
id | post_id | tag_id
1 | 1 | 2
Then you use JOINs to get the required information