Multilingual Support

Yeah this would be cool. You could choose the type of node queue when you create it. This could be something like a "synchronised multilingual queue" whereby when you add or remove a node, all translations of that node are automatically added / removed.

How would you propose dealing with ordering in the queue, since two different language versions of the same node can't occupy the same queue position. Do those modules provide any kind of reference inside of a node object of the nids of other language versions of that same node?

#159424: With i18 internationalization Workflow Actions adds ALL translations to queue also!! is relevant to this issue.

I think my comments in the discussion at #264138: Show language of node in queue view might answer your question? Perhaps we should take up the discussion on that issue instead.

Simply said, the order of nodes of different languages actually doesn't matter, because you can only pull out the nodes from a certain language at one time anyway. So just make them in a standard order e.g. alphabetical name of language.

Second question: Yes, it's part of the node object (at least in D6, I don't know D5). I believe the nid of the source node is held in the tid variable of any translated node. There are also functions in core to get the translations of any node, given the nid.

Wouldn't it be better to create a smartqueue for language translations? - if not every node is translated (e.g. a press release in French but not English), then different languages would want to order their node queues differently. Seems to me that a better way of adding multi-lingual support to nodequeue is to add a language smartqueue to smartqueue module.

Per-languge smartqueue is a valid feature request (it's a new project request really), but I don't see how it would solve the issue discussed here.

In answer to my question from #2, Drupal core provides a 'language' value in the node object.

Yes, you're right, a smartqueue solution wouldn't keep node translations synchronised. In response to your query here, yes, with i18n installed the node object provides a $node->language value.

You can check for the node languages and node translations like this …

$languages = i18n_node_language_list($node);

… (which, for instance, makes it easy to compare with the user's language and tell them if this node has a translation available in the language they're using) and …

$translations = translation_nodeapi($node, 'load');

Would then be very easy to grab the translations of the node added and also add them to the queue, if desired.

I still think that this would be better combined with a smartqueue (maybe as a 'synchronise languages' option), so that the different languages could be managed independently. As the developer for a large multi-lingual site with language-specific content editors, the priorities in different languages don't always co-incide and independence between the languages is desirable.

We're working on a very similar issue on the flag module: Multilingual support for flag. The issue isn't the actual coding so much, it's deciding what we want to happen with the translated nodes. For instance if you add a node to a nodequeu, do you add just that on node, or do you add the translation set? Would you provide this option globally, as a default for all nodequeus or would you provide the option each time you create a new queue?

The patch for the flag module is ready and is now awaiting the maintainer's review. Just a heads up that I'm now starting on this issue and that a patch should be ready in a couple of days.

I would build the logic as follows. Have never used smartqueues and I'm not sure if they are relevant, but here is the logic in any case:

You can create a type of queue where you specify the maximum number of nodes of each language that are allowed in the queue. A node will only bump out nodes of the same language. When you add or remove a node from the queue there's an optional tickbox "add/remove all translations of this node as well".

As far as ordering languages within the queue I'm not sure if that's relevant, but in any case Drupal does have inbuilt ordering of languages, so I would just use this. You can order them on the language configuration screens.

Here is my first go at a patch to bring better i18n support to the nodequeue module. After applying the patch be sure to run update.php.

This patch adds a new configuration option to each queue to enable internationalization. When this option is enabled, if you queue a node then automatically all translations of that node are also treated as part of the queue. The same goes for unqueueing: you can queue the English version of the node and unqueue the French translation of that same node for instance.

With the internationalization option disabled, nodequeue works just like it did before.

Do note that you need the translation_helpers module for this to work, just like the flag module does and many more modules will start to rely on it for i18n support.

Thanks, sounds good except what about this scenario:
You have 3 languages on your site - EN, FR, DE.
You create an English article to appear in a special box on your front page and translate it into German.
You add that node to the queue. The German article is automatically added.
Since the article is not translated into French, you add a different French article to the queue so that you can have something on the front page in French.
When the French article is added, the German and English translations of that article are also automatically added! Oh no!

This is why I think you need a tickbox or way to specify whether the other language nodes should be added whenever you add/remove.

John, in your specific case all you need to do is just disable the i18n support and select the individual nodes.

Can't install the module if content translation module is enabled and translation_helper module is not, after applying this patch. It display an error that says: "To have the nodequeue module work with translations, you need to install and enable the translation_helpers module.". However I can disable translation, enable nodequeue, then re-enabled translation. I think this would result on a completely broken setup.

So probably, what we have in hook_requirements is not enough here, since: a) Users may not want to use internationalization options for nodequeue and still use content translation module and with that patch they can't do this without installing translation_helpers module. And b) Users can do the trick above (disable translation, etc.) and get a broken setup, and there is nothing saying what they did wrong that resulted in this.

So probably we need a hook requirements on 'runtime' phase too. Also I wonder if we can change the severity to REQUIREMENT_WARNING instead of REQUIREMENT_ERROR, so user can still have translation and nodequeue enabled without translation_helpers, and some logic is added to don't display internationalization settings on such setup?

Field 'i18n' is missing on hook_schema, so I get this:

When adding a queue with Internationalization set to 'Add translations of content to the queue as a group': user warning: Column count doesn't match value count at row 1 query: INSERT INTO nodequeue_queue (title, subqueue_title, size, link, link_remove, owner, show_in_links, show_in_tab, show_in_ui, i18n, reverse, reference) VALUES ('Test internationalization', '', 0, '', '', 'nodequeue', 0, 1, 1, 1, '0') in /home/henrique/public_html/drupal6/sites/all/modules/nodequeue/nodequeue.module on line 1958.

