Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Problem
- I have a taxonomy T which has no language but localizable terms
- I have a view V which has a filter F using taxonomy T
- If I expose the filter F, the terms in the exposed form are not localized
Patch
The attached patch (against beta 6) fixes this by implementing hook_form_alter for i18n_views and localizing the terms.
Comment | File | Size | Author |
---|---|---|---|
#21 | i18nviews.zip | 3.06 KB | dagmar |
#19 | i18ntax_tid_with_depth.patch | 3.82 KB | Alice Heaton |
#17 | i18ntaxnonomy.patch | 4.49 KB | Alice Heaton |
#16 | i18taxonomy.patch | 4.07 KB | Alice Heaton |
#15 | i18ntaxonomy.views_.inc_.txt | 755 bytes | dagmar |
Comments
Comment #1
Alice Heaton CreditAttribution: Alice Heaton commentedA new patch which :
Comment #2
Alice Heaton CreditAttribution: Alice Heaton commentedFixes a problem with the previous patch as localisation was only per filter type (eg. 'date' filters as a whole, while it's now possible for different date filters to have different labels).
As previously, this patch :
Comment #3
dagmarHello:
I have tested the patch #2 and doesn't work for me.
I don't know what kind of configuration are using in the exposed filter form for the taxonomy terms but in my case devel shows this info for an exposed filter for taxonomy terms:
Your patch display a lot of errors in line 156 (One per taxonomy term in the vocavulary). I think that it is because I don't have the $opt->option in my form.
I have created another patch that works in a diferent way. It removes all the translated terms and the user only see the terms for the active language.
Works fine for me.
Comment #4
Alice Heaton CreditAttribution: Alice Heaton commented@dagmar : As far as I can tell, your patch addresses a different issue than mine : I deal with terms that have been *localized* while yours deals with terms that have been *translated* ; different problem, and obviously different solution :)
We should try to write a patch that deals with both cases !
Comment #5
burlap CreditAttribution: burlap commentedI cannot make either of the patches to work for taxonomy terms (labels are localized ok). I'm not too proficient with devel module (and development for that matter), but I could try to find out what's wrong, if you could help me some details where and how to look...
Comment #6
nedjo@Anselm Heaton and dagmar:
Yes, both versions of this patch are are welcome and needed, thanks for contributing them.
Probably this should go in i18ntaxonomy rather than i18nviews, as it depends on i18nvocabulary.
This could be added to the existing
i18ntaxonomy_form_alter()
function. See that function for patterns to follow, e.g.:Is either of you up for consolidating the two and moving them to
i18ntaxonomy_form_alter()
?Comment #7
Alice Heaton CreditAttribution: Alice Heaton commentedI'd love to, but I have a lot to catch up on in my Drupal module maintenance work, so I won't be able to do this any time soon.
I'll have a go if it's not been done by the time I get to it, but that might be a couple of months away.
Comment #8
wmostrey CreditAttribution: wmostrey commentedThis is a first attempt to join both patches in i18ntaxonomy. It needs more work to reflect the code style of the current i18ntaxonomy_form_alter but it should be a good starting point.
Comment #9
nedjoNice start. On second thought, I guess this would be better in i18nviews, with a module_exists('i18ntaxonomy') test.
Comment #10
dagmarHello:
I'm don't post nothing before because i was investigating about the views handlers. I think that hook_form_alter is a posible solution but it not is the most elegant.
If we have a lot of taxonomy terms hook_form_alter will remove the terms in other languajes. But all of they will be loaded first. Bad performance.
I think that the better solution is use views handlers like this http://drupal.org/node/64004#comment-1125854 maybe i18n should overwrite the
default argument and define his own.
Some like this
And create the a handler that only load the correct taxonomy terms.
I don't know why hook_views_data_alter is not documented in the views docs. Comment, Taxonomy, Translation and Upload modules into views/modules directory have examples of the implementation of that hook.
Ok, this is what I'm think
Sorry for my english
Mariano
Comment #11
Jose Reyero CreditAttribution: Jose Reyero commentedComment #12
nedjoComment #13
Jose Reyero CreditAttribution: Jose Reyero commentedYes, I think this should go into i18nviews
However we should be able to reuse i18ntaxonomy api for that instead of writing all the translation logic for that form field from scratch and,
One very important thing that's missing is that we don't just translate all terms we come accross. Depending on the vocabulary settings each vocabulary may be translatable or not, we need to check that
@nedjo, you can also make i18nviews to require i18ntaxonomy, this would reduce clutter and will be much simpler for users.
Comment #14
homoludens CreditAttribution: homoludens commentedi had problem that i could translate only some of exposed views (all of them were "Taxonomy: Term" exposed filter).
solution was to turn on "Show hierarchy in dropdown" because then $form[$key]['#options'] is giving you array of objects, and not simple array.
i hope that problem and workaround are clear enough. (i was using diff from comment #8)
Comment #15
dagmarHello again:
I have created a patch using views handlers.
To test it copy i18ntaxonomy.views.inc into i18ntaxonomy and create a new directory 'includes' into this directory. Then copy 18ntaxonomy_handler_filter_term_node_tid.inc inside.
Upload module renamed the uploaded files for security reasons, please rename these files to their correct names
This patch needs work, specially in the "help text" I don't speak english very well and I'm not sure that "Limit list to terms with the same language that actual page language" be a good explanation of what this module does.
Anyway it works pretty good and I think that is the way to implement this feature.
By the way. I can't found i18nviews into i18n 6.x-1.0 version. For this reason I created the patch for i18ntaxonomy.
This patch adds a new option to exposed taxonomy terms in views options. Users can check this option to limit taxonomy terms to those that have the same language that the actual page language.
I'm not sure, but I think that is necesary that weight of i18ntaxonomy module > views weight.
And clear the drupal cache.
Comment #16
Alice Heaton CreditAttribution: Alice Heaton commentedHi,
I think the way it has been implemented by dagmar is #15 is the right way to go. It is implemented as an modification of the taxonomy views filter ; I agree this is a better approach than my original approach to use form_alter.
As such, I think this should live in i18taxonomy (as dagmar made it) : it's a views filter in i18ntaxonomy, this sounds right to me.
I have extended the patch in #15 to also localise the taxonomy terms in exposed views. This patch therefore addresses both issues, and is implemented as a (modification of a) views filter.
@dagmar :
1. You had forgotten to include your call to i18n_taxonomy_views_api ! I have also added that.
2. Please if you improve on your code and submit a patch here, make sure you also include the code to localise the terms, so that we can continue with a patch that addresses both issues.
Patch (from root of i18ntaxonomy) is attached.
Comment #17
Alice Heaton CreditAttribution: Alice Heaton commentedA few changes:
This patch superseeds the patch in #16 ; and (as the one in #16) fixes both issues. Patch from root of i18taxonomy module.
Comment #18
Alice Heaton CreditAttribution: Alice Heaton commentedBy the way, note that the patch in #16/#17 does not localize labels anymore. As localizing labels of exposed filters is not specific to taxonomy, this has been made a patch of it's own and can be found here : http://drupal.org/node/295305#comment-1525788
Comment #19
Alice Heaton CreditAttribution: Alice Heaton commentedAnd a small bonus : People who have applied this patch : http://drupal.org/node/271833#comment-1086526 (to get taxonomy-with-depth filter) can apply the attached patch to also get terms localized/filtered-by-language in their taxonomy-with-depth exposed filters.
This must be applied after the patch in #17. If you don't know what this is about, you probably don't need it - just use the patch in #17.
Comment #20
Jose Reyero CreditAttribution: Jose Reyero commented@Anselm,
This looks great.
However I'd rather have all the views integration part in i18nviews so the day views changes its api again all the integration bugs are in the same place.
I think I'll be doing the i18nviews module dependent on i18ntaxonomy so we don't have to use if_module_exists anywhere..
Sounds good?
Comment #21
dagmarI'm agree with Jose. Moving this features into i18nviews also solve another important issue.
Views and i18nviews will implement hook_data_alter()
Views includes the 'views_handler_filter_term_node_tid' handler.
And i18nviews will try to include 'i18nviews_handler_filter_term_node_tid'
The problem is that Views will overwrite 'i18nviews_handler_filter_term_node_tid' beacuse in system table it appears after i18nviews.
The solution is change the weight of i18nviews module to views_weight + 1. But if we continue implementing this into i18ntaxonomy, views should be a dependency of i18ntaxonomy and this is not correct.
I'm having problems to create a single file patch as Anselm Heaton did. Sorry, I spent two hours trying without results.
Please can anybody explain me how do that. I have read http://drupal.org/patch/create a lot of times!
For now, I attach the files to work with i18nviews.
Comment #22
Jose Reyero CreditAttribution: Jose Reyero commented@dagmar,
If you are working with a cvs checkout you just need to be in the right directory when creating the patch. I use Eclipse which makes it a lot easier.
Anyway, never mind, I'll apply the patch anyway into i18nviews.
Comment #23
dagmarJose:
Yes I'm using cvs. The fact is that i18nviews doesn't exists in DRUPAL-6--1 tag. This is what I did.
And this is wath cvs diff said:
cvs diff: Diffing i18nviews
cvs diff: i18nviews/i18nviews.install is a new entry, no comparison available
cvs diff: Diffing i18nviews/includes
cvs diff: i18nviews/includes/i18nviews_handler_filter_term_node_tid.inc is a new entry, no comparison available
cvs diff: Diffing i18nviews/translations
And the final patch doens't include the content of
i18nviews_handler_filter_term_node_tid.inc
i18nviews.install
Thanks Anselm for your email. This is what I'm doing for create the patch.
Comment #24
joostvdl CreditAttribution: joostvdl commentedI integrated the ZIP form #21 with the latest DEV release and also the localise labels patch (from #360024: Write views localization plugin) and all works fine.
Comment #25
otinanism CreditAttribution: otinanism commentedHi,
Can someone please help me understand if the exposed terms in views are translated in the current dev version of the module? If I understand correctly, from #24 it should work, but for me it does not.
Another question, is it possible to downgrade back to the stable release, since I did not see any difference with the dev release?
Sorry for the newbie questions...
Comment #26
otinanism CreditAttribution: otinanism commentedI am sorry to insist, but I really need to localise exposed terms... I see on the zip of #21 a class named i18nviews_handler_filter_term_node_tid.inc. I do not see this class on the dev release of the module. Isn't this supposed to be integrated on the dev release? thank you.
Comment #27
dagmar@otinanism: There are a few issues that must be solved before integrate i18nviews into i18n.
To localize exposed terms with #21 untar the file into modules/i18n (stable version) and then, for each exposed term, check the option:
"Limit list to terms with the same language that actual page language"
I also have tested #357529: Implement translation of customized 'translatable' views properties that is usefull to translate parts of the views (header, footer, labels for columns) but it doen't work for labels in exposed filters.
Patch #18 in #360024: Write views localization plugin is not 'elegant', and need to be implemented as a view plugin, but maybe can help you.
Comment #28
dagmarI'm also working on this issue #357529: Implement translation of customized 'translatable' views properties. What do you think about implement this feature (Localise views esposed forms) into the plugin #360024: Write views localization plugin?
Comment #29
anrikun CreditAttribution: anrikun commented@Anselm Heaton (#19)
I can get to make i18ntax_tid_with_depth.patch work.
Maybe I did something wrong when patching.
Could you please post the patched files:
- i18ntaxonomy.module
- i18ntaxonomy.views.inc
- includes/i18ntaxonomy_handler_filter_term_node_tid.inc
- includes/i18ntaxonomy_handler_filter_term_node_tid_depth.inc
Thanks!
Comment #30
anrikun CreditAttribution: anrikun commented@Anselm Heaton (#19)
It appeared that my taxonomy tables' language fields were messed up.
Now that I fixed them, it works.
But I get something strange though:
My hierarchy is
a
-b
-c
The original terms are in French.
Strings a and b are localized in English.
c is not localized yet
List is displayed in French as:
a
--b
--c
In English it's displayed as:
a (localized)
--b (localized)
-c
There's an extra - in French, and in English when strings are localized.
If I localize c
Then I get in English:
a (localized)
--b (localized)
--c (localized)
Shouldn't the correct format be in French and in English:
a
- b
- c
Comment #31
ezeey CreditAttribution: ezeey commentedI have the problem that I have an exposed block with taxonomy terms.
They are localized via i18n "localiza terms", but are still untranslated in my block.
Is this the right patch for me? Unfortunatly I got an error while patching. So is there a patch for the current i18n version?
Comment #32
momentuminc CreditAttribution: momentuminc commentedSame problem here!
Comment #33
feuillet CreditAttribution: feuillet commentedLooking for a working solution too...
Comment #34
adewinne CreditAttribution: adewinne commentedI found a way that worked for me for exposed view filter dropdowns. In your template.php add these two functions:
function themename_select($element) {
$select = '';
$size = $element['#size'] ? ' size="'. $element['#size'] .'"' : '';
_form_set_class($element, array('form-select'));
$multiple = $element['#multiple'];
return theme('form_element', $element, '
'. _form_select_options($element) .'
');
}
function _form_select_options($element, $choices = NULL) {
if (!isset($choices)) {
$choices = $element['#options'];
}
// array_key_exists() accommodates the rare event where $element['#value'] is NULL.
// isset() fails in this situation.
$value_valid = isset($element['#value']) || array_key_exists('#value', $element);
$value_is_array = is_array($element['#value']);
$options = '';
foreach ($choices as $key => $choice) {
if (is_array($choice)) {
$options .= '';
$options .= form_select_options($element, $choice);
$options .= '';
}
elseif (is_object($choice)) {
$options .= _form_select_options($element, $choice->option);
}
else {
$key = (string)$key;
if ($value_valid && (!$value_is_array && (string)$element['#value'] === $key || ($value_is_array && in_array($key, $element['#value'])))) {
$selected = ' selected="selected"';
}
else {
$selected = '';
}
$options .= ''. check_plain(t($choice)) .'';
}
}
return str_replace(''','\'',$options);
}
Notice 5 lines from the bottom I added t around $choice.
Comment #35
dagmarI will try to fix this patch soon.
Comment #36
Boobaasubscribe
Comment #37
anrikun CreditAttribution: anrikun commentedCCK has just been updated to 6.x-2.6
Views, to 6.x-2.7
and i18n to 6.x-1.2
Do you know if patches #17 and #19 have been committed or if they are still needed?
Comment #38
Bilmar CreditAttribution: Bilmar commentedsubscribing
Comment #39
DomoSapiens CreditAttribution: DomoSapiens commentedI added the ZIP from #21 with the latest stable release (6.x-1.2) and this patch works fine.
I had some language neutral taxonomy terms which are used in both Dutch and English and these terms are not displayed anymore.
Comment #40
robby.smith CreditAttribution: robby.smith commentedI was wondering if there has been any updates to this new feature?
I'm looking at Views 6.x-3.x-dev and i18n 6.x-1.x-dev
Thank you
Comment #41
rburgundy CreditAttribution: rburgundy commented+1 subscribing
Comment #42
ximo CreditAttribution: ximo commentedThe custom module provided in comment #90 of #346028: Translate taxonomy term names in Views solved translation of exposed term filters for me with Views 2.8 and I18n 1.2.
Comment #43
ak CreditAttribution: ak commentedsubscribing
Comment #44
rburgundy CreditAttribution: rburgundy commentedI have also moved to Views 6.x-3.x-dev and i18n 6.x-1.x-dev for testing.
@dagmar - I see in #35 that you may be able to fix this patch? Would you have the time?
Comment #45
GiorgosK#346028: Translate taxonomy term names in Views seems to solve this problem
please test and report there
Comment #46
robby.smith CreditAttribution: robby.smith commentedGiorgosK - so is this issue a duplicate of #346028: Translate taxonomy term names in Views?
Comment #47
Jose Reyero CreditAttribution: Jose Reyero commentedMoved to new project. See #788290: Fix views compatibility issues (2.x, 3.x), spin off i18nviews module?
So duplicate?
Comment #48
houdelou CreditAttribution: houdelou commentedThe patch at #17 is woking with 6x-1.7 ! Thanks
Comment #49
heyehren CreditAttribution: heyehren commentedDifferent approach for the same problem which worked for me: http://drupal.org/node/929368#comment-4025498