Attach fields to translation sets.

Shared data! We discussed to a lot of length, that a node based solution allows a superior feature set, compared to anything out of nodes. But there are quite a few situations, when shared data is a requirement. A common solution for sharing data among nodes should solve the problem for polls, events and simpler use cases, where only a few properties of a node are translated. Unfortunately I have see no solution for node instance data sharing yet in Drupal core/contrib, so it seems we have no prior art to look at.

I've changed the title because I think the original one was bit misleading. I'll open a new thread about blocks only.

For these cases when we need language specific and shared data for nodes, as we are in principle, going for 'different nodes for each language' as a general solution, we may have some other options:
- Some support for cck-like translatable fields for nodes that may be a good solution depending on how much of cck gets into the next version of Drupal. I have this idea implemented in the ttext.module (ttext = translatable text field), i18n package, for 4.7.
- We build on this http://drupal.org/node/133745 (User defined string translations) and then provide somehow some support for text fields that will be translatable using that mechanism.
- Specific language options built into the poll node type, may be a bit more complex and may need then a case by case approach for other node types.

I'd go for any of the first two ones -and anyway we should start thinking sometime soon about cck field types that are translatable -which is not that difficult-... I'll be working for now on that user defined strings translation next and will keep in mind using it for node text fields later...

Jose, you got my paper by mail earlier :) I cannot give a better explanation on why node translations as nodes are better. In case we go any other way, like field level translations or user defined string translations, we would need to support workflows for these fields, permissions, different authors and revisions. There is a whole lot of features you get by using nodes for free, which we would need to implement from scratch again. This is impossible in the Drupal 6 timeframe, so going the custom translation method way would loose our users a lot of valuable features. As far as I see, we'd better focus not to support shared fields in core for the first iteration, and let core have a simple node translation scheme like i18n and localizer module both have. Shared fields are viable for contrib in the Drupal 6 timeframe as far as I see (and then only building on the separate node concept too).

I think node translations is the next target. Maybe we should try to get node languages as is to core now, and submit the translation patch in the next iteration.

Gabor,

Yes, ok with that. I'm not working on this. As the thread was open, I just wanted to point out some options for the future, in case someone else wants to work on that, but I'm focusing on the other issues...

So, i am not clear on how you are planning to relate all the different language nodes for a single piece fo content. any pointers?

Moshe, look at our SVN repo, links at the top of http://groups.drupal.org/i18n We will submit a node translation patch later, once we have cleaned up the translation module we are proposing (it still needs quite some cleanup).

Moving to Drupal 7 queue. We don't have a separate code repository now, so no reason to have this separated as if someone is working on it.

Here's a possible approach for how this might work.

Some contrib modules now operate on either nid or translation id - see nodequeue for example. In terms of adding stuff to the node object, I think it almost makes sense to treat translation sets as a separate object type over and above nodes. So we'd add to hook_nodeapi from within translation.module - and allow for modules to load data by tnid instead of nid.

So attached patch adds a new hook_nodeapi_translation_set_load() and the accompanying documentation in translation.api.php. At the moment, we still have the calling modules adding to the node object by reference, but it might work allowing them to return data in an array keyed by tnid and let translation module handle this itself (this would go against the current nodeapi_load hooks though).

However while writing it I realised we'd have to do this in _prepare, _index, _save etc. - so perhaps the better approach would to see if we can make node translation sets 'fieldable' - since if it's possible to handle it indirectly via translation module still, we get all the fields for free, and all the work is done there instead of asking modules to do double the work.

Here's that second approach, only a very partial sketchy patch, and it's a bit evil - so stopping here to see if it makes any sense at all.

translation.module defines a new 'fieldable' object with Field API, called 'translation set'. For the purposes of Field API this object is completely independent of nodes - so we attach fields to translation sets in the same way as we can to nodes, users etc.

However, all the field_attach_* functions are called from within hook_nodeapi with empty objects - or they may need just tnid as a property - either way we build an object just for the purposes of Field API - field_attach_load() populates those objects, and the values are then merged back into the nodes once that's done. I've only done hook_nodeapi_load() for now.

The advantages of this is are that all of the logic is handled entirely by translation module - so there's no additional complexity in node module, no performance hit at all on mono-lingual sites, no greater performance hit with translation module than adding a field to individual nodes or installing another nodeapi module, and Field API doesn't need to know anything about it either. The disadvantage is it's a bit evil.

Obviously we'd need to ensure that there are nodeapi equivalents for everything Field API needs, and that translation module follows those religiously. I don't yet have a handle on how we'd do 'bundles' like this - but ideally that'd still be by node type.

Defining the same field with the same field instance name on both nodes and translation sets is going to result in overwriting the values of one or the other, but it seems like that could be handled by validation.

Attaching fields to translation sets makes a ton of sense to me. Very nifty approach! You might want to augment node rendering so that these fields appear in the node belonging to a given set.

I agree that this is a strong approach. I'll ask Goba to take a look.

subscribe

With translatable fields being in core now, do we still want to do this?

Personally, after intensively discussing the translatable fields approach with some site owners of multilingual Drupal sites, I do not see any use-case for the "old" node translation set based approach anymore.

I think contrib could probably do this with hook_node_* hooks - maybe that's a replacement/enhancemnt for some of what i18nsync module does. However it's probably won't fix for core.

I'm sure existing i18n sites with translated nodes are going to continue using those in Drupal 7, even if we eventually try to merge those back into translated fields in Drupal 8.

ok, trying to clean the i18n sprint queue. Feel free to re-open if you do not agree.