[eluser]aquary[/eluser]
My own version for multi languages was like..
- In the database, there are tables, store all the text for each language, let say there are text_en, text_jp, text_cn. Each table has 2 fields (3 on the latest version), which are id, and the text.
- All these table are created/removed by adding/removing languages in the backend. Data would be copied from the "Primary language"
- One language is a primary one, cannot be removed, but the primary could be changed.
Now for other tables require a multilanguages fields, let say a news table:
- Those fields which required multilanguages, instead of being a varchar/text, they will be INT.
- On creation of the table, I'd add the text data to each languages, with some automated function, then save the insert_id, which is returned by the function itself.
- The same also applied to editing, but need the id of the text.
Code:
// insert/update text data to each language table,
// with value posted from the form, with input name of field_name_en, field_name_jp, field_name_cn, etc.
$id=$this->save_text('field_name'); // Insert mode
$id=$this->save_text('field_name', $news->news_title_id); // Update mode, send the stored text id
Lastly is about selecting data, which also has an automated function to select a good language, or all languanges (for backend part).
Code:
// autometically get the text for the current languages, or all langs.
$this->join_lang(array('news_title_id', 'news_content_id'));
The downside is, the query would be exponentially big in the backend, since I call 1 join / language / field. So with 3 fields and 3 languages, it's 9 joins in the backend. The worst I saw was like 7 fields on 5 languages, which is 35 joins....
Another point not yet fixed is, the table must be in sync. Only a row/id missing would make that language got screwed, happened mostly during development. >:3
Atleast it's reusable, without noticably slowing the DB on small-medium websites, as long as the tables are indexed correctly. >:3
