Drupal core has a method to have something other than the core module handle taxonomy, variable taxonomy_override_selector. It doesn't add the taxonomy forum element in those cases.

i18ntaxonomy alters the forum node forum no matter what along as $form['taxonomy'] is there, setting anything of $form['taxonomy'][$vid], and it's weighted at 5? so anything that wants to avoid it would have to be weighted higher, but if something is supplying the taxonomy forum it wants to run at around -1 so other modules (content_taxonomy, comment taxonomy add, etc.) can perform their alterations.

The simplest way is to check on taxonomy override selector.

A more complex way is to not override the values unrelated to it, like #type, but it's sharing code so that's more complex.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

hefox’s picture

as noted in http://drupal.org/node/601500#comment-2368706 this patch had a syntax error, this one should be fixed (manually edited) but didn't test it (bad fox, bad :( ).

TripleEmcoder’s picture

I confirm all what hefox says ;)

Wim Leers’s picture

Status: Active » Reviewed & tested by the community

Not sure what's holding back this patch from being committed. Code style isn't perfect, but since it's a single-line patch to commit, that can easily be fixed by the committer.
Please commit this :)

YK85’s picture

tested and +1 for commit

Alan D.’s picture

Wim Leers’s picture

Thanks Alan!

Jose Reyero’s picture

Status: Reviewed & tested by the community » Fixed

Ok, committed.

Thanks.

Wim Leers’s picture

Thanks!

Status: Fixed » Closed (fixed)

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

domidc’s picture

Category: feature » bug
Status: Closed (fixed) » Active

When some module alters this setting the terms dont get localized anymore on the node form. In my specific case hierarchical select alters the setting, this is causing the terms not being localized anymore. Can someone explain why this implemented like this?

When removing the !variable_get('taxonomy_override_selector', FALSE) terms are getting localized again.

default:
      if (isset($form['type']) && isset($form['#node']) && $form['type']['#value'] .'_node_form' == $form_id
        && ($node = $form['#node']) && isset($form['taxonomy']) && !variable_get('taxonomy_override_selector', FALSE)) {
        // Node form. Translate vocabularies.
        i18ntaxonomy_node_form($form);
      }
  }
domidc’s picture

FileSize
920 bytes

This removes the support and fixes my problem but I there is probably a better way to fix the issue

hefox’s picture

when taxonomy_override_selector is enabled, cannot assume the taxonomy input will be what core provides (which i18n alterations assume), so yeah, go check the module you're using for taxonomy selection to see if there is an issue queue about this/move this issue there/create a new issue there.

domidc’s picture

Project: Internationalization » Hierarchical Select
Version: 6.x-1.x-dev » 6.x-3.1
Component: Taxonomy » Code - Taxonomy
hefox’s picture

Title: Honour taxonomy_override_selector » Ensure normal taxonomy selection gets translated

Title doesn't make sense. I believe it's not HS that isn't getting translated, corrected, just the normal taxonomy selection?

Wim Leers’s picture

Title: Ensure normal taxonomy selection gets translated » Ensure normal (non-HS) taxonomy form items get translated via i18n
Assigned: Unassigned » Wim Leers
Status: Active » Fixed

I think I understand what's happening.

HS needs to set the taxonomy_override_selector variable, so it can use HS instead of the regular taxonomy form. HS then uses the regular taxonomy form (by duplicating its code) when HS is not enabled for that vocabulary, and it uses the HS taxonomy form otherwise (there's slightly more nuance to it than just this, but this is the essence). However, when the regular taxonomy form has been generated by HS, then i18n won't be applied to it.

Committed a patch that should fix it: http://drupal.org/cvs?commit=389256.

This really is a stellar example of the hell that aspect-oriented programming can trigger: one needs an override to insert HS form items without also generating the non-HS form items. But it needs to duplicate the original code, too, just to also support forms that use Taxonomy without HS. And then one needs to alter *both* paths to support i18n. So, now if either of the following change, I need to replicate the changes: the Taxonomy core form, i18n or when modules such as Taxonomy Access, Taxonomy Access Lite, Term Permissions need to be supported. If this ain't FAPI hell, then I don't know what is. The most demotivating aspect of Drupal module maintenance for sure.

Status: Fixed » Closed (fixed)

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