Posted by catch on September 19, 2008 at 3:06pm
There's a number of ongoing issues for various contrib modules where i18n support is being introduced or refined for D6 at the moment. Would be good to consolidate some of these efforts so things work consistently where possible, and hopefully encourage some extra reviews of the various patches. Most of these links via nedjo.
I'll start with a quick list of some of the issues:
- Voting API: Handle multilingual content
- Nodereference:
Multilingual support for nodereference& Refactor nodereference to handle multilingual content? - Flag: Multilingual support for flagging
- Legal: Internationalization needed for Legal module
- Views: Support for displaying translation sets
- Wordfilter: Multilingual support for wordfilter
Module specific discussion should probably stay in the issues (and I'll add more into this post as I become aware of them), but more general stuff we could talk about here.
Comments
Multilingual node references: getting it right
Thanks for the summary.
A key issue that needs addressing is: how should we track node data in multilingual contexts? This is coming up again and again.
With a single language, the nid is a valid primary identifier. But when we have multiple languages, we have a new potential primary identifier for a piece of content: the tnid (the nid of the "source" translation, which becomes the tnid for all nodes in a translation set). A quick test for the primary identifier might be:
<?phpreturn isset($node->tnid) && $node->tnid ? $node->tnid : $node->nid;
?>
When users are casting a poll vote (poll module), creating nodereferences (nodereference module), voting on a piece of content (voting api module + e.g. fivestar), flagging a piece of content (flag module), or placing a piece of content in a panel (panels module) we now have to ask: should a vote, reference, flag, panel, etc. be for a particular translated node (the French version of node 123, which has the tnid of 122) or for a translation set (122, the nid of the original node from which 123 was translated)?
There's something of an emerging consensus that, in many or most cases, the latter is correct.
When we're voting on a piece of content, we're generally saying "I like/dislike this piece of content" rather than "I like/dislike the French translation of this piece of content". When we're looking at the votes for a piece of content, we're generally asking "How many people voted for this piece of content?" and not "How many people voted for the French version of this piece of content?".
At least, that's the approach taken in e.g. the multilingual polls module (i18npoll, part of i18n). When that module is enabled, a vote is for the source translation, and vote data for a translation shows the source translation data.
Similarly, a recent patch to Panels says, when displaying a panel, ask if this is a source translation, and if so show instead a version in the current language, if available.
In all these areas, some action is required. Multilingual content in core has essentially broken a lot of contrib--the contrib modules don't work as expected under multilingual contexts. Getting the solution right is important.
Should we be using the tnid when available to track votes, flags, nodereferences, panel nodes, etc.?
Should the algorithm for selecting translation be in core ?
The problem of selecting the correct translation of a given node is that there are several ways of doing it. If an article is not available in the current language, should you return it in the default language or in the source language ? Some regional sites (eg. south america) might want to favor the languages of the region (Spanish/Portuguese/etc.) over other languages. If you have an organisation with working languages, but allow other languages to be used on the site, should you give priority to current language, the default language, the source language or one of the working languages ? In what order ?
At the moment, each module contributor is using his/her own algorithm, making it impossible to have a consistent site. Query re-writting (as per i18n content selection) is only useful when you use queries - not the case for many modules such as Nodereference, E-publish, etc.
To make sure module contributors implement this in a consitent way, there has to be a centralised API. An idea could be:
support both sets and nodes
The thinking behind having standalone nodes for translations is that you can for example do polls and then cluster votes by language or aggregate votes overall. If you have the same questions, that is.
For example a vote for "Favorite gadget for christmas" could very well have different options for different languages on an international site. Eg. iPhone's are not sold around the world, so they might not make it to the list in some language versions of the poll.
Another example is imagefield. If you have translated nodes, you could very well have translated images/figures, right? So the same figure associated to the French version will not apply to the German version, and you need a different image attached.
Basically, we designed core so that it enables supporting both tying data to translation sets and individual language nodes, and we should let site admins to choose on a case-by-case basis. Either based on content type, or whatever other criteria made up.
Flag now does this
I hadn't come back to update this issue, but Flag now does this (see http://drupal.org/node/307810 for the patch) - for each flag, you can flag by translation set, or by individual node. There's also similar patches for nodequeue and Voting API - so it looks like we'll end up with a consistent approach with at least those modules.