Drupal and i18n, the holy grail?
Or, how to get the i18n project rolling. online here too http://www.webschuur.com/node/525 First of all we need to recognise that there is no Ultimate i18n solution. There are many, all depending on the different needs, cases and implementations. So, I really do not believe in a single i18n module. Or in a holy grail. Therefore I torn the problem apart, and made Lego blocks out of it. That way the problem becomes rather clear. On the top level there are a few types of i18n sites: 1 Mixed content. Sometimes I blog in English, sometimes in Dutch. 2 Mirrored translations. For *every single item* in a "normal" site, you now need X amount (X being amount of active languages). this can be reduced by saying 'I need admin areas only in language A, admin is defined as Foo and Bar' 3 Growing translations. For every piece of content there may, or may not, be a translation. Think about freetagging (a tag beer and a tag bier). Or about community efforts to get pages translated. interlingual connections (read this in langB) lay, or may not be required. 4 A few pages in langA to explain what its about. Simple, just maintain a few pages in another language.[1] 5 Inline translations. Only certain elements of content have to be translated. Example: a photogallery with only English and Dutch "descriptions". They may appear on one page even. Other elements may not be translated like the title, that can be the same for both languages. We can also differentiate some other translations areas. The clear difference being: 1 content (terms, nodes, comments, profiles. oh if only they all were *cough* :)) 2 interfaces (PO file import export) 3 admin submitted configuration (think menu-titles, or user roles, or flexinode types, or profile fields) The good news, is that all the types have one common denominator: language switching. Except maybe for site type 4. The bad news is that both workflow and interfaces differ a *lot* between the various types. So here is what I propose: * locale.module+locale.inc, current implementation MINUS language choosing/switching interface and code! handles "translate area 2". * lang_switcher.module. A *simple* API/library module containing only APIs and a block to select languages. No editing interfaces or forms should be in there. Should also contain the three methods of storing the language in APIs. $SESSION, url prefix /en/node/12 /fr/node/12 and url postfix ?lang=en. * config_translation.inc. the toughest part: a contrib that allows us to translate missions, blocks, menu-items etc. handles "translate area 3". I have a fuzzy vision of some form_alter, combined with table prefixing (ugh!) and variable_get/_set prefixing. Needs clear thought. * Loads of modules and or themes using these APIs and systems to allow a variety of cases and workflows. Node_translator.module, comment_lang_switchers (yes, ever thought of how to avoid EN comments appearing under the DE version, heh?). oh and, off course a contrib user_profile_lang.module, containing the part from locale.module, where you store your language preference in your profile. And now? Fists in the air and *ffoooorwaaaaaaard* :) Serious: if we think these Lego blocks are well defined, we only need to make them, the blocks. Most of this is ripping stuff from existing modules, putting that in other modules and finetune that. Oh, and occasionally we need to build non-existing stuff, like config_translation.inc/.module. Starting here, IMO is better then writing down that the industry needs i18n, not? Or developing yet another module for translating the 60% your specific case needs translated (and no-one else will ever need). BZR? CVS? bright SVN? Drupal.org issues? where to start? Bèr [1] unfortunately not /that/ simple, because if you want to have poor SEO and so, you need to add the lang="" entity to the surrounding XHTML.
I think an approach worth considering is having hooks in core for multilingual content (e.g. a lang column in nodes, menus, blocks, ...etc.), and let contribs handle those hooks in multiple ways. I met Eric Gunderson of Development Seed at DrupalCON and talked about that a bit. Jose Reyero, the author of the i18n module has a plan on keeping up with 4.7. It is described here http://www.developmentseed.org/blog/internationalization/drupal4-7 There is also the tr module http://cvs.drupal.org/viewcvs/drupal/contributions/modules/tr/ It is worthwhile that Ber coordinates with Jose and/or Eric, et al for a unified solution. On 2/25/06, Bèr Kessels <ber@webschuur.com> wrote:
Or, how to get the i18n project rolling.
online here too http://www.webschuur.com/node/525
First of all we need to recognise that there is no Ultimate i18n solution. There are many, all depending on the different needs, cases and implementations. So, I really do not believe in a single i18n module. Or in a holy grail.
Therefore I torn the problem apart, and made Lego blocks out of it. That way the problem becomes rather clear.
On the top level there are a few types of i18n sites: 1 Mixed content. Sometimes I blog in English, sometimes in Dutch. 2 Mirrored translations. For *every single item* in a "normal" site, you now need X amount (X being amount of active languages). this can be reduced by saying 'I need admin areas only in language A, admin is defined as Foo and Bar' 3 Growing translations. For every piece of content there may, or may not, be a translation. Think about freetagging (a tag beer and a tag bier). Or about community efforts to get pages translated. interlingual connections (read this in langB) lay, or may not be required. 4 A few pages in langA to explain what its about. Simple, just maintain a few pages in another language.[1] 5 Inline translations. Only certain elements of content have to be translated. Example: a photogallery with only English and Dutch "descriptions". They may appear on one page even. Other elements may not be translated like the title, that can be the same for both languages.
We can also differentiate some other translations areas. The clear difference being: 1 content (terms, nodes, comments, profiles. oh if only they all were *cough* :)) 2 interfaces (PO file import export) 3 admin submitted configuration (think menu-titles, or user roles, or flexinode types, or profile fields)
The good news, is that all the types have one common denominator: language switching. Except maybe for site type 4.
The bad news is that both workflow and interfaces differ a *lot* between the various types.
So here is what I propose: * locale.module+locale.inc, current implementation MINUS language choosing/switching interface and code! handles "translate area 2". * lang_switcher.module. A *simple* API/library module containing only APIs and a block to select languages. No editing interfaces or forms should be in there. Should also contain the three methods of storing the language in APIs. $SESSION, url prefix /en/node/12 /fr/node/12 and url postfix ?lang=en. * config_translation.inc. the toughest part: a contrib that allows us to translate missions, blocks, menu-items etc. handles "translate area 3". I have a fuzzy vision of some form_alter, combined with table prefixing (ugh!) and variable_get/_set prefixing. Needs clear thought. * Loads of modules and or themes using these APIs and systems to allow a variety of cases and workflows. Node_translator.module, comment_lang_switchers (yes, ever thought of how to avoid EN comments appearing under the DE version, heh?). oh and, off course a contrib user_profile_lang.module, containing the part from locale.module, where you store your language preference in your profile.
And now? Fists in the air and *ffoooorwaaaaaaard* :)
Serious: if we think these Lego blocks are well defined, we only need to make them, the blocks. Most of this is ripping stuff from existing modules, putting that in other modules and finetune that. Oh, and occasionally we need to build non-existing stuff, like config_translation.inc/.module.
Starting here, IMO is better then writing down that the industry needs i18n, not? Or developing yet another module for translating the 60% your specific case needs translated (and no-one else will ever need).
BZR? CVS? bright SVN? Drupal.org issues? where to start?
Bèr
[1] unfortunately not /that/ simple, because if you want to have poor SEO and so, you need to add the lang="" entity to the surrounding XHTML.
On 25 Feb 2006, at 4:15 PM, Khalid B wrote:
I think an approach worth considering is having hooks in core for multilingual content (e.g. a lang column in nodes, menus, blocks, ...etc.), and let contribs handle those hooks in multiple ways.
Also. remember my cascading variables table ? that would allow for localisation of all variables. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
Op zaterdag 25 februari 2006 15:22, schreef Adrian Rossouw:
Also. remember my cascading variables table ?
Do you have writings or slides online?
that would allow for localisation of all variables.
It would. It would slve what we now need to do by prefixing tables and so on. in other words, it sonds like the route to take to tackle the "3 admin submitted configuration" in a config_translation.inc Care to share yuor thoughts on this Adrian? Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]
On 25 Feb 2006, at 4:30 PM, Bèr Kessels wrote:
Care to share yuor thoughts on this Adrian?
add 2 columns to the variables table, namely 'realm' and 'id' During system initalisation, do : variable_init('realm', $id) , to load that realm's settings into memory. In the example of locale, you would have : function locale_init() { variable_init('locale', $GLOBALS['lang']); } What this would do, is load the settings onto the setting stack. so when you do variable_get('my_setting', 'default') it would get the top most variable for that from the stack. This would be useful for the following cases : user specific settings layout/view specific settings (the successor to the sections module) locale specific settings (this example) install profile specific settings (install profile specified defaults) and quite a few more. Remember that just because you can override any setting doesn't mean you will be able to from the interface. You still need to actually have a form element to capture the setting for that specific layer, although you might just change the default layer that things save to. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
Op zaterdag 25 februari 2006 15:47, schreef Adrian Rossouw:
Remember that just because you can override any setting doesn't mean you will be able to from the interface. You still need to actually have a form element to capture the setting for that specific layer, although you might just change the default layer that things save to.
That is not a big problem. in the case of a translator for settings, we can use form_alter and so. As long as we have the concept of cascading variables we have the foudation of the problem solved. Well, part of it. Still problematic are: profile fields CCK/flexinode types CCK/flexinode fields menu titles block titles roles input formats views and much, much more. All need a way to become translated.... I think a module or a few modules that do this part by part is the only way to solve it. A huge task.... My, personal shot at this, is to use less on-site configuration and more real PHP. A block defined in a hook_block can have a t() around its title. A block added trough the online interface has no translation options. Same for menus, node types, etc etc etc. Another reason not to lean too much on online configuration, but rather build your site with normal PHP files. Bèr -- [ End user Drupal services and hosting | Sympal.nl ]
Op 25-feb-2006, om 16:10 heeft Bèr Kessels het volgende geschreven:
Op zaterdag 25 februari 2006 15:47, schreef Adrian Rossouw:
Remember that just because you can override any setting doesn't mean you will be able to from the interface. You still need to actually have a form element to capture the setting for that specific layer, although you might just change the default layer that things save to.
My, personal shot at this, is to use less on-site configuration and more real PHP. A block defined in a hook_block can have a t() around its title. A block added trough the online interface has no translation options. Same for menus, node types, etc etc etc. Another reason not to lean too much on online configuration, but rather build your site with normal PHP files. And how about usability??? Only building your site with PHP-files doesn't improve that in any case, only making it even worse..
Stefan
Op zaterdag 25 februari 2006 16:26, schreef Stefan Nagtegaal:
And how about usability??? Only building your site with PHP-files doesn't improve that in any case, only making it even worse..
My sites are *far* better usable then an out-of-the-box Drupal. For my clients! My client does not need flexinodes define-content-types interfaces. They want a "add new product link". Nothing more. I did not mention for nothing that this is "my personal shot". It is my usage of Drupal: "drupal for consultants, consultants for users" (replace consultants with whatever you like). However, this is leading us away from the original issue: getting all the user-submitted config data translated. -- [ Bèr Kessels | Drupal services www.webschuur.com ]
However, this is leading us away from the original issue: getting all the user-submitted config data translated.
The current i18n provides needed functionality. Some have said it is monolithic. It also lacks some features, such as the ability to translate menus. It handles nodes and taxonomies in a fairly good way (end user functionality, forget internals for now). Let us go back to the hook idea. If there are hooks in Drupal to handle things such as nodes, taxonomy, menu, variables, users, ...etc. then the ecosystem will develop plugins for it. We can make them modular. Let us hope this is on the table Drupal 4.8/5.0.
FYI: I've adding some links to http://del.icio.us/tag/drupal+i18n I rather like Jose's approach to i18n support, and that is having it in core. I'm a little skeptical that having i18n as modular functionality. It should really be a part of core, and not something that can be turned on and off. Jose broke down the challenges pretty well: 1. i18n - being able to switch between content 2. l10n - being able to localize content (dates, times, currency, etc) 3. Multi-lingual content The first two that tough to fix, it's #3 that would require some revolutionary changes to the system. The i18n module, despite the excellent work, is really just a hack. Essentially with the i18n module you're building 2 sites, they're just mashed together through some PHP wizardry. This implementation is not good. If you're buildilng a multi-lingual website on 4.7, you're better off creating separate Drupal installations for each language. Why? It'll accomplish exactly what the i18n module does, but with more simplicity. Unfortunately it is essentially two sites, which means two of everything, and double the maintenance. Any data sharing will simply be hacks/middleware to synchronize things. This is an unavoidable fact of using 4.7 to build an i18n, multi-lingual site. This is where I think multi-lingual support should be part of core (as it is in other CMS systems). I'll use i18n to refer to all 3 issues above. (brain dump...there are probably more points) 1. i18n functionality should be a native part of core. 2. An i18n API for handling multi-lingual content (more on this below) 3. An l10n API for themes/modules/contribs to easy localize data (time, currency, etc) Some more details on point 2: The i18n API would be used by pretty everything that needs to save content in different languages. This is built on the idea that the meaning of something is constant but the language may be different. The challenge is creating a general use API that allows nodes to be created with their elements (title, body, teaser, etc, etc) to be in different languages. Why all that work? Usability. So we can have this: (URL method) http://drupal.org/en/node/32 http://drupal.org/fr/node/32 or (same thing, virtual host method) http://en.drupal.org/node/32 http://fr.drupal.org/node/32 And this for translating: http://drupal.org/en/node/32/tr/fr (translate from english to french) http://drupal.org/fr/node/32/tr/de (translate from french to german) Accomplishing this: Before we start firing out code, I think we need to ask the right questions first. How will we store all this new data? Do we have a single set of tables, or a set of tables for each language? What is the ideal implementation for Drupal's node system? What about versioning? How do we make it easy for contributed modules to support i18n? etc. One approach, that I've been mulling over (with some ideas from eZpublish), is to have an abstracted content creation layer that sits on top of the database layer. I don't know what's been going on with the CCK, but perhaps that may be a good foundation for this stuff. (wrrrr...geek mode) #1. When configuring your site you _HAVE_ to choose a default language. #2. Additional languages can be added. Handling Nodes: To define a new node, we have a simple definition (in code, in a text file, whatever). I prefer this so I can source control them. The forms api is a good example of using arrays of arrays to define something complex. We can apply this to nodes: 1. A node already has default fields (title, body, teaser), and a contrib can add custom ones. 2. The attributes and handling of fields is be defined as an associative array. 3. The system will handle all the database stuff auto-magically, making these obsolete node_insert(), node_update(), node_load(), etc. 4. Added benefit (psst..Adrian), this will also allow us to create the MVC system, RPC access to anything/everything...droolz. It should be fairly easy to tie together the FAPI with the node def, to create a web form. When nodes are created, they are in the default site language. So, some work flow off the top of my head: 1. We have a site that is French/English. 2. node/story/add 3. Creates a new node (nid:34), (ver:1), (lang:en) 4. Translate to french: node/34/tr/fr 5. Does this, automagically... creates: (nid:34),(ver:2),(lang:en) creates: (nid:34),(ver:2),(lang:fr) Notice that version 2 has an English and French version, where as version 1 only has an English version. This would undoubtly create lots of data as copies, but we're smart, we can find a better solution. Anyways, I've been typing this for like 2hours, and gotta pick up the wife. I'll write more ideas about handling menus, system variables, if I find some more time this weekend. I would like to be able to create i18n menu paths as well... eg: http://en.drupal.org/view/32 http://fr.drupal.org/vue/32 http://de.drupal.org/ansicht/32 to be all be contextually the same (I used google translate for the above, so if it's wrong... :) Ben.
I rather like Jose's approach to i18n support, and that is having it in core. I'm a little skeptical that having i18n as modular functionality. It should really be a part of core, and not something that can be turned on and off.
You are, unfortunately, making the same 'mistake' that Joses approach has had since the beginning: There is *no* holy grail. All our i18n sites differ so much in what they need that they can never use the same codebase. *this* cannot live as turnkey in core. It can only ever live in core as APIS that offer miodule developers to build translation and so interfaces. Beleive me: I have been hacking Drupal since I released my first english and dutch Drupal site back in 2002 . My post is not "just a wild idea" to hack current systems up into smaller chunks and that be it. Its four years of Drupal-i18n experience that I compiled into a final proposal :). And I am not sayig this to lever myself as /te/ i18n guru, or to get aah and oohs. I am saying his, to illustrate my reasons for disliking the monolyth apprroach. Bèr -- | Bèr Kessels | webschuur.com | website development | | Jabber & Google Talk: ber@jabber.webschuur.com | http://bler.webschuur.com | http://www.webschuur.com |
Bèr Kessels wrote:
I rather like Jose's approach to i18n support, and that is having it in core. I'm a little skeptical that having i18n as modular functionality. It should really be a part of core, and not something that can be turned on and off.
You are, unfortunately, making the same 'mistake' that Joses approach has had since the beginning:
There is *no* holy grail. All our i18n sites differ so much in what they need that they can never use the same codebase.
Maybe. So long as making i18n work doesn't require hacking core, modules are fine by me. That Drupal provides no 'clean' way to allow me to implement i18n is the real problem, and the only one which *must* be fixed. Somehow. I really doubt many people care how it's done. jh
Bèr Kessels wrote:
I rather like Jose's approach to i18n support, and that is having it in core. I'm a little skeptical that having i18n as modular functionality. It should really be a part of core, and not something that can be turned on and off.
You are, unfortunately, making the same 'mistake' that Joses approach has had since the beginning:
There is *no* holy grail. All our i18n sites differ so much in what they need that they can never use the same codebase.
I think you got my intentions wrong because I agree with this 'no holy grail' idea from the beginning. And that's why the i18n.module is nothing more than a buch of options you can use -or not- to have whatever idea of multilingual site you want.
*this* cannot live as turnkey in core. It can only ever live in core as APIS that offer miodule developers to build translation and so interfaces.
All I'd like to have in core is some basic support for handling 'multilingual objects'. But a simple default for a multilingual site wouln't be bad either.
Beleive me: I have been hacking Drupal since I released my first english and dutch Drupal site back in 2002 .
My post is not "just a wild idea" to hack current systems up into smaller chunks and that be it. Its four years of Drupal-i18n experience that I compiled into a final proposal :). And I am not sayig this to lever myself as /te/ i18n guru, or to get aah and oohs. I am saying his, to illustrate my reasons for disliking the monolyth apprroach.
Looking forward to take a look at your proposal -cannot access your site right now-... Cheers,
Bèr
Op zondag 26 februari 2006 18:18, schreef Jose A. Reyero:
I think you got my intentions wrong because I agree with this 'no holy grail' idea from the beginning. And that's why the i18n.module is nothing more than a buch of options you can use -or not- to have whatever idea of multilingual site you want.
All I'd like to have in core is some basic support for handling 'multilingual objects'. But a simple default for a multilingual site wouln't be bad either.
Yes, I know you prefer this layered system too , because we discussed this a lot :). My proposal contains a lot of your idea, youmight see. And about Core? My plan requires some changes in core. And I expect, if they are done right, that core will have even less code for multilinguality, but more abilities to develop and deploy a multilingual site. Bèr ps: site is back, the main contoller servers at lycos crashed (again). Did I already tell you people to never ever use lycos? No? Never ever use lycos :-) -- PGP ber@webschuur.com http://www.webschuur.com/sites/webschuur.com/files/ber_webschuur.asc PGP berkessels@gmx.net http://www.webschuur.com/sites/webschuur.com/files/ber_gmx.asc Gebruik geen CVS, tenzij je zeker van je zaak bent: http://help.sympal.nl/gebruik_geen_cvs_tenzij_je_zeker_van_je_zaak_bent
Bèr Kessels wrote:
And about Core? My plan requires some changes in core.
Thinking out loud for a moment - Could this be achieved with a module which manages the new node_revisions table and assigns languages to its entries? jh
One way of looking at text fields is that they are either in a specific language in which case they should be marked with that language or they are invarient across languages, perhaps have some other marking. For those fields which are in a specific language, they should actually be an array so that you can select the one that matches the user's current default language, or one marked default if there is no translated version for the language (probably english). Similar considerations apply to numbers and dates where one probably wants to format them for the current default language. The Unicode Consortium has discussed a lot about embedded language tags within text strings to handle the case of say a French quote inside otherwise English text. Here, if one were to send the string to a translator to Russian, you would expect the English to be translated but the French left alone. I don't know the current status of the implementation of these tags as I have been off their email list for a few years. Doing a search on www.unicode.org for language tags claims that they are part of the standard.
-----Original Message----- From: development-bounces@drupal.org [mailto:development-bounces@drupal.org] On Behalf Of Jose A. Reyero Sent: Sunday, February 26, 2006 12:18 PM To: development@drupal.org Subject: Re: [development] Drupal and i18n, the holy grail?
Bèr Kessels wrote:
I rather like Jose's approach to i18n support, and that is having it in core. I'm a little skeptical that having i18n as modular functionality. It should really be a part of core, and not something that can be turned on and off.
You are, unfortunately, making the same 'mistake' that Joses approach has had since the beginning:
There is *no* holy grail. All our i18n sites differ so much in what they need that they can never use the same codebase.
I think you got my intentions wrong because I agree with this 'no holy grail' idea from the beginning. And that's why the i18n.module is nothing more than a buch of options you can use -or not- to have whatever idea of multilingual site you want.
*this* cannot live as turnkey in core. It can only ever live in core as APIS that offer miodule developers to build translation and so interfaces.
All I'd like to have in core is some basic support for handling 'multilingual objects'. But a simple default for a multilingual site wouln't be bad either.
Beleive me: I have been hacking Drupal since I released my first english and dutch Drupal site back in 2002 .
My post is not "just a wild idea" to hack current systems up into smaller chunks and that be it. Its four years of Drupal-i18n experience that I compiled into a final proposal :). And I am not sayig this to lever myself as /te/ i18n guru, or to get aah and oohs. I am saying his, to illustrate my reasons for disliking the monolyth apprroach.
Looking forward to take a look at your proposal -cannot access your site right now-...
Cheers,
Bèr
You are, unfortunately, making the same 'mistake' that Joses approach has had since the beginning:
There is *no* holy grail. All our i18n sites differ so much in what they need that they can never use the same codebase.
I didn't mean to imply that it was the "holy grail". Um... wait, didn't you start this discussion about finding the holy grail for i18n support for drupal? :D (heh)
*this* cannot live as turnkey in core. It can only ever live in core as APIS that offer miodule developers to build translation and so interfaces.
Why not? Aren't those the same? How do you accomplish one without the other?
My post is not "just a wild idea" to hack current systems up into smaller chunks and that be it. Its four years of Drupal-i18n experience that I compiled into a final proposal :). ... to illustrate my reasons for disliking the monolyth apprroach.
I don't doubt your intelligence or your experience. Only mine. :) How would your proposal address these challenges: 1. Storing the multi-lingual content in the DB (true support, not just making new nodes) 2. Making it easy for contribs to support multi-lingual nodes (again not just new nids). What if these contribs create new node types? I don't think we can expect all contributors to create their own multi-lingual implementations. (shudder). Ben.
Op maandag 27 februari 2006 01:07, schreef Benson Wong:
*this* cannot live as turnkey in core. It can only ever live in core as APIS that offer miodule developers to build translation and so interfaces.
Why not? Aren't those the same? How do you accomplish one without the other?
Because the interface and workflow and all tat depends on your *case* or implementation.
How would your proposal address these challenges:
1. Storing the multi-lingual content in the DB (true support, not just making new nodes)
This would be a *contrib* module named something like i18n_node_mirroring.module (store teh contents of a node in separate locations) It can live (but prolly not used simultanuously) next to a i18n_node_duplication.module (a new node for each lang)
2. Making it easy for contribs to support multi-lingual nodes (again not just new nids). What if these contribs create new node types? I don't think we can expect all contributors to create their own multi-lingual implementations. (shudder).
Nodes (in contrary to terms and comments) have very, very good APIs. Wuith the proper hooks you can catch EVERY node. For those that sill think that Drupal should offer the whole shazam (aka turnkey internatiolisation) in core. Some out-of-the-field examples why this can never work: * How to address comments to multilingual nodes? having a thread that contains both FR and EN can be required, but might be unwished. * How to address non-translated nodes? Depends higly on the nature of the content and the 'community'/editors. * How to adress 'I have 5.000 nodes, now I add a third language'. * How to tag or classify content? Translated terms? Translation-specific terms? Shared Terms? Depending highly on the nature of your site and usage of classification (galleries/forums) * How to build books? Can a french node be child of an English node. Some might need that (I did). * How to build menus? Does every menu item have a mirror in the other languages? Or do you have per-language menus? Do you have nodes under menu items? Under all menu-items? * Should a teaser list contain all languages? On a blog where i sometimes write EN and sometimes NL I will want that. * How to enable translation of only the body, teaser and title of an image (or any file). If you are still think that a single turnkey is possible in core, please llet me know, I can write five more of such lists ;) However, all thise have two common denominators: * They use the same switching APIs, HTML wrappers and some storage aPIs * They use the same interface trnalators t(), and ll need configurations to be translated and switched. -- | Bèr Kessels | webschuur.com | website development | | Jabber & Google Talk: ber@jabber.webschuur.com | http://bler.webschuur.com | http://www.webschuur.com | Gebruik geen CVS, tenzij je zeker van je zaak bent: http://help.sympal.nl/gebruik_geen_cvs_tenzij_je_zeker_van_je_zaak_bent
Benson Wong wrote:
FYI: I've adding some links to http://del.icio.us/tag/drupal+i18n
I rather like Jose's approach to i18n support, and that is having it in core. I'm a little skeptical that having i18n as modular functionality. It should really be a part of core, and not something that can be turned on and off.
Jose broke down the challenges pretty well:
1. i18n - being able to switch between content 2. l10n - being able to localize content (dates, times, currency, etc) 3. Multi-lingual content
I have explained this better here http://www.developmentseed.org/blog/internationalization/coremodules
The first two that tough to fix, it's #3 that would require some revolutionary changes to the system.
The main changes accross the system would be. a) Having a language field for all the translatable objects that can be just ignored or: b) Joining simple language conditions when you want 'multilingual features enabled', that would be 'enabling i18n module'
The i18n module, despite the excellent work, is really just a hack. Essentially with the i18n module you're building 2 sites, they're just mashed together through some PHP wizardry. This implementation is not good. If you're buildilng a multi-lingual website on 4.7, you're better off creating separate Drupal installations for each language.
I have to agree that current i18n module is plenty of hacks -that resulted from the need to avoid extensive patching to Drupal core-. But I insist the data model is quite clean, and the hacks are only in the module's code, thus allowing for a future core module to reuse existing data and be implemented in a clean way
Why? It'll accomplish exactly what the i18n module does, but with more simplicity. Unfortunately it is essentially two sites, which means two of everything, and double the maintenance. Any data sharing will simply be hacks/middleware to synchronize things. This is an unavoidable fact of using 4.7 to build an i18n, multi-lingual site.
But about 'building different sites' I have a different view, actually it is more like 'namespaces'. I mean you have a lot of objects -nodes, comments, etc...- that are all of them stored in a single table, and then you can enable/disable i18n module to have the ones for the current language selected or to have all of them mixed together -i18n disabled, no languages- The pre-4.6 versions of i18n module were using this multi-site approach which proved to be unpractical and a pain when it came to synchronization and relations between objects in different languages -translations-. That why it was dropped..
This is where I think multi-lingual support should be part of core (as it is in other CMS systems). I'll use i18n to refer to all 3 issues above.
Agree, whatever the implementation is some support is needed in the core.
(brain dump...there are probably more points)
1. i18n functionality should be a native part of core. 2. An i18n API for handling multi-lingual content (more on this below) 3. An l10n API for themes/modules/contribs to easy localize data (time, currency, etc)
Some more details on point 2:
The i18n API would be used by pretty everything that needs to save content in different languages. This is built on the idea that the meaning of something is constant but the language may be different. The challenge is creating a general use API that allows nodes to be created with their elements (title, body, teaser, etc, etc) to be in different languages.
Why all that work? Usability.
So we can have this:
(URL method) http://drupal.org/en/node/32 http://drupal.org/fr/node/32
or (same thing, virtual host method) http://en.drupal.org/node/32 http://fr.drupal.org/node/32
And this for translating:
http://drupal.org/en/node/32/tr/fr (translate from english to french) http://drupal.org/fr/node/32/tr/de (translate from french to german)
I think the current i18n.module -with that lots of hacks- handles this url problems better than this. a) Objects have language, so xx/node/32 will be in whatever language the node is b) Interface has language, so the language prefix will determine the interface language and the language to select the node listings. All the urls would be just as current ones but with language prefix: xx/node, or xx/node/32 We dont need that complex ones above for translations, as the translation relations can be worked out before printing the links for navigating the content.
Accomplishing this: Before we start firing out code, I think we need to ask the right questions first.
How will we store all this new data? Do we have a single set of tables, or a set of tables for each language? What is the ideal implementation for Drupal's node system? What about versioning? How do we make it easy for contributed modules to support i18n? etc.
If we provide some generic mechanism in core for handling I.e. multilingual nodes, the contributed modules don't need to worry at all about it. Same for whatever other object -menus, blocks, etc..- provided that we provide in core some 'object abstraction' -I.e. taxonomy_get_vocabulary()- or 'query rewriting' - current db_rewrite_sql- mechanism for selecting collections of objects, and the contrib modules are using them
The main changes accross the system would be. a) Having a language field for all the translatable objects that can be just ignored or: b) Joining simple language conditions when you want 'multilingual features enabled', that would be 'enabling i18n module'
Yep, so the support is there whether you use it or not. I had a bunch of counter-arguments against your points, but I erased them all because I can summarize with this. 1. The i18n module doesn't add multi-lingual node support. It adds a language flags to a node. This is an important distiction because you're still building two sites, they're just mashed together into one through complexity. 2. Using a language in the URL, "namespace", is a great approach, but it's just one intuitive way to designate the language. Totally separate issue from #1. 3. If nodes are not truely multi-lingual, it is better to build a site for each language. This will accomplish the same thing but in a simplier fashion. This starts falling apart if you're building anything bigger than a brocure site. See: http://www.ndp.ca, drupal, brochure site, multi-lingual, yet very intuitive. Navigate to a node, and click the 'francais' link at top... that's how it should work. 4. FYI: I'm not hating on the i18n module, in fact, much props for your work. Considering 4.7's i18n limitations, I just can't see any benefits of using it over building a site for each language.
If we provide some generic mechanism in core for handling I.e. multilingual nodes, the contributed modules don't need to worry at all about it. Same for whatever other object -menus, blocks, etc..
Agreed, +1 from me. Ben.
If we provide some generic mechanism in core for handling I.e. multilingual nodes, the contributed modules don't need to worry at all about it. Same for whatever other object -menus, blocks, etc..
Agreed, +1 from me.
This is exactly what I said earlier, twice. } Let us go back to the hook idea. If there are hooks in Drupal to handle } things such as nodes, taxonomy, menu, variables, users, ...etc. then } the ecosystem will develop plugins for it. We can make them modular. So, we have +3 on this: hooks in core for anyone to use, and contrib modules to handle it in varying ways, as needed. Any more +'s or -'s?
On 26-Feb-06, at 3:47 PM, Benson Wong wrote:
1. The i18n module doesn't add multi-lingual node support. It adds a language flags to a node. This is an important distiction because you're still building two sites, they're just mashed together into one through complexity.
2. Using a language in the URL, "namespace", is a great approach, but it's just one intuitive way to designate the language. Totally separate issue from #1.
3. If nodes are not truely multi-lingual, it is better to build a site for each language. This will accomplish the same thing but in a simplier fashion.
All good points. Why not have separate sites? Remember, multi-site is in core. Workflow, actions, and publish/subscribe to push content between sites might be an appropriate way to build a multi-lingual solution. Much like organic groups vs. a separate site, you could probably build a good case for a site-per-language vs. single-site multi-lingual. Is (true) multi-lingual best accomplished via an install profile? I agree that no hacks/patches should be the main goal for clean multi- lingual solutions. Actually, a dedicated multi-lingual support team is probably a good idea -- Jose, Ber, Ben, Mike Gifford, Khalid, Development Seed off the top of my head, with Jose with my nomination for lead (he's been living the pain since something like 4.5) -- What do you guys need in terms of support from Drupal.org in order to move forward? P.S. Ben, thanks for taking the time to contribute your thoughts. I probably owe you several beers when I get back to Vancouver. Maybe at the first VanDUG, co-hosted by VanPHP? :P -- Boris Mann Vancouver 778-896-2747 San Francisco 415-367-3595 SKYPE borismann http://www.bryght.com
Is (true) multi-lingual best accomplished via an install profile? I agree that no hacks/patches should be the main goal for clean multi- lingual solutions. Actually, a dedicated multi-lingual support team is probably a good idea -- Jose, Ber, Ben, Mike Gifford, Khalid, Development Seed off the top of my head, with Jose with my nomination for lead (he's been living the pain since something like 4.5) -- What do you guys need in terms of support from Drupal.org in order to move forward?
Good idea Boris. I hope such a team leads to a modular, standard and in-core multilingual support.
Op maandag 27 februari 2006 00:47, schreef Benson Wong:
This starts falling apart if you're building anything bigger than a brocure site. See: http://www.ndp.ca, drupal, brochure site, multi-lingual, yet very intuitive. Navigate to a node, and click the 'francais' link at top... that's how it should work.
No. You are describing only one of the five cases/scenarios. reread them at the top of this thread if you do not beleive me. Having "flagged" nodes is a solution. A proper solution for a lot of use cases. Just as mirrored content is a solution. Bèr -- [ End user Drupal services and hosting | Sympal.nl ] Gebruik geen CVS, tenzij je zeker van je zaak bent: http://help.sympal.nl/gebruik_geen_cvs_tenzij_je_zeker_van_je_zaak_bent
Stefan Nagtegaal wrote:
Op 25-feb-2006, om 16:10 heeft Bèr Kessels het volgende geschreven:
Op zaterdag 25 februari 2006 15:47, schreef Adrian Rossouw:
Remember that just because you can override any setting doesn't mean you will be able to from the interface. You still need to actually have a form element to capture the setting for that specific layer, although you might just change the default layer that things save to.
My, personal shot at this, is to use less on-site configuration and more real PHP. A block defined in a hook_block can have a t() around its title. A block added trough the online interface has no translation options. Same for menus, node types, etc etc etc. Another reason not to lean too much on online configuration, but rather build your site with normal PHP files. And how about usability??? Only building your site with PHP-files doesn't improve that in any case, only making it even worse..
Stefan
If I understand Stefan, I have to agree. As an old I18n/L10n tools hand (my first engineering jobs were in this general area), I'm curious what a less technical admin trying to get up a site in Japanese or Arabic finds difficult right now. Also, is there a list of general features that European or other non-English language coders notice as being general pains in the ass (such as bad phone/postal code UI, etc). One of the things I see frequently in I18n discussions is the tendancy to reinvent the wheel. Very few of the problems people have are new, even for web apps, and some very good people came up with great solutions 10 years and more ago. Mozilla, for example, has some great tools (invented by a guy named Tao Cheng, an old friend of mine). The best thing about using existing tools is that people who do localization professionally know them and can use them. So using more standard tools makes it easier for us to get professional quality translation work on a wider range of modules and in a wider range of languages. You can easily design a better tool/file format/l10n system than many of the ones currently used. But there are likely a number available that are almost as good, and are used widely. It would be good to know what those tools are, since getting translators familiar with your system is half the battle from what I've seen. I suspect some of you are old I18n hands as well, so you know what I'm talking about. Mostly, the underlying PHP platform is at least better set up for this than (sigh) JavaScript, which has always been a disaster, and our t() function has most of what it needs to do things right if developers code with it correctly. So I'm guessing making L10n easier or even possible is the bigger challenge right now. Am I right about this? thanks, Rob
As an old I18n/L10n tools hand (my first engineering jobs were in this general area), I'm curious what a less technical admin trying to get up a site in Japanese or Arabic finds difficult right now. Also, is there a list of general features that European or other non-English language coders notice as being general pains in the ass (such as bad phone/postal code UI, etc).
Don't know about Japanese, but Arabic has unique issues with the whole Right to Left thing. As far as Drupal and Arabic goes, here are some resources: http://baheyeldin.com/arabization/using-drupal-with-arabic-and-other-right-t... Note that other Semitic languages share the right-to-left issues, such as Syriac, Hebrew, and Amharic, as well as many other non-Semitic languages that use the Arabic script (Farsi, Urdu, Pashtu, Dari).
This is why Arabic is a great script for doing these kinds of tests: it's contextual (meaning that letters need to be drawn differently depending upon what glyphs they're near), bi-directional (byte direction != physical layout), and written right-to-left, so very often, page layout needs to change as well. If you've done Arabic right, you'll do almost anything else right as well. Now that most apps use Unicode and along with it UTF8, Japanese is less valuable a test, since the old encodings were variable multibyte encodings: meaning that not each glyph took the same number of bytes to record. Now with UTF8, even French and German are multibyte, so if you get French or German right, Japanese will probably be mostly right as well (except if we start seeing Japanese and Chinese written top-to-bottom, right-to-left, which isn't common yet): don't shorten strings by byte count but by character count, etc. Although you would get this by testing Arabic as well. So we'd solve a lot of problems if we'd just develop Drupal in Arabic and then localize it into English, count to think. :-) R Khalid B wrote:
As an old I18n/L10n tools hand (my first engineering jobs were in this general area), I'm curious what a less technical admin trying to get up a site in Japanese or Arabic finds difficult right now. Also, is there a list of general features that European or other non-English language coders notice as being general pains in the ass (such as bad phone/postal code UI, etc).
Don't know about Japanese, but Arabic has unique issues with the whole Right to Left thing.
As far as Drupal and Arabic goes, here are some resources: http://baheyeldin.com/arabization/using-drupal-with-arabic-and-other-right-t...
Note that other Semitic languages share the right-to-left issues, such as Syriac, Hebrew, and Amharic, as well as many other non-Semitic languages that use the Arabic script (Farsi, Urdu, Pashtu, Dari).
On 2/25/06, Rob Thorne <rob@torenware.com> wrote:
This is why Arabic is a great script for doing these kinds of tests:
The first problem with Arabic is that it used to have very different encodings, even from the same vendor. This is now mostly a non-issue with utf-8. Some sites still use windows-1256 though.
it's contextual (meaning that letters need to be drawn differently depending upon what glyphs they're near),
This is also a non-issue now. All operating systems handle the contextualization well. At least Linux KDE and Microsoft does, as well as MS IE and Firefox. Even Konqueror is decent here. Not sure about Safari, but I imagine it would be working too.
bi-directional (byte direction != physical layout), and written right-to-left, so very often, page layout needs to change as well. If you've done Arabic right, you'll do almost anything else right as well.
This is where it gets tricky. The analogy I use is that of when you write your CSS to standards, it mostly works in FireFox, and life is good. Then you start testing in MS IE, and find that your layout is broken. You then have to go iteratively and fix the bugs. Arabic is the same, and there are many surprises. For example, numbers in the middle of an Arabic string, or a line that has Arabic and English in it. The rule of thumb: whatever you estimate for doing this, multiply it by ten and go by trial and error. At least for the first project or two. Other issues: Arabic in URLs does not work well. If you want pathauto for example to have Arabic in the alias, then think twice: MS IE and Firefox will treat these differently (MS IE leaves the letters as Arabic, Firefox encodes them to %CE, ..etc.)
Although you would get this by testing Arabic as well. So we'd solve a lot of problems if we'd just develop Drupal in Arabic and then localize it into English, count to think.
The way I see Arabic being used in Drupal (as well as Hebrew, being the other Semitic language in use today), is that sites are mono-lingual, or "indifferent" lingual. By monolingual, I mean that the site is purely Arabic, e.g. http://csc-sy.net/ By indifferent, I mean a site with an English front end, but content can be either Arabic or English, e.g. http://manalaa.net or http://foolab.org. This is true for blogs mostly.
with proper MySQL unicode support in 4.7 drupal now works perfectly with Arabic, the only problem is writing an RTL theme is a pain since drupal.css assumes LTR, you have to actually override any css statement that gives different values for left and right (margins, padding, borders, float, etc.). believe it or not when it comes to RTL table based layouts are much better since tables flip direction. cheers, Alaa -- http://www.manalaa.net "context is over-rated. who are you anyway?"
Op zondag 26 februari 2006 04:49, schreef Khalid B:
Don't know about Japanese, but Arabic has unique issues with the whole Right to Left thing.
As far as Drupal and Arabic goes, here are some resources: http://baheyeldin.com/arabization/using-drupal-with-arabic-and-other-right- to-left-languages.html
Note that other Semitic languages share the right-to-left issues, such as Syriac, Hebrew, and Amharic, as well as many other non-Semitic languages that use the Arabic script (Farsi, Urdu, Pashtu, Dari).
Maybe you noted my footnote, saying that even "a few pages in english" on a Dutch or so, site, is not that easy as it sounds. Case: I have an Arabic site, about a local diving centre. But I want to explain in very short, how tourists can reach us, what our options for them are etc. That means that curerntly I would have to wrap those pages in some DIVS and classes only to make sure my english texts appear RTL and to make sure the lang= property is set for that text. (Disclaimer, I have no Arabic sites, and no sites on diving, its just an example) Please do not take this is a starter for a thread on how to achieve this particular case. It is just to illustrate, that whatever solution we come up with, it will have to be layered (aka modular). So that even simple solutions like this one described can benefit from it. Because we certainly do not want to install a complete content mirroring system that infects forums and all that too, only to have five english pages rendered correct. Bèr -- | Bèr Kessels | webschuur.com | website development | | Jabber & Google Talk: ber@jabber.webschuur.com | http://bler.webschuur.com | http://www.webschuur.com |
On 25 Feb 2006, at 5:10 PM, Bèr Kessels wrote:
Op zate Still problematic are: profile fields CCK/flexinode types CCK/flexinode fields menu titles block titles roles input formats views and much, much more.
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> Then we can extend the prefixing to use these language specific tables. With the introduction of timestamps or even revision id's on each of the tables we want to be translateable, we can very very easily see which items need to be updated. I still have a suspicion however, that to implement i18n properly, we are going to have to abstract the database api even more, and move towards having a query builder. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
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 |
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
On 26 Feb 2006, at 2:16 PM, Bèr Kessels wrote:
What that would do: We add a single table: content_locale (other names are welcome) | tcid | lang | table | column | value |
could you imagine the joins needed for something like that ? and how tall that table will become ? Or if you don't use joins how many extra queries per page that will need? With a query builder, and having an array of the columns and tables. (i'm not talking about the .install, all the .install does is create / maintain this array, drupal itself knows how to spawn tables based on this array) You could define individual column of a table to be translateable , and a query builder could automatically join in the correct language version of the table. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
Hello,
I met Eric Gunderson of Development Seed at DrupalCON and talked about that a bit.
Jose Reyero, the author of the i18n module has a plan on keeping up with 4.7.
I am aware of i18n moudle by Jose. I just feel (know) that it will not suit me. I know Gerhard had very good points in the current i18n he disliked. currently we would be forced to all write our huge monolths, instead of being able to pick those blocks we like and add our extra blocks to make it the way we like it. i18n is a huge monolith that serves only one need. And tries to expand all that trough settings and config. IMO we should strip all this down to proper building blocks. That is far more valuable than diving into the one monolith and add options in there for all our needs. Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]
And I've post this one on drupal.org http://drupal.org/node/51544 Khalid B wrote:
I think an approach worth considering is having hooks in core for multilingual content (e.g. a lang column in nodes, menus, blocks, ...etc.), and let contribs handle those hooks in multiple ways.
I met Eric Gunderson of Development Seed at DrupalCON and talked about that a bit.
Jose Reyero, the author of the i18n module has a plan on keeping up with 4.7.
Yes, see the post above
It is described here http://www.developmentseed.org/blog/internationalization/drupal4-7
There is also the tr module http://cvs.drupal.org/viewcvs/drupal/contributions/modules/tr/
It is worthwhile that Ber coordinates with Jose and/or Eric, et al for a unified solution.
Yes. As I see it this is the whole point of all this discussions, forums, reports, etc... I hope we can agree on some approach before start rolling out patches, I wouldn't like to spend a month coding then get into the discussions about the the functionality...
The interface: And a good default? We are collecting some great ideas here, and i expect actual work and actual code too. :) One particular issue, though is still unclear. We already discussed the three areas of translation: interface, configuration, content. The interface for the content translation is highly dictated by the workflow, so I doubt we can say something good about it. Two forms next to eacother for two languages? Tabs? fields under eachother? All possible solutions, but none can be *the* solution. However, for the configuration translation, we will need one single solution. Untill today, I tried three interface ideas, both have their pros and cons. 1) simply use the active language for generating the current object. if you add a menu-entry "About us", with the active language being "English" then you will create the english menu item. If the language is "German" you will add an entry that you call "Über uns" to the german copy of the menu[1] Pro: quite clear for end users. in your theme or a block You can even add a Visual thing like a big flag of the current language. Con: Connection between Menuitem-german and menu-item English is virtually impossible. Meaning that it is very hard (if not impossible) to track that "Über uns" is the translation of "About us". BTW: this is virtually the same as adding tabs! 2) dedicated interface. Somwhere else, under admin/translations/ for examlpe you can search for elements abnd tanslate them. Pro: Simple, effective. Con: Our objects are not consistent. This will therefor never work completely. There will always be objects (from contribs) that do not fit in this interface. 3) duplicated interface. I did this trough theme functions; we can now do it with form_alter: just add a second (and their and fourth and so on, one for each language) field for each element that wants to be translated. Con: severe hacking required. Hard to track what watns to be translated and what not. Very hard to expand beyond core. Pro: simple interface. The current i18n uses some combination of 2 and 1, I, and my clients found this very unuserfreindly. However, the code was written, then, to minimise core changes, which require these often a bit odd interfaces. Bèr [1] Note that copy does not yet have to be a copy. We are still discussing and brainstorming about that in another thread. -- [ End user Drupal services and hosting | Sympal.nl ] Gebruik geen CVS, tenzij je zeker van je zaak bent: http://help.sympal.nl/gebruik_geen_cvs_tenzij_je_zeker_van_je_zaak_bent
Bèr Kessels wrote:
The interface: And a good default?
We are collecting some great ideas here, and i expect actual work and actual code too. :)
One particular issue, though is still unclear. We already discussed the three areas of translation: interface, configuration, content.
The interface for the content translation is highly dictated by the workflow, so I doubt we can say something good about it. Two forms next to eacother for two languages? Tabs? fields under eachother? All possible solutions, but none can be *the* solution.
Ber, I was one of a couple people at Netscape (before AOL bought us) that created tools for "leveraging" (i.e., reusing translations between versions), and we tried a number of different ways of doing this. But we got an interesting response from the international group at IBM, and from localization professionals they worked with. They didn't care about our interfaces, or our tools. What they wanted was a simple way to get a text file out of our tool set that had the US English string, and a bit of contextual, explanatory information, like "this string is used in the File menu". Beyond that, they couldn't care less what our tools did. It wasn't that the tools weren't good. They were. But translation shops turn out to be very idiosyncratic about their work procedures, and are very suspicious of new tools. In the end, we figured out how to do inport and export (along with commenting information, which they cared a lot about), and that was almost the only features of our tool sets that they used. A really useful interface would be targeted not at the translators, but at the people that are "managing" the translators. The main thing the tool needs to do is make it easy to add "comments" to strings, so that when a translator sees a string like "I agree" (for example), they know that it's used on a button to indicate the user agrees to the terms of contract. The context will make it a lot easier for the translator to choose the right text in the target language. Those comments are very important information, and if our tools make it easy to reuse the comments even after we've changed strings in some modules, we'll have made it much easier to prepare translations into new languages quickly. But as far as the translators themselves: nice, simple text files are almost the best interface for translators you can find. Cheers, Rob Thorne Torenware Networks, and Netscape Communications, Way Back In the Day.
Op maandag 27 februari 2006 06:59, schreef Rob Thorne:
But as far as the translators themselves: nice, simple text files are almost the best interface for translators you can find.
You are adressing that one point in Drupal that is actually working very well. We handle this trough po files. But that leaves us with a wide open space for translating: * content (nodes, comments, terms) * configuration (profile fields, node-types, node-fields, menu entries, and many, many more [1] ) Bèr [1] Example: "Add /news entry/" and "Voeg /nieuwsbericht/ toe": t('add %name') but how to translate %name? -- [ End user Drupal services and hosting | Sympal.nl ] Gebruik geen CVS, tenzij je zeker van je zaak bent: http://help.sympal.nl/gebruik_geen_cvs_tenzij_je_zeker_van_je_zaak_bent
Bèr Kessels wrote:
The interface: And a good default?
We are collecting some great ideas here, and i expect actual work and actual code too. :)
One particular issue, though is still unclear. We already discussed the three areas of translation: interface, configuration, content.
The interface for the content translation is highly dictated by the workflow, so I doubt we can say something good about it. Two forms next to eacother for two languages? Tabs? fields under eachother? All possible solutions, but none can be *the* solution.
Agree. That's why we need some basic support in core but then swappable modules that can use that mechanism and provide whatever interface people likes.
However, for the configuration translation, we will need one single solution.
Sure. However, the configuration interface is only for site Administrators, and I think not for everyday use. So this one only has to be functional and be somehow consistent with the case when we have a single language.
Untill today, I tried three interface ideas, both have their pros and cons. 1) simply use the active language for generating the current object. if you add a menu-entry "About us", with the active language being "English" then you will create the english menu item. If the language is "German" you will add an entry that you call "Über uns" to the german copy of the menu[1] Pro: quite clear for end users. in your theme or a block You can even add a Visual thing like a big flag of the current language. Con: Connection between Menuitem-german and menu-item English is virtually impossible. Meaning that it is very hard (if not impossible) to track that "Über uns" is the translation of "About us". BTW: this is virtually the same as adding tabs!
2) dedicated interface. Somwhere else, under admin/translations/ for examlpe you can search for elements abnd tanslate them. Pro: Simple, effective. Con: Our objects are not consistent. This will therefor never work completely. There will always be objects (from contribs) that do not fit in this interface.
3) duplicated interface. I did this trough theme functions; we can now do it with form_alter: just add a second (and their and fourth and so on, one for each language) field for each element that wants to be translated. Con: severe hacking required. Hard to track what watns to be translated and what not. Very hard to expand beyond core. Pro: simple interface.
The current i18n uses some combination of 2 and 1, I, and my clients found this very unuserfreindly. However, the code was written, then, to minimise core changes, which require these often a bit odd interfaces.
Yes. It is unuserfriendly or even user unfriendly but it just a) works b) needed no core patches For a good inteface, in the long term I'd go for (3) because of a number of reasons: - I think it provides the best usability -a variable could be changed for every language in a single page and even if there are too many languages, translations can be hidden with that nice javascript... - I don't think patches would be that big, as we'd need only some Forms API 'magic' and the variable management functions to be aware of this multiplicity. However it doesn't mean this nice interface needs to be implemented in core, just the 'variable management part'. So we could provide the hidden functionality -multilingual variables, menus, etc..- with some simple -as for coding- way to manage it, that could be option (1) and then if you want a nice colorful interface some contrib modules can be available. Same for translations, translation workflow, etc...
Bèr
[1] Note that copy does not yet have to be a copy. We are still discussing and brainstorming about that in another thread.
Hi, this is my first post, and pardon me if this idea was already on the table. I have to admit I didn't deep dive into drupal code, but nevertheless I will propose one more approach. So far I think we have 2 scenarios: 1) translating hard-coded strings in drupal core + modules 2) translating menus + content (user created) How about tagging the in scenario 2) with language tags: On example: using single storage, we can store also information about languages, so for a single menu item it should look similar as this: <en>about us</en><de>ueber uns</de><hr>o nama</hr> Processing of the menu item: if user chooses German language, and there is not German tag in menu item <en>about us</en><hr>o nama</hr>, then this menu item won't be displayed. The same is for content: in one node should be present information for all languages <en>text, images, bla bla bla</en> <de>text, bilder, bla bla bla</de> <hr>text, slike bla bla bla</hr> When drupal builds up the page, after it loads the node, proper translation should be processed (if user is on EN part of the site, then should be always English content processed from the node. If there is no content (and menu is there), we can put some default info message. Of course this approach than needs changes in GUI so that we can edit each language content separately (combo box with language selection, some javascript, some text processing/tagging in background). Advantage is that we don't need to change table structure. Drupal core can take care about how many languages are installed and how to process adding a new language or deinstalling/reinstalling existing one. This is just in short. Regards, Boris Iljadica p.s. I also would like to build multilingual web site in drupal, and so far, for my case, I think it is best idea to create multisite (3 web sites) for 3 languages sharing photo gallery.
I forget to wrote one more thing: tagging doesn't have to be in xml form <en>process this text</en>, it can be php IF control structure. <?php if ($lang=="en") {?> process this text <?php } ?> Boris I.
Bèr Kessels wrote:
Or, how to get the i18n project rolling.
Not to drag up an older thread but I missed most of this discussion while it was taking place originally :) i18n came up in our last DUG-TO (Toronto user's group) meeting, seeing as Canada is officially bilingual and we do have some people who work on various government sites in the group. (Someone in this thread mentioned ndp.ca, for example). We hashed over many of the same ideas that have been mentioned here.. adding a language field to the node table, having prefixed tables per-language, using revisions table with language codes. When working on government sites in Canada, there another interesting issue with i18n: Translation of a piece of content relates to Workflow That is, content must not be published until it is available in all official languages. Something else to chew on. Personally, I am most interested by the idea of using revisions for node translation as you could tie a unique nid to language _and_ version at the same time. -Rowan
participants (14)
-
Adrian Rossouw -
Alaa Abd El Fattah -
Benson Wong -
Boris Iljadica -
Boris Mann -
Bèr Kessels -
Eric Gundersen -
John Handelaar -
Jose A. Reyero -
Khalid B -
Rob Thorne -
Rowan Kerr -
Stefan Nagtegaal -
Walt Daniels