Labels not translated in Views

By labels, do you mean the labels of CCK fields as customized via the CCK UI? If so, this may be a CCK rather than a Views issue.

That's almost certainly CCK then.

CCK builds default views integration in includes/views/content.views.inc, function content_views_field_views_data(). And that used t() to wrap field labels in 'title' and 'title short' items of the exposed views columns.

Maybe it just happens with CCK fields not implemented in CCK distribution?

subscribe

subscribe

Yes, I also have the same question - is it a bug or not implemented function? I thing it's a Views issue, couse it happens only in Views.

SaxxIng, how exactly did you resolve it?

I've fixed it replacing line 560 of views/theme/theme.inc (version 1.72 2009/04/08 04:24:52) with this one:

      $widget->label = t($info['label']);

So you can enter the english label, and it will be translated into italian.

sersim, it is a great and so simple solution! Thank you very very much

As proposed #11 patch

Cck should give untranslated info about fields so views can translate but maybe before _preprocess

Anyway need review of views maintainers

subscribe

Hmm. I'm not sure Views should be translating the label at this point. Normally Views translates its own data upon load. Data given to it from an external source should already be translated, or we will end up translating labels multiple times.

subsribing

@merlinofchaos cck widget brings not only data but a descriptive metatada about, suppose label should be translated at rendering time so data in memory can be reusable.

I think the point is this is not only about CCK, right?

My exposed filter labels are not translatable. So 'Filter by tag:', one of my exposed filters, is not translatable.

I'll try patch in #13

As I said, Views translates upon load, not upon display. And this definitely won't work right with the translation patch that is in progress.

@merlinofchaos: even if the cck-lables have a translation, views only show their original version. as a result i have the original lables and their translated content which is a mixture of two languages.
labels-do-not-appear-in-the-translation-in-views
alas, i am not a php expert and do not want to fiddle with the view module. on the other hand i think it cannot be that difficult changing this. or maybe this is a feature request?
generally, i think views is one of the best modules out there and boosts drupals power by lightyears.

a reply would be very much appreciated.

subscribing

subscribing

Patch from #531662: Internationalization support has been committed to
CCK 7.x-2.x-dev 2009-Sep-04
and
CCK 6.x-2.x-dev 2009-Oct-15
and solves this problem

NOTE: CCK 2.5 does not include the patch

Merlin was right it was a cck related issue thus marking this as fixed

I am still experiencing this issue. I created a cck text field originally with label in English and then in Translation Table I set the French and English translations, but when viewing the Views page in French it still shows the label in English.

Site default language: French
Also enabled language: English

Should I be making the cck field originally in French instead of English?

In translation table I see:
Original | French | English
apple | pomme | apple

The Views page shows 'apple' even if the language is set to French.

Same problem #25. I have CCK-2.6 and Views-2.8.

Subscribe.

I also need to translate the field label and "rewrite field output text" added via the Views admin UI.

same issue as of #25

Everything works well on my side.
I am using:
Drupal 6.16
Views 6.x-2.10.

If something is not working go to "admin/build/translate/refresh"
and "refresh strings" + "update translations".

then go to "/admin/build/translate/search" and check if the translations are ok.

clear drupal cach (go to "admin/build/themes" and press save button).

now check your views. everything has to be ok.

reopening, because it works only if you choose Custom Label.
it doesn't work if you choose Widget Label.

Widget labels are provided by CCK, and must be translated by CCK. Views can't translate them.

I have the same problem. When I choose Custom Label it´s translated, but not with Widget Label. Reopening because on the normal display of a node of that content type node the label of that CCK it´s translated correctly.

Why is it that today everyone is smarter than me?

Widget labels are provided by CCK, and must be translated by CCK. Views can't translate them.

Which am I?

1) Wrong
2) Lying

