[development] Drupal and i18n, the holy grail?

[Eric Gundersen]

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 at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20060226/6c29af3a/attachment-0001.htm