Summary:
When I create a view with Views 2 on Drupal 6.2 and expose a "Taxonomy: Term ID" filter, even though the term names are localized in two languages (english and spanish), when the page is displayed in both languages, only the english term name is displayed.

Expected Behavior:
When the page is viewed in another language, terms that have localized names in that language should display the localized version.

Source:
I traced the source of the problem to what I believe to be the cause. In the file taxonomy.views.inc on line 840, the taxonomy term name is set without being encased a call to t().

...
      else {
        $options = array();
        $result = db_query("SELECT * FROM {term_data} WHERE vid = %d ORDER BY weight, name", $vocabulary->vid);
        while ($term = db_fetch_object($result)) {
          //Should be t($term->name)
          $options[$term->tid] = $term->name;
        }
      }
...

I tested this fix by modifying the code to call t($term->name) and this almost resolves the problem. Now, I can localize the term names presented, but I have to specifically translate them for that page. It does not use the translation that I already provided for taxonomy term. If I look at the "Translate Interface" admin page, I see two translatable strings now:

Taxonomy Rural term:8:name
Built-in interface Rural /dynamic/es/search/projects

Translating the new Built-in interface entry solves my problem, but I'd like to have only one entry appear and use the translation of the Taxonomy term.

Comments

merlinofchaos’s picture

merlinofchaos CreditAttribution: merlinofchaos commented

I'm not aware of any convention in Drupal that says that term names are supposed to be run through t(). There are no instances of this in taxonomy.module, so if Views did this, that behavior would be incorrect.

timburke1661’s picture

timburke1661 CreditAttribution: timburke1661 commented

I agree that using t() is the wrong solution, but there is definitely a difference in behavior between e.g. Views 2 and Node display. Look for example, if you have a multilingual site with two languages, English and Spanish using i18n. Now, create a taxonomy vocabulary and mark it as having localizable term names. Create some terms and then use the Translate Interface to translate those terms to another language. Now go to Create Content and create a Node and tag it with one of those terms that you just created. You'll see the term name in English. Now change language to another language and edit that node or create a new one. You will see the localized term names.

This is the behavior that I think views should conform to. If you are showing a view with an exposed filter that is filtering on Taxonomy: Term ID, and the page is viewed in different languages, then the terms should also be localized. To see an example of this not happening see the following two pages:

http://www.communityrefund.org/dynamic/search/projects
http://www.communityrefund.org/dynamic/es/search/projects

The drop down menus are all exposed filters on taxonomy terms, and in the english and spanish versions of the page, though the node text automatically translates itself, the term names do not. Does this make the issue more clear?

I'll do some more investigating to see if I can find out what the node editing page is doing differently to make localize the terms.

merlinofchaos’s picture

merlinofchaos CreditAttribution: merlinofchaos commented
Status: Active » Closed (works as designed)

The reason that there is a difference in node behavior is that the module you're using for taxonomy translation modifies the node. It would have to modify the view as well. Drupal core doesn't support translating vocabulary. I am happy to work with the creators of that module and make sure it has the capability to help with Views translation, but you must understand that this is:

1) not automatic
2) not views' responsibility.

timburke1661’s picture

timburke1661 CreditAttribution: timburke1661 commented

Understood. Thank you very much much for looking at this issue so quickly and I'm sorry for posting it as a views bug. I'll look to see what I can do about improving this behavior in the other module.

thekayra’s picture

thekayra CreditAttribution: thekayra commented

@timburke1661: Hae you been able to solve this?

TIA,
Kayra.

ak’s picture

ak CreditAttribution: ak commented

I'm struggling with the exact same problem. I'm using the http://drupal.org/project/i18n module and can't get my exposed term filters to display translated. Any help or advice?

feuillet’s picture

feuillet CreditAttribution: feuillet commented

A quick and very dirty hack to solve this is, to solve this with a little dynamic php/javascript. Thats what i did, because i needed a solution very fast:

<script type="text/javascript"> 
document.getElementById('edit-myfield').options.length=0
document.getElementById('edit-myfield').options[0]=new Option("<?php print t('- any -') ?>", "All", true, false)
document.getElementById('edit-myfield').options[1]=new Option("<?php print t('Term1') ?>", "2", true, false)
document.getElementById('edit-myfield').options[2]=new Option("<?php print t('Term2') ?>", "4", true, false)
document.getElementById('edit-myfield').options[3]=new Option("<?php print t('Term3') ?>", "3", true, false)
document.getElementById('edit-myfield').options[4]=new Option("<?php print t('Term4') ?>", "50", true, false)
</script>

Where "edit-myfield" is the ID of the select form...

As i mentioned, its really dirty... :)

rogerpfaff’s picture

rogerpfaff
he/his
Primary language German
Location Munich
CreditAttribution: rogerpfaff commented

subscribing

boogsbobo’s picture

boogsbobo CreditAttribution: boogsbobo commented

subscribing

boogsbobo’s picture

boogsbobo CreditAttribution: boogsbobo commented

http://drupal.org/node/346028#comment-2769734

problem is with i18n module. this patch solves it

ducdebreme’s picture

ducdebreme CreditAttribution: ducdebreme commented

subscribing

bibo’s picture

bibo CreditAttribution: bibo commented
Status: Closed (works as designed) » Fixed

I had this problem too. The patch mentioned by boogsbobo has been committed in 18n(!)

However, the module it was attached to (i18nviews) was moved out of the i18n-bundle to an external module: http://drupal.org/project/i18nviews. This happened just lately, in the i18n 1.5-release. So, to fix this just upgrade to the new i18n and download i18views.
(You should probably also deactivate the old i18nviews and make sure you remove it from i18n-folder, before activating the new external release).

Marking this as fixed.

Edit
Also note that you need the latest dev-version of i18nviews (or a release after July 2 2010, see commitinfo: http://drupal.org/node/346028#comment-3151612).

Status: Fixed » Closed (fixed)

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