My taxonomy vocabularies are created with this option selected:
Localize terms. Terms are common for all languages, but their name and description may be localized. But I tried an other option and as long as the module is enabled it takes over taxonomy module. (The best proof of this is in "field_config" table in the database, "module" column.)
The views exposed filter widgets are not the same wether you use a term reference field driven by taxonomy module or by i18n_taxonomy module.
With taxonomy you can choose between Dropdown (select list widget) and autocomplete (with the operators is one of / is not one of) whereas with i18n_taxonomy there's just a blank input value field (and operators is equal to, etc.). (See the attached screenshots it will certainly make things clearer as I can describe them in "verbose mode")
| Comment | File | Size | Author |
|---|---|---|---|
| Capture d’écran 2011-04-22 à 21.49.09.png | 47.32 KB | Jerome F | |
| Capture d’écran 2011-04-22 à 20.41.16.png | 75.51 KB | Jerome F |
Comments
Comment #1
Jerome F commentedWhat I mean when I say
is that:
When you create a taxonomy vocabulary with Taxonomy translation module enabled the value in "field_config" table for the field type "taxonomy_term_reference" is:
i18n_taxonomyinstead of the originaltaxonomyvalue*, that's what makes me think that Taxonomy translation module takes full control over the taxonomy term reference field.So I assume this is somehow related to the views exposed filter issue, isn't it ? If Taxonomy translation module takes over Taxonomy module, then it should provide the same views integration as Taxonomy does.
(*Note: All these database observations are discussed more in depth in this issue about what happens when taxonomy module is disabled: http://drupal.org/node/1078422)
I mark this as major as it has significant repercussions on taxonomy views integration.
Comment #2
Jerome F commentedComment #3
jose reyero commentedYou're right, we are 'taking over' taxonomy widgets in order to provide some translation.
This causes some other issues like #1078422: Disabled taxonomy fields when enabling and disabling i18n_taxonomy
So I think what we are doing is changing that to provide i18n's own widgets that don't mess with other modules.
Comment #4
Jerome F commented@Jose Reyero Thank you for your answer. That's right, and I'm also interested in the other issue.
Ok, so would it be possible to provide the dropdown select list widget and the autocomplete widget for views exposed filters like the regular taxonomy widgets?
Comment #5
jose reyero commentedNow the other issue has been fixed, not sure where we are with this one.
Anyway, I think views should respect whatever handler is defined for the field. Moving to i18nviews just in case.
Comment #6
Jerome F commented@Jose Thank you for your message and for correcting status
i18n taxonomy's views exposed filters widgets are still a simple empty textarea. We definitely needs to be able to choose between a select list and an autocomplete widget like for regular not translatable taxonomy.
Comment #7
miro_dietikerI'll make this a separate issue. We need this separation to assign tasks.
i18nviews does no more any takeover and the primary issue has been fixed.
Comment #8
Jerome F commentedThank you