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.
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.
I get some issues when i implement product_description table with language .
my process is that i have default table product_description_en to store description and when a client installs new language (Chinese) the php script will create new table product_des_ch and then put the all default data(from the English table) in to the newly created table.then the client can update .
My problems are
Is it a security issue that we create the table dynamically while installing new language
2.If we use same table for all languages(the records will be around 500,000) then are there any per performance issues
3.what is the best way for large amount of records to store , i mean same table or separate tables.
Thanx
Az
Updated:
This is sample product_description table structure for English table and Japan .What you think about this table(we store the all records in a same table and when the client inserts new record for different language only inserting new records ) ,Any feedback please ?
+---------------------------------------------------------------------------+
| product_id | name | desc | meta_name | meta_desc | key_words | lan_code |
+---------------------------------------------------------------------------+
| 1 | A | D| m1 | m_d1 | k1 | en |
+---------------------------------------------------------------------------+
| 1 | A | D| m2 | m_d2 | k2 | jp |
+---------------------------------------------------------------------------+
Basic RDBMS design wisdom would put a huge red flag on anything that dynamically alters the table structure. Relational databases are more than flexible enough to handle pretty much any situation without requiring such measures.
My suggestion as for the structure would be to create a single Languages table to store the available languages, and then a Phrases table to store all the available phrases. Then use a Translations table to provide the actual translations of those phrases into the available languages. Something that might look like this:
Language
+----+---------+
| id | name |
+----+---------+
| 1 | English |
| 2 | Chinese |
+----+---------+
Phrase
+----+-------------+
| id | label |
+----+-------------+
| 1 | header |
| 2 | description |
+----+-------------+
Translations
+-------------+-----------+-----------------+
| language_id | phrase_id | translation |
+-------------+-----------+-----------------+
| 1 | 1 | Header |
| 1 | 2 | Description |
| 2 | 1 | 头 |
| 2 | 2 | 描述 |
+-------------+-----------+-----------------+
For small to medium sized databases, there should be no performance issues at all even using the default database configurations. If you get to huge sizes (where you are counting the database size in terabytes) you can optimize the database in many ways to keep the performance level acceptable.
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 have a scenario and i'm confused about how i can go about designing the database schema for it.
In my software (php)
there are companies and applications.
companies need to have licenses to access applications.
now the fields (for form while purchasing licenses) for each application is different.
for ex:
for application1:
fields are:
no of users
no of groups
for application2:
no of users
for application3:
number of hours of usage
Prices are based on these fields.
Now i need to design schema for this so that on one page company can manage licenses for all applications.
How can i make this schema generic?
Please help.
Thanks.
You can go with this type of structure
select * from applicationMaster
| APPID | APPNAME |
------------------------
| 1 | Application1 |
| 2 | Application2 |
ApplicationMaster will go with main Application related details which won't be repeated such Name, date etc.
Query 2:
select * from applicationField
| FIELDID | APPID | FIELDNAME |
---------------------------------
| 1 | 1 | NoOfUsers |
| 2 | 1 | NoOfGroups |
| 3 | 2 | NoHourusage |
ApplicationField can adjust any number of field for a particular appId.
So AppId 1 has 2 fields NoofUsers and NoOfGroups. It is also capable to adjust newer fields for a particular app if you want.
Query 3:
ApplicationValue will have the values for every license aplication so it will have compId which represents which company has applied using fieldId which refers to applicationField table we can get for which app values are stored.
select * from applicationValue
| ID | COMPID | FIELDID | FIELDVALUE |
--------------------------------------
| 1 | 1 | 1 | 50 |
| 2 | 1 | 2 | 150 |
| 3 | 2 | 3 | 350 |
| 4 | 3 | 1 | 450 |
| 5 | 3 | 2 | 50 |
applicationPriceMaster stores the price package for each application. There could be multiple package for a application.
select * from applicationPriceMaster
| APPPACKAGE | APPID | TOTALPRICE |
-----------------------------------
| 1 | 1 | 50 |
| 2 | 1 | 100 |
For each application package its details will posted in this table.
select * from applicationPriceDetail
| APPPACKAGE | FIELDID | QUANT |
--------------------------------
| 1 | 1 | 1 |
| 1 | 2 | 1 |
| 2 | 1 | 10 |
| 2 | 2 | 1 |
NOTE Please check the structure as it is now too complex and check what type of queries you would be running on these table and its performance.
select apm.APPPACKAGE, TOTALPRICE from
applicationPriceMaster apm
inner join
(select APPPACKAGE from applicationPriceDetail
where FIELDID=1 and QUANT=1)a
on apm.APPPACKAGE = a.APPPACKAGE
inner join
(select APPPACKAGE from applicationPriceDetail
where FIELDID=2 and QUANT=1)b
on
a.APPPACKAGE=b.APPPACKAGE
SQL FIDDLE:
| APPPACKAGE | TOTALPRICE |
---------------------------
| 1 | 50 |
For single filter you have to use this query, so you have to increase number of inner query with the number of inner filter.
select apm.APPPACKAGE, TOTALPRICE from
applicationPriceMaster apm
inner join
(select APPPACKAGE from applicationPriceDetail
where FIELDID=1 and QUANT=1)a
on apm.APPPACKAGE = a.APPPACKAGE
NOTE-This query is quite complex and will only work if the values are same as mentioned in the packagedetail table and will work only if the values are 2 filter you have to remove 1 inner join if there is only 1 filter. So I suggest you to reconsider before using this approach.
What you have there, could be easily mapped to Classes in an OO language (like PHP). You have an Abstract License, and then 3 Subclasses (ApplicationByUsersAndGroups, etc). Then, mapping to a Relational database is a very common problem, here is a nice article about it: http://www.ibm.com/developerworks/library/ws-mapping-to-rdb/
It has 3 options, it depends on the way you want to structure your application which one you should use. I recommend reading it, it is not that long.
One way is
Table LICENCES:
LICENSE_ID ==> UNIQUE IDENTIFIER
COMPANY_ID ==> references table COMPANIES
APPLICATION_ID ==> references table APPLICATIONS
LICENCE_TYPE ==> either of "BY_GROUPS_AND_USERS", "BY_USERS", "BY_HOURS"
LICENCE_BODY_ID ==> ID of specific body table
[...]
Table LIC_TYPE_BY_GROUPS_AND_USERS:
LICENCE_BODY_ID ==> body identifier
NO_GROUP
NO_USERS
[...]
Table LIC_TYPE_BY_USERS:
LICENCE_BODY_ID ==> body identifier
NO_USERS
[...]
This way, your intention is clear. Even after long time comming back, you will know in no time how things are organized, which fields are used in which case...
how about a table structured this way:
LicenseId int PK
CompanyId Int PK
AppId Int PK
LicenseType int
NumberOfUsers int
NumberOfGroups int
NumberOfHours int
Price Money
Depending on LicenseType, you will use different column in your business logic,
you might need to add CompanyID and/or AppID, that depends how you going to structure those tables as well as relation ships between company/app/license.
Some questions to think about:
Can one company have different License Types for same App?
Can one company have different Apps?
Dont complicate things, if the number of users is unlimited then set it to 999999 or some other max value.
This keeps the license check logic (which will run every time a user logs in ) simple and the same for all applications.
You will need extra logic in the licenses maintenance application, but this should also be pretty simple:
if the cost_per_user is = 0 then set no_of_users = 99999
Again you end up with the same licensing screen and logic for all your applications.
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