[development] Drupal and i18n, the holy grail?

[Bèr Kessels]

Op zondag 26 februari 2006 02:54, schreef Adrian Rossouw:
> One of the things i thought about, was using the data from the  
> db_create_table function I'd like to see
> us implement, and be able to spawn new content tables for each language.
>
> Ie: node_en, node_fr, node_<something>

This is somehow, the way i18n works now. 

the .inhstall can ease the pain a bit, but it is subperfect.

I have been thinking about this a lot, and investigated it a bit. I think we 
should add a second t() system. tc(), from translate content.

What that would do: 
We add a single table: content_locale (other names are welcome)
| tcid | lang  | table | column | value |

Then every hand-added item that is not a node, a term, a user or a comment, 
will get this tr around the unrendered output.
Example: 
 menu: I store a menu with 'Read all latest changes to the site' '/tracker' 
from my site. 
 on the place in the code where we know we are rendeing a custom menu item (if 
that is the theme function that would be preferred, but deeper down is right 
as well), we run this function trough tr()
 tr() will
 * check wether this thing exists in the locales and if so use that to 
translate output (cases: custom menu for "archives" is not translated, while 
we did translate it in the po file: confusing for my customers) 
 * else look it up in content_locale 
 * else return the default string.

Obviously we will need some locale-alike interface to translate these strings.

Why this is better then separate tables:
A table contains *all* the data. While 99% of the times you only want to 
translate one single row in a table. Hence we should try to solve this on a 
separate level, IMO.

-- 
| Bèr Kessels | webschuur.com | website development |
| Jabber & Google Talk: ber at jabber.webschuur.com
| http://bler.webschuur.com | http://www.webschuur.com |