CODEWITHSUNDEEP
phpmysqljsonlocalizationinternationalization
Cranio
Cranio

Reputation: 9847

MySQL Database I18N, a JSON approach?

UPDATE: I've come across this question I did after some years: now I know this is a very bad approach. Please don't use this. You can always use additional tables for i18n (for example products and products_lang), with separate entries for every locale: better for indexes, better for search, etc.

I'm trying to implement i18n in a MySQL/PHP site.

I've read answers stating that "i18n is not part of database normally", which I think is a somewhat narrow-minded approach. What about product namesd, or, like in my instance, a menu structure and contents stored in the db?

I would like to know what do you think of my approach, taking into account that the languages should be extensible, so I'm trying to avoid the "one column for each language solution".

One solution would be to use a reference (id) for the string to translate and for every translatable column have a table with primary key, string id, language id and translation.

Another solution I thought was to use JSON. So a menu entry in my db would look like:

idmenu label
------ -------------------------------------------
5      {"en":"Homepage", "it":"pagina principale"}

What do you think of this approach?

Upvotes: 5

Views: 4053

Answers (4)

Nic Cottrell
Nic Cottrell

Reputation: 9665

I would recommend keeping a single primary language in the database and using an extra sub-system to maintain the translations. This is the standard approach for web applications like Drupal. Most likely in the domain of your software/application there will be a single translation for each primary language string, so you don't hav to worry about context or ambiguity. (In fact for best user experience you should strive to have unique labels for unique functionality anyway).

If you want to roll your own table, you could have something like:

create table translations (
  id          int          not null primary key
, source      varchar(255) not null // the text in the primary language
, lang        varchar(5)   not null // the language of the translation
, translation varchar(255) not null // the text of the translation
)

You probably want more than 2 characters for language since you'll likely want en_US, en_UK etc.

Upvotes: 0

Roland Bouman
Roland Bouman

Reputation: 31961

"One solution would be to use a reference (id) for the string to translate and for every translatable column have a table with primary key, string id, language id and translation."

I implemented it once, what i did was I took the existing database schema, looked for all tables with translatable text columns, and for each such table I created a separate table containing only those text columns, and an additional language id and id to tie it to the "data" row in the original table. So if I had:

create table product (
  id          int          not null primary key
, sku         varchar(12)  not null
, price       decimal(8,2) not null
, name        varchar(64)  not null
, description text          
)

I would create:

create table product_text (
  product_id  int          not null
, language_id int          not null
, name        varchar(64)  not null
, description text
, primary key (product_id, language_id)
, foreign key (product_id) references product(id)
, foreign key (language_id) references language(id)
)

And I would query like so:

SELECT    product.id
,         COALESCE(product_text.name, product.name) name
,         COALESCE(product_text.description, product.description) description
FROM      product
LEFT JOIN product_text
ON        product.id = product_text.product_id 
AND       10         = product_text.language_id

(10 would happen to be the language id which you're interested in right now.)

As you can see the original table retains the text columns - these serve as default in case no translation is available for the current language.

So no need to create a separate table for each text column, just one table for all text columns (per original table)

Like others pointed out, the JSON idea has the problem that it will be pretty impossible to query it, which in turn means being unable to extract only the translation you need at a particular time.

Upvotes: 4

Alexander Palamarchuk
Alexander Palamarchuk

Reputation: 879

This is not an extension. You loose all advantages of using a relational database. By way like yours you may use serialize() for much better performance of decoding and store data even in files. There is no especial meen to use SQL with such structures.

I think no problem to use columns for all languages. That's even easier in programming of CMS. A relational database is not only for storing data. It is for rational working with data (e.g. using powerful built-in mechanisms) and controlling the structure and integrity of data.

Upvotes: 1

Jerzy Zawadzki
Jerzy Zawadzki

Reputation: 1985

first thought: this would obviously brake exact searching in sql WHERE label='Homepage' second: user while search would be able to see not needed results (when e.g. his query was find in other languge string)

Upvotes: 0

Related Questions