Adrian, You have a really good point here about extending the prefixing to use these language specific tables – with timestamps and version id's on each of the tables. It makes a better workflow for the site owners that are struggling to add content, let alone make sure that the content is added in all languages. This is often done is a piecemeal fashion. Especially at larger organizations, the review and editing of translated content can be a nightmare. Using the workflow functionality and versioning controls in Drupal combined with the i18n will greatly help out folks managing large sites. Bèr – thank you for starting this thread up. This is a great discussion to flush out some ideas. Thanks --eric Eric Gundersen Development Seed On 2/26/06, Bèr Kessels <ber@webschuur.com> wrote:
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@jabber.webschuur.com | http://bler.webschuur.com | http://www.webschuur.com |
-- -- Eric Gundersen Development Seed Strategies Design and Gardening http://www.developmentseed.org http://www.developmentseed.org/blog ericgundersen(skype) Tel. 202.250.3633 SMS. 202.297.0671 Fax. 806.214.6218