When editing a node: user warning: Unknown column 'nq.i18n' in 'field list' query: SELECT nq.qid, nq.show_in_tab, nq.show_in_links, nq.show_in_ui, nq.i18n FROM nodequeue_queue nq INNER JOIN nodequeue_types nt ON nt.qid = nq.qid WHERE nt.type = 'story' in /home/henrique/public_html/drupal6/sites/all/modules/nodequeue/nodequeue.module on line 1684.

and can't actually test the patch.

I'll manually create the field and do some further testing.

We indeed need a bit of work on the hook_requirements, thanks for the tip. The i18n field gets installed when you run update.php, it's in nodequeue_update_6001(). I'll add it to the scheme as well.

Here's an update of the patch that adds the i18n field to the schema. I'm currently keeping the _ERROR in the same line as the Flag i18n patch because the i18n functionality really depends on the helpers module. This is something we can further discuss but it doesn't prevent further testing of the patch.

Subscribing so I can review this a bit later on.

Spotted some things while reviewing:

Translation helpers requirement should be warning rather than error (I might not want this feature and only queue individual nodes, so could happily run without it), and it should show on runtime as well as install.

nodequeue_save() query was missing a %d

Got a call to undefined function when deleting a node - not sure if that was the fault of this patch, but made it harder to review.

Otherwise this works great. Since those issues were pretty minor, re-rolled with fixes.

Just a note that I'm paying attention to this issue. Thanks for all the great work here. I'm hoping to test this soon and commit it for the next RC.

I'm doing some testing and this looks great so far. The users in this queue probably work on multilingual Drupal implementations more frequently than I do generally, so I'm interested in your thoughts here:

1) Perhaps the translated node title should show up when available on the queue manipulation page when the language negotiation setting specifies that we're browsing in another language. That way, users manipulating a queue could see content in their language.

2) Browsing to a View of nodes in a queue in spanish, for example, still shows the english version of the nodes. (This is because we're storing a single nid in nodequeue_nodes which is desirable.) A quick search turns up #64004: Integration of i18n and views.module = fix translatablity of views, which suggests that showing the translated version of these nodes is out of the scope of this patch. Correct?

3) Can anyone think of a use case where we'd want there to be a hook for when a node in a queue changes its translation nid, and all of the nid values in nodequeue_nodes are changed for that node?

4) Pretty minor, and I can make this change before I commit. The options and description for the "Internationalization" radios could be more explicit:

"Treat node translations as a single node"
"Manually manage translated nodes"

Treating node translations as a single node allows users to add, remove and manipulate a node in a queue regardless of which translation is being Viewed; Nodequeue will only act on the original node. When Manually managing a translated node, Nodequeue will ignore the relationship between node translations; each translation node must be added to the queue separately and will occupy a separate spot in the queue. Changing this setting will not update content that has been added to the queue already.

I there was a typo defining the internationalization settings radios -- the logic there checked $fqueue->qid instead of $queue->qid. I fixed that and updated the description + help text for the radios. This is committed.

Thanks, everyone!

I'm experiencing this problem - currently using current version of nodequeue - 6.x-2.0 and i18n - 6.x-1.0.

I have modified view settings to show the current user's language as well as nodes that have no translations.

Included in the queue was a node with a translation. However when the queue is viewed in the translated language, the translated node does not appear in the list.

Current setup is:
Drupal 6.10
Nodequeue 6.x-2.0
i18n 6.x-1.0
Apache 2
PHP 5
MySQL 5

Thanks.

Please open a new issue -- This is the issue for adding multilingual support to the module. Thanks!

The Source Translation trick
http://drupal.org/node/433930#comment-2759852
worked for me. But it shows only nodes which are already translated. Nodes without translation are not shown.
What I'm missing? It seems to me useless. I want simple thing: one multilingual limited (Queue size) nodequeue. So Internalization must be setup to "Treat translation nodes as a single node". And then display nodes in queue based on the current user language. It should not be dependent on whether the node is translated or not.

Example:

1. I've put some nodes in English in my nodequeue.
2. I setup the "Source Translation trick", and it returns nothing cause none of nodes have translation or better to say there is no "Source Translation" for nodes which is required ("Nodequeue: Queue" is required and got "realitionship" with "Content translation: Source translation").
3. Then I translate one node to Spanish.
4. When switching languages there is only one node (translated one) shown in my nodequeue.
5. Then I translate one more node to Spanish. And there are show two nodes for English, two for Spanish.

Same when I put untranslated node in Spanish to nodequeue. Until I translated it its not shown in nodequeue.
I want to show all nodes in queue and than filter them via views lang filter Content translation: Language (= Current user's language).
I have tried to use "Content translation: Translations" setup to show ALL translations.
It really returns all nodes from my nodequeue, but setting up lang filter did nothing, still shows all translated nodes regardless of filter settings.

Same issues problem here: http://drupal.org/node/433930#comment-4679216

My setup:
Drupal 7.0
Internationalization 7.x-1.0-beta5
Translation helpers 7.x-1.x-dev
Nodequeue 7.x-2.0-alpha1

@mattez Please open a new support request issue.