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.

Comments

Title:localize taxonomy of views exposed formsLocalise views exposed forms
StatusFileSize
new1.38 KB

A new patch which :

  • Localises taxonomy terms in exposed forms (as per original bug description) ;
  • Localises labels in exposed forms.

StatusFileSize
new1.41 KB

Fixes 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 :

  • Localises taxonomy terms in exposed forms (as per original bug description) ;
  • Localises labels in exposed forms (improved behaviour compared to patch in comment #1)

StatusFileSize
new1.44 KB

Hello:

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:

tid  (Array, 4 elements)
    #type (String, 6 characters ) select
    #options (Array, 37 elements)
        All (String, 5 characters ) <Any>
        60 (String, 12 characters ) Arqueología
        40 (String, 22 characters ) Arquitectura y Diseño
        42 (String, 5 characters ) Artes
        81 (String, 10 characters ) Archeology
        82 (String, 23 characters ) Architecture and Design
        103 (String, 18 characters ) Arts and Languages

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.

Localises labels in exposed forms (improved behaviour compared to patch in comment #1)

Works fine for me.

@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 !

I 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...

Status:Needs review» Needs work

@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.:

<?php
     
switch (i18ntaxonomy_vocabulary($vocabulary->vid)) {
        case
I18N_TAXONOMY_TRANSLATE:
        .....
?>

Is either of you up for consolidating the two and moving them to i18ntaxonomy_form_alter()?

Is either of you up for consolidating the two and moving them to i18ntaxonomy_form_alter()?

I'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.

StatusFileSize
new1.84 KB

This 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.

Nice start. On second thought, I guess this would be better in i18nviews, with a module_exists('i18ntaxonomy') test.

Hello:

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

<?php
function i18nviews_views_data_alter(&$data) {
 
$data['term_data']['name']['field']['handler'] = 'i18nviews_handler_field_taxonomy';
}
?>

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

Category:bug» feature

Issue tags:+i18n sprint

Yes, 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.

i 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)

Version:6.x-1.0-beta6» 6.x-1.0
Status:Needs work» Needs review
StatusFileSize
new1.89 KB
new755 bytes

Hello 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.

i18n/i18ntaxonomy/i18ntaxonomy.views.inc
i18n/i18ntaxonomy/includes/i18ntaxonomy_handler_filter_term_node_tid.inc

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.

For example, If views weight is 10:
UPDATE system SET weight = 11 WHERE name = 'i18ntaxonomy';

And clear the drupal cache.

StatusFileSize
new4.07 KB

Hi,

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.

StatusFileSize
new4.49 KB

A few changes:

  • I've cleaned up the localizing code, so it reads the vocabulary itself to work out depth rather than preg_matching for leading dashes (yes, that was pretty ugly) ;
  • I've factored the two functionalities ("filter terms to current language" and "localize terms") in separate methods for claritity.

This patch superseeds the patch in #16 ; and (as the one in #16) fixes both issues. Patch from root of i18taxonomy module.

By 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

StatusFileSize
new3.82 KB

And 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.

@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?

StatusFileSize
new3.06 KB

I'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.

Issue tags:+i18n views

@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.

Jose:

Yes I'm using cvs. The fact is that i18nviews doesn't exists in DRUPAL-6--1 tag. This is what I did.

cvs -z6 -d:pserver:anonymous:anonymous@cvs.drupal.org:/cvs/drupal-contrib checkout -d i18n-DRUPAL-6--1 -r DRUPAL-6--1 contributions/modules/i18n/
cd i18n
#create i18nviews.install file
vim i18nviews.install
# modify i18nviews.module
vim i18nviews.module
cd includes
# modify i18nviews.views.inc
vim i18nviews.views.inc
# create handler
vim i18nviews_handler_filter_term_node_tid.inc
cvsdo add i18nviews_handler_filter_term_node_tid.inc
cvsdo add i18nviews.install
cd ..
cvs diff -Rup i18nviews > i18nviews_taxonomy.patch

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.

Version:6.x-1.0» 6.x-1.x-dev

I 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.

Hi,

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...

I 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.

@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.

I'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?

@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!

@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

I 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?

Same problem here!

Looking for a working solution too...

I 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('&#039;','\'',$options);
}

Notice 5 lines from the bottom I added t around $choice.

Status:Needs review» Needs work

I will try to fix this patch soon.

subscribe

CCK 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?

subscribing

I 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.

I 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

+1 subscribing

The 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.

subscribing

I 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?

#346028: Translate taxonomy term names in Views seems to solve this problem
please test and report there

GiorgosK - so is this issue a duplicate of #346028: Translate taxonomy term names in Views?

Project:Internationalization» Internationalization Views
Version:6.x-1.x-dev» 6.x-2.x-dev
Status:Needs work» Closed (duplicate)

The patch at #17 is woking with 6x-1.7 ! Thanks

Different approach for the same problem which worked for me: http://drupal.org/node/929368#comment-4025498