Hi,

In the previous version of nodequeue 5.x-1.0, we had multiple queues to handle the i18n issue. So something like:

homepage_features (en)
homepage_features (es)
homepage_features (fr), etc

Different editorial teams would maintain these different queues. We have i18nviews set up, so when showing the homepage features, we selected nodequeue is one of:
homepage_features (en)
homepage_features (es)
homepage_features (fr), etc

Because the old field was multiple select. The new one is single select, and after the update, many parts of the site got screwed up.

Any recourse here? Or do I have to refactor everything? or hack the module?

Best,
Jacob

Comments

merlinofchaos’s picture

Well, you don't actually have to hack the module. Though the 'right' way is unfortunately probably the hard way.

For what you're doing, you really want a smartqueue implementation where all of the languages in the system are subqueues, and you determine queue eligibility by...the language the node is in? Or I guess whatever you're using to control who can add items to which queue now.

This means writing a module that is probably about the same size as the smartqueue_taxonomy.module (and you could use it as a guide), and then it means moving all the existing queues. That isn't actually too bad; you'd probably keep the subqueues that were created (a normal queue actually has one and only one subqueue) and just move them to the smartqueue. And then refactor the view.

That said it's probably all a lot more work than you want to do. Instead you may find it easiest to just add a new views filter that does what you want; it doesn't seem like this would be all that difficult, I don't think.

merlinofchaos’s picture

Status: Active » Fixed
Anonymous’s picture

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.

fletchgqc’s picture

There is some discussion of ideas for multilingual queues here: http://drupal.org/node/264138