Because I thought my explanation was clear and unambiguous. If 1) please explain why I am wrong (and no, just because data is displayed within Views does *not* mean Views is responsible for that data. You don't blame node.module for how CCK fields are translated when viewing a node, do you?).

I will add a little bit more to my explanation.

Currently, Views translates on load. (Note: Yes we know this is not good. There's work to improve this). However, when selecting 'widget', CCK provides this value dynamically. Views is not able to translate this value. CCK must provide the translation when it sets the label.

Sorry, I didn't understand very well your previous answer. I wasn't trying to be smarter than anyone. I'm sorry if you felt bothered by it.

In the hope to help those that may land here, still with problems with CCK field labels:

- Initially, CCK was translating field labels using t(), and it still does, but...
- Some time ago, integration with i18n was possible since #531662: Internationalization support and #531660: i18n + CCK. In addition, support for CCK stuff was added to Translation Table module, see #499668: Possibility to integrate cck fields?.

Now, let's look at CCK integration for Views:

- The Views field handler implements the 'label' option as a translatable attribute.
- CCK fields use a Views handler that provides an option to choose how to generate the label of the field for Views. You can select from Node, Custom or Widget label.
- When you choose "Widget label", CCK passes to Views $field['widget']['label'], which is already translated if you have installed i18n stuff with support for CCK.

Hi markus_petrux

I ran into the same issue:

If I choose "Widget label" in the view, the label is not translatable.

I have read you post again and again, but I don't see a solution. Assumign I have views and i18n (views and cck translation acrivated).

How can I force the translation using the "Widget label" selection in views?

After translating the CCK field labels and descriptions (recommended to use http://drupal.org/project/translation_table), you may need to clear the content cache, and maybe also the views caches.

At line 210 in "view/theme/theme.inc" in function template_preprocess_views_view_fields() you can replace:

      $object->label = check_plain($view->field[$id]->label());

with:

      if(function_exists('locale') && $language->language != 'en') {
        $object->label = locale(check_plain($view->field[$id]->label()), $language->language);
      } else {
        $object->label = check_plain($view->field[$id]->label());
      }

and at the beginning of the function declare: global $language;

This should work. It works for me.

You can use a similar approach in function template_preprocess_views_exposed_form();

Here's the patch for this issue. Please review it.

You are right over here. But in my tests (maybe I did something wrong), not even a custom inputed label was traslated.
But whatever the case, the posted patch should translate the field if it has a translation.

Can someone explain why http://drupal.org/node/356951#comment-2954942 is not valid anymore?

Translation of views is really hard. Therefore this part will be written right for views3. It's definitive a much harder task then this simple patch.

Your patch might lead to an incredible amout of strings in the db if you have a dynamically changeing label.

I don't want to reset to reset but this is for me the real status of this issue.

not even a custom inputed label was traslated.

That's afaik the case which don't need to be handled by cck. But anyway this has to be done good and not this hacky way.

Thanks for the input. I reviewed my own code again and you are right:

* This is a hacky way!
* And it will generate strings in db, so do not use it.

It has to be done the propper way, and I hope it will be written right for Views3.

Based on http://drupal.org/node/356951#comment-2954942, I am setting this back to won't fix. Sorry, my mistake.

#30 worked for me guys

updated from
drupal 6.16
cck 2.6
views 2.10
to
drupal 6.17
cck 2.7
views 2.11

then saved a node, didn't help, emptied the cache, didn't help, then stumbled upon #30, now it works like a charm. the theme page save fixed it. i already tried the rest.
only thing about the order: first i saved the theme page again, then emptied the cache, hope this helps
great work peeps!
(is this now working out of the box on a clean install? or do we have to follow #30 every time we create a label translation? not a problem if that's the case, just to be sure)

Hello!

My setup is:
Drupal 6.20
CCK 6.x-2.8
Views 6.x-2.12

The way I went around this issue was following advice in #40 with some tweaks.
I know hacking is a bad practice and I should burn in hell, but if someone is in a hurry:
Around line 340 in theme.inc:

  foreach ($columns as $field => $column) {
    // render the header labels
    if ($field == $column && empty($fields[$field]->options['exclude'])) {
      $label = check_plain(!empty($fields[$field]) ? $fields[$field]->label() : '');
      // HACK
      global $language;
      if(function_exists('locale') && $language->language != 'en'){
        $label = locale($label, $language->language);
      }

There's a helper function with a missing t() envelope.

Look in modules/views/handlers/views_handler_field.inc

For:

/**
* Get this field's label.
*/
public function label() {
if (!isset($this->options['label'])) {
return '';
}
// 2025-05-13-GL Enclosed in t() function to enable table heading translations
return t($this->options['label']);
}