Handle multilingual content

I spent most of yesterday wrestling with various possible versions of approaches 2 and 3. The short conclusion: approach 1 is looking mighty attractive!

Trying to change the way that data are stored or retrieved in Voting API itself raised a host of issues.

Voting API is nicely abstracted from any content_type (e.g., node, user). Dealing with nodes' translation ids directly would compromise this.

Various strategies I tried and their problems:

1. Implement hook_votingapi_results_alter() to add in the data for a whole translation set when a node is being handled.

While useful for adding new data, is not suited to altering existing data since it gives summary statistics (e.g., percent), not the data used to calculate those statistics.

Also, vote data are loaded as well through other methods, and my testing ended up with two sets of data, one aggregated and one not.

2. Redirect all handling of node data to use the tnid if available instead of the nid.

This proved very messy. It would need some sort of _substitute function that, fed a content type and content id, would enable modules to substitute one for another. Beyond that, there is no single set of data handling functions--data are loaded, saved, deleted in multiple places. So redirecting would require messy hacking in many places.

3. Redirect only node vote loading to reference the combined data of a translation set.

Specifically I looked at enabling modules to specify an array of content_id values to be used in place of a single one in _votingapi_get_standard_results().

But IIRC this wasn't the only place that voting results could be loaded from.

I hit various problems with potential collision between what is loaded and what is saved.

Beyond this, there were issues with determining voting rights. If all nodes in a translation set count, we have the potential for a given user to bias statistics by voting separately on each member of a translation set, and hence a need for preventing a user from voting on a node if s/he has voted already on a member of its translation set.

Then I returned to the original approach 1, "Leave any special handling to other modules using Voting API." I used fivestar as the test case. And in a few minutes coding things were looking peachy.

So what I'm thinking now is; put just enough in Voting API to provide some consistency in the handling of voting modules. Like a common settings form element that they can use. And, possibly, some translation-related Views exposure option. Then leave well enough alone.

Patches to Voting API and fivestar coming up....

Here is a small patch to add a configuration option that voting modules can add to the voting api settings form.

And the accompanying patch on Fivestar: #307207: Multilingual voting: option to tally votes by translation set.

A bit more explanation about the patch.

It creates a configuration option that doesn't appear by default on the Voting API settings form but can be added by any module wanting to include options for handling of multilingual content votes.

The two options are (a) 'default' (no change, votes are separate on each node in a translation set) and (b) 'source'--votes for any piece of translated content should be registered to and then loaded from the "source" translation.

In the fivestar patch, this translates into: Use tnid instead of nid when registering and fetching voting data.

One issue we should at least think through is the implications of changing this setting.

What's the expected outcome if there are existing translated content and a site admin changes the setting from 'default' to 'source'? Should data be updated so that any existing votes are summed and assigned to the source translation? Then there's the other direction. If an admin turns 'source' to 'default', there is no effective way to determine which of the votes were assigned to which version of the node. The best that could be done would be e.g. dividing the existing votes between members of the translation set.

Probably not a critical problem, but one to think through. Maybe some warning text is enough.

Thanks for your comments Scott.

Wouldn't we want votingapi to calculate (if multilingual site) results on each individual translation and then aggregate those together?

Yes, that's one of the approaches I tried. Probably it merits a fuller attempt before we opt for a quick fix. Setting this back to active. I'll post a version of one of the patches I tried so you can take a look. It was messy, but maybe with some review we could clean it up.

Here's a roughed in patch along the lines Scott discussed, hackish, untested, intended as a proof of concept. I'll return to this next week.

@Eaton

Thanks for your thought and explanation.

I'm not thinking that changes are needed in the general ways Voting API handles data. I just don't particularly relish the idea of having to introduce overrides wherever data is handled to ask "is it the nid or the tnid that you're talking about?"

We're hitting a general problem that probably calls for some community-wide consensus. The problem is: under what circumstances is the nid the best primary identifier? and under which is the tnid best? Or, put differently, under what cases do we want to track each translation separately (by nid) and then, as needed, aggregate data vs. under what cases do we want to actually track by translation set (the content per se, independent of language)?

The answer I suspect comes down to the question: is the particular translation being operated on a significant piece of information for the purposes of this datum?

