Adrian, <br>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.
<br><br>Bčr – thank you for starting this thread up. This is a great discussion to flush out some ideas.<br>Thanks<br>--eric<br>Eric Gundersen<br>Development Seed<br><br><div><span class="gmail_quote">On 2/26/06, <b class="gmail_sendername">
Bčr Kessels</b> <<a href="mailto:ber@webschuur.com">ber@webschuur.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Op zondag 26 februari 2006 02:54, schreef Adrian Rossouw:<br>> One of the things i thought about, was using the data from the <br>> db_create_table function I'd like to see<br>> us implement, and be able to spawn new content tables for each language.
<br>><br>> Ie: node_en, node_fr, node_<something><br><br>This is somehow, the way i18n works now.<br><br>the .inhstall can ease the pain a bit, but it is subperfect.<br><br>I have been thinking about this a lot, and investigated it a bit. I think we
<br>should add a second t() system. tc(), from translate content.<br><br>What that would do:<br>We add a single table: content_locale (other names are welcome)<br>| tcid | lang | table | column | value |<br><br>Then every hand-added item that is not a node, a term, a user or a comment,
<br>will get this tr around the unrendered output.<br>Example:<br> menu: I store a menu with 'Read all latest changes to the site' '/tracker'<br>from my site.<br> on the place in the code where we know we are rendeing a custom menu item (if
<br>that is the theme function that would be preferred, but deeper down is right<br>as well), we run this function trough tr()<br> tr() will<br> * check wether this thing exists in the locales and if so use that to<br>translate output (cases: custom menu for "archives" is not translated, while
<br>we did translate it in the po file: confusing for my customers)<br> * else look it up in content_locale<br> * else return the default string.<br><br>Obviously we will need some locale-alike interface to translate these strings.
<br><br>Why this is better then separate tables:<br>A table contains *all* the data. While 99% of the times you only want to<br>translate one single row in a table. Hence we should try to solve this on a<br>separate level, IMO.
<br><br>--<br>| Bčr Kessels | <a href="http://webschuur.com">webschuur.com</a> | website development |<br>| Jabber & Google Talk: <a href="mailto:ber@jabber.webschuur.com">ber@jabber.webschuur.com</a><br>| <a href="http://bler.webschuur.com">
http://bler.webschuur.com</a> | <a href="http://www.webschuur.com">http://www.webschuur.com</a> |<br></blockquote></div><br><br clear="all"><br>-- <br>-- <br>Eric Gundersen<br>Development Seed<br>Strategies Design and Gardening
<br><a href="http://www.developmentseed.org">http://www.developmentseed.org</a><br><a href="http://www.developmentseed.org/blog">http://www.developmentseed.org/blog</a><br>ericgundersen(skype)<br>Tel. 202.250.3633 <br>SMS.
202.297.0671<br>Fax. 806.214.6218<br>