Support for displaying translation sets

Thanks, I'll put together a draft translation.views.inc and post for review.

Here's an initial roughed in patch. To test: after applying the patch, extract the tarball to views/modules.

Features:

1. Moves language field from node.views.inc to new translation.views.inc.

2. Adds remaining translation-related fields: tnid and translate.

3. For convenience, all fields handled are added to a new group, "Node translation".

4. For tnid, declares a relationship with the source ID. Here I was following what's done with the {comments}.pid field. I vaguely think this relationship might be useful but I don't fully understand yet just how ;)

5. Adds a view_node_translation link field. This will link by title to a translation of the node in the current language if available, and otherwise to the node.

In other words, I've started to sketch in some of the possibilities. Needs review and thinking through at this point.

There's a lot that could be done or tried but not all of it will be commonly needed. We might want to put a minimum in Views core - something not much more than what I've sketched in, though obviously revined - and leave more advanced or particular handling to e.g. a views_translation module.

@merlinofchaos: Looking at it again, I think the main thing that would be useful is another relationship on the node.tnid field. What I currently have is a join on node.nid to find the source translation. What we also need, I think, is a relationship to the translation in the current language. However, this would require a where condition in the join: join on node.tnid where node.language = '***CURRENT_LANGUAGE***'.

This looks complicated. I don't see support for where conditions in the views_handler_relationship class.

If this worked, though, then what I sketched in as the 'view_node_translation' field probably wouldn't be necessary, since we could get any of the translation's fields via the relationship.

So I guess we should either:

a. strip out both the relationship and the 'view_node_translation' and work them out later,

b. strip out just the 'view_node_translation' field, on the assumption that the source translation relationship is going to be useful, or

c. complete work on a 'translation in the current language' relationship before applying anything.

I think I lean towards a. It gets some basic improved support in and gives time to work through the rest. Thoughts? Shall I do up a patch sans those two?

Also, I forgot a line assigning the node.translate field to the "Node translation" group. I'll add that in.

@Anselm Heaton: thanks for the link, I'll have a look.

Nice! That example from CCK is very useful. I'm thinking now that we'll need only one relationship. It'll be a join on node.tnid (not on node.nid as I'd done earlier for finding the source translation).

Here, the options could be:

* all (no where condition, multiple rows)
* source translation (translated_node.nid = translated_node.tnid)
* current language (as above)
* for each enabled language, a version in that language

I'll get working on this, but I'm not likely to finish today.

Yes. I was just thinking that we could do both of these in a single relationship. Or in other words these two are equivalent and would both create a relationship with the source node.

LEFT JOIN node translated_node ON node.tnid = translated_node.tnid AND translated_node.nid = translated_node.tnid
(which could be done as part of the single translated node relationship)

LEFT JOIN node source_node ON node.tnid = source_node.nid
(which would require a separate source translation relationship)

But even if so, it might be clearer and cleaner to do the source translation as a separate field. What do you think?

k, thanks, I'll get coding.

Well, I got most of the way but I'm stuck on how to modify the join.

merlinofchaos, can you have a quick look and point me in the right direction?

Changes since the last patch:

* Removed the 'view_node_translation' field and handler
* Added a DEFAULT_LANGUAGE query substitute
* Added a join on node table (node.tnid = node_node.tnid) to permit a tnid to tnid relationship
* Added a translation relationship and handler.

This last point is where I'm stuck. In the handler, I'm not finding the right way to modify the join to add a condition. See ensure_my_table in class views_handler_relationship_translation in views_handler_relationship_translation.inc in the attached tarball.

I tried the following:

      // This has no effect on the join.
      //$this->table_alias = $this->query->ensure_table($this->table, $this->relationship, $join);

      // This produces a double join (two joins on the node table, producing duplicate rows).
      //$this->table_alias = $this->query->add_table($this->table, $this->relationship, $join);

      // This could work but I'm not sure how to cleanly implement it and it would seem cleaner to have this as part of the join rather than the where condition.
      // $this->query->add_where(0, "node_node.language = 'whatever'");
      // $this->table_alias = 'node';

Here's the relationship definition I'm working with, in case I got something wrong there:

  $data['node']['translation'] = array(
    'group' => t('Node translation'),
    'title' => t('Translations'),
    'help' => t('Versions of content in different languages.'),
    'relationship' => array(
      'title' => t('Translations'),
      'help' => t('Versions of content in different languages.'),
      'base' => 'node',
      'base field' => 'tnid',
      'relationship table' => 'node',
      'relationship field' => 'tnid',
      'handler' => 'views_handler_relationship_translation',
      'label' => t('Translations'),
    ),
  );

What's the right approach here?

Thanks, Nedjo.

Great, I'll have a look.

I realized what I'd missed previously is that we for can't simply join on the tnid field, because there are two cases we need to account for. The first is: the node is part of a translation set and has a tnid equal to the nid of the source translation. The second is: the node is not part of a translation set and so has a tnid of 0.

If we simply join on node.tnid, for untranslated nodes we get all other untranslated nodes joining (since they too have tnid values of 0).

To complicate things, we should support the "require this relationship" functionality. So the joins we're looking for would be something like:

1. If we do *not* require the relationship:

SELECT node.nid, node.title, node_node.nid AS node_node_nid, node_node_title AS node_node_title FROM {node} node LEFT JOIN {node}node_node ON node.tnid = node_node.tnid OR node.tnid = 0

2. If we do require the relationship:

SELECT node.nid, node.title, node_node.nid AS node_node_nid, node_node_title AS node_node_title FROM {node} node INNER JOIN {node}node_node ON node.tnid = node_node.tnid AND node.tnid != 0

Looking at the commit, I'll report back.

Looks like I put the wrong handler, the relationship on source translation should use the standard views_handler_relationship, patch attached but not tested. I'll test in a minute.

Joining on nid covers this relationship: show me translations of this source translation. That's definitely something we want.

I'm thinking it misses something we may also want, sibling translations. Those are: show me translations of this piece of content (which may itself be a translation, not the source translation).

That's where I'm thinking we might want to join on tnid.

you're going to get multiple rows, because there are an unspecified number of siblings

True. But we're going to get multiple rows in any case as there are multiple translations per source translation.

We already handle this by including the language field in the join. There are multiple nodes with a tnid of 23, but only one of them is in Spanish.

So by joining on tnid we get everything we get from nid (ability to show translations of a source node) plus sibling-to-sibling joins.

Attached patch includes some small needed fixes:

* Fixes my incorrect handler for the source translation.
* Adds in two bits missed from the original patch.

And:

* Uses tnid as the join field, enabling sibling-to-sibling translation relationships. The only extra this requires is ensuring tnid != 0 in the join.

I've run this through its paces and it seems to work.

But I found some additional areas I left unfinished. There's no views_handler_filtern_tnid, but it's declared in the field definition. I'll try to write that tomorrow.

I'm afraid I have no idea what I was thinking there, apologies for the problem.