Take page view statistics. In that case, I think there is a strong use case for the use of nid. When we want to know what pages were viewed, we might often interested in what language was seen. When we want to, we can always aggregate across the translation set to generate statistics. So, probably, these data are best tracked by nid.

With voting, I'm not so sure. When we're voting, is it important that we're voting on the French translation of a piece of content? My initial feeling is, probably not--unless we're asking "what's the best translation? ;) A vote is on the content per se, not some translation of it. So, it seems to me, we're not losing significant data if we store and load from the nid/tnid rather than the nid.

(In practical terms, we'll often want to expose voting data to views. Here, aggregation is not necessarily straightforward since Views doesn't by default support GROUP BY operations. See merlinofchaos's comments in this related issue on Views: #307032: Support for displaying translation sets.)

We're having pretty much the same conversation about flag module over here: #307810: Multilingual support for flagging. It looks like we need some community consensus before we can move forward. When is a piece of content a node and when is it a translation set member?

@Eaton

Would that help at all, or would it only shift the problem to another area?

My hunch is, it would help, and would help promote better solutions elsewhere. We're almost always better off choosing what's correct and relying on other solutions to correct themselves, rather than trying to compensate for what's incorrect elsewhere. Further comments here: http://drupal.org/node/307810#comment-1018545

Could you have a quick look at the patch I did for Fivestar in #307207: Multilingual voting: option to tally votes by translation set? It basically comes down to this line:

+  $id = $node->tnid && variable_get('votingapi_translation', 'default') == 'source' ? $node->tnid : $node->nid;

When registering or fetching voting data, if set to use the 'source' (evil stormtroopers of the empire, beware!), send the tnid if it's set, or otherwise the nid.

I'd be tempted to change it to:

+  $id = $node->tnid ? $node->tnid : $node->nid;

In other words, enforce voting by source id, and avoid problems of what do do when switching back and forth.

In this case, at least, it's a pretty simple change and may accomplish the aim without muddying Voting API. But it only makes sense if we accept the "use the tnid if present, otherwise the nid" conclusion.

Eaton:

For the views part, the new code in modules/translation.views.inc in views module may be useful for reference.

For the views part, it may benefit from the recent translation set relationship feature that went into Views, see translation.views.inc. Or from some improvement on it.

Say what we want is a list of highest ranked nodes in the current language. With a views relationship, we can display nodes or the Spanish versions of source nodes.

So we could:

1. Create a view, filtered to show nodes that are either (a) untranslated nodes in the current language or (b) source translations.
2. Add voting data.
3. Add a relationship, so that we see the current language version of source translations.
4. Display fields from the relationship node.

Hmm, this approach assumes a given node is receiving votes either as a translation or as a translation set--not as both. Which, I guess, would work if we designated the behaviour by node type.

But I'm not fully convinced that node types is the right way to go here. I suspect that whether a vote should be applied to a translation set or an individual translation is going to depend not so much on what kind of content we're voting on but rather on the quality we're voting on.

Maybe today fivestar is limited to a single parameter. But we can imagine voting on multiple parameters. Say you have a 'song' content type. People might vote on multiple parameters: fan response (by way of comments left), quality of lyrics, instrumentation, recording quality, danceability, or whatever. In that case, maybe fan response and lyrics would be by the individual translation--they're different because they're translated into different languages. Everything else is identical throughout the translation set (it's the same recording heard in each case) so apply to the translation set.

Do we have current voting modules that provide multiple parameters/criteria/axes?

Well....

With flagging, we're deciding, it's not the content we're flagging that determines if a flag is better per translation or per translation set--it's why we're flagging it.

Isn't it the same with voting? Isn't it the particular quality or qualities a vote is evaluating that can have per-translation implications--not the content itself?

If all the axes in my song example should be treated per-translation - even though many are clearly translation-independent - then it feels like we're back where we started, with only per translation voting and no voting by translation set. Any node type that can exist in multiple languages by definition has some properties that vary by translation, and so could potentially be evaluated per translation.

As with flagging (and, likely, nodequeue, and other similar functionality), it seems to make more sense to determine the tnid/nid distinction by voting axis rather than node type.