Labels, translations and other languages

Could you post a screenhot of the output and error you're getting? I haven't explicitly done anything wrt translations of field labels as I thought this would be handled transparenty by View itself, but it seems I'm wrong.

I've removed all occurrences of t() from the options code which should fix the module in multilingual sites, albeit now with only English options labels.

Seems this issue should still be active...

I've encountered this problem with the most recent 6.x-1.x-dev version of the module.
I had a label called link that would get translated to リンク, the japanese equivalent, and then just got stripped out by _views_xml_strip_illegal_xml_name_chars(). Bypassing the illegal xml name chars check did give me the label back, but in Japanese. I would tend to think that in many asian languages (mainly Chinese, Japanese, Korean, Thai, and so on) having tags kept in English (or at least not translated) would be the preferred behavior.

I've tried to investigate what was causing my label to get translated but haven't found a definite answer, my knowledge of Views internals being quite limited at the moment.

Hi, is the field label translated when using the default View styles like list or unformatted? Because if it is there's nothing the module can do as it relies on Views to render the field.

Same issue with 7.x-1.x-dev

The label defined in Views is translatable, so if I add a label named 'content' for my real content field 'foo' views will create a t('content') internally.

The Views preview works as expected, but when you access the atom feed (is what I defined in my case) from the browser the tag is translated in (the italian word for content, the italian is my default site language)

I'm actually removed the generic 'content' term translation from the drupal internationalization configuration as workaround, but I think this issue should be resolved in another manner :)

+1
Using last 7.x-1.x-dev the problem still exist. Can someone fix it? It translates 'link' into my language, so i have to delete link tranlation in vocabulary. Thats really no good because this translation is used on many places across the website.

Thans for any advice

I think the best solution for this is to add an extra configuration option for each views field to be used as 'Key' of the output array instead of using the 'label' of the field, because the label usually get translated if i18nviews enabled, but as the 'Key' it should not be translated.

I have dug into this problem, it turns out, we can't really do much about this. As I have already mentioned, the 'label' will be translated if i18nviews is enabled, which makes it can not be used as a reliable json/xml element key.

The first solution I thought would be add a custom views field option to truly use it as the element key, but, the views field handler's options_form does not really give us any chance to add a option into it. It seems we can alter the views_config_item_form, but it would require lots of hacking on the option saving logic, still not an ideal solution. So, this approach is pretty mush a dead end.

The second solution I thought would be completely remove the use of label, and use the field id instead, this would decrease the reliability of the rendered json/xml, so, this option is my least acceptable choice.

Then, I go through the views unpack_option process to see if is there any chance I can stop the translation of the label, then, I found actually the views calls i18nviews_plugin_localization_i18nstrings class to translate the label, so I believe we can extend this class and use it for views display that use views_datasource as the formatter, so that we have enough context information to skip the translate of field label.

Drupal 6 has been EOL for some years, closing all D6 issues.