It should be possible to enable label translations for exports (like CSV). This was default behaviour in the past, but has been changed in favour of disabling label translations completely for all export types.

Original problem:

At least using XML output style, field labels get translated (and affect XML element names). This is very unwanted behaviour in XML, when I want the data structure to be exactly something, and not changing per language. I have set Views' localization plugin to "None" but it doesn't help.

Members fund testing for the Drupal project. Drupal Association Learn more


johnv’s picture

Status: Active » Postponed (maintainer needs more info)

Did you set the following in the Views display: Advance --> Other --> Field Language to e.g., "Language neutral"?

pebosi’s picture

Same problem here using CSV export. The option "Language neutral" is selected and also tried the other options of "Field language" with no success. And the content of Global Textfields gets translated too.

ram4nd’s picture

Had the same problem, I solved it by giving my labels unique names.

Steven Jones’s picture

Assigned: Unassigned » Steven Jones
Status: Postponed (maintainer needs more info) » Active
Issue tags: +Needs tests

Let's get some tests in, and then fix this eh?

Steven Jones’s picture

Status: Active » Postponed (maintainer needs more info)

I can't seem to reproduce getting any field labels in views to be translated, let alone the ones in Views data export. How are you getting the labels translated in the first place?

Steven Jones’s picture

Assigned: Steven Jones » Unassigned
Frank Ralf’s picture

Same problem here. When accessing the view via the /de/ path the label "image" gets translated as "Bild" in the exported XML. Will try the recommendations above and report back.

Setting option "Language neutral" doesn't solve the problem. A unique label name does work but IMO is only a workaround.

Mabuy’s picture

Real problem for me as the Google contacts CSV syntax forces me to use labels like "name" and "birthday" and the corresponding fields are not identified when importing to Google because these labels get translated in the produced CSV file to "nom" and "anniversaire". I also need to rewrite field values using text like "home" (to specify a phone type) but this gets also translated to "accueil" !

I confirm that Setting option "Language neutral" or even "English" doesn't solve the problem.

Mabuy’s picture

In my case I solved the problem by adding a space in front of the labels, for instance: " Home". Then it doesn't get translated and the space seems not to cause problems during the Google importation.

MegaChriz’s picture

A workaround can be to enable language detection, for example for 'session'. Then you can generate the XML with the English labels by adding the ?language=en to the URL. Problem is that the content can become English as well. In my case, I had added the path alias to the XML view and it fell back to the system path, because the path alias is localized.

MegaChriz’s picture

Issue summary: View changes
Status: Postponed (maintainer needs more info) » Needs review
720 bytes
FAILED: [[SimpleTest]]: [MySQL] 75 pass(es), 22 fail(s), and 84 exception(s). View

It took me a long time to figure out at what place the label get its translation, but here is what I found:

  • In the method option_definition() of the class views_handler_field from the file views/handlers/ the following code marks the label as translatable:
    $options['label'] = array('default' => $this->definition['title'], 'translatable' => TRUE);
  • The translation happens when $handler->init() is called in the method get_handlers() of the class views_plugin_display from the file views/plugins/
  • Right before that init() call the label is still untranslated. I found out I could reach the untranslated label by calling get_option('fields') on an instance of views_plugin_display. That instance can be found on $view->display_handler.

So, in the attached patch the untranslated label is retrieved by calling get_option('fields') on the display handler. Note though that if a field handler overrides the label() method (for whatever reason), that code will not be executed. So there is a probability that this change has an undesired effect for some fields.

Maybe there is cleaner, better way to fix this problem, but I currently not see it.

Status: Needs review » Needs work

The last submitted patch, 11: views_data_export.label-untranslated-1344592-11.patch, failed testing.

MegaChriz’s picture

Okay, label is not always available in the fields' info.

BillyTom’s picture

I've got this issue as well. A fix would be much appreciated.

marktheshark’s picture


This is a great problem for our affiliate sites which choke on the localized labels (actually the label gets the value: 'invalid-tag-name') and we are forced to provide them with a non-localized feed (English), which can be parsed.

smurfxx’s picture

It seems that this bug has not been fixed yet, if I export my view I get labels and fileds translated but the preview is ok.

PascalAnimateur’s picture

899 bytes
PASSED: [[SimpleTest]]: [MySQL] 97 pass(es). View

I can confirm patch #11 fixes the problem in my case, but we shouldn't assume $fields_info[$key]['label'] is set, in which case we should fall back to the default behaviour.

I re-rolled the patch with additional checks...

PascalAnimateur’s picture

Status: Needs work » Needs review
IckZ’s picture

works for me! thx a lot!

klausi’s picture

Status: Needs review » Reviewed & tested by the community

Looks good to me, too.

Steven Jones’s picture

Status: Reviewed & tested by the community » Fixed

Brilliant, thank you!

Status: Fixed » Closed (fixed)

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

adrien.felipe’s picture

Somehow last dev version (7.x-3.x-dev) does not contain patch #11 while flagged as committed.
Was it removed or something went wrong?

Applying #11 does fix the issue.

Steven Jones’s picture


I've pushed an empty commit into 7.x-3.x to see if d.o will re-package with this commit included.

adrien.felipe’s picture

Seems ok now, thanks!

Plazik’s picture

It will work only if "Transform spaces" option is enabled.

minorOffense’s picture

There's a use case that's been broken by this patch which is to actually export labels in specific languages. For example a CSV export with the word "Email" or "Courriel" in en or french.

I think just unilaterally disabling translation of labels is too big of a hammer to use here.

Plus this doesn't actually change all labels from beign translated. If you add labels and they're translated elsewhere they still show up in another language. Only prevents overridden labels from being translated by views.

Instead, there should be an option in the display settings to toggle "Localize labels" or something and actually load the source language values from the translation system.

minorOffense’s picture

Status: Closed (fixed) » Needs work
minorOffense’s picture

Or even arguably you could make the case to toggle the localization on/off per label.

Do these settings in the view have an effect on Views data export?

maddentim’s picture

@minorOffense, I agree with you. I have a client asking for her CSV labels to get translated. I get why you would want to not have the translations typically, but there are use cases where you might want it translated.

I am trying to see how I might be able to undo this commit. Not finding quick success.

Lonnytunes’s picture

Status: Needs work » Needs review
3.98 KB

The previous patch created a regression on my project... It was clearly not a good solution, labels are simply no longer translated.
I submit a new one providing a new option to enable/disable labels translation as proposed by minorOffense.
I chose to enable translation by default because it's probably the most often expected behavior (but this will switch again the behavior and might be consiger as a regression as well).

minorOffense’s picture

I would leave the default behavior the same as it stands to avoid confusion or unexpected changes to people's views. Leave things untranslated by default.

Lonnytunes’s picture

Same patch than in comment #32 but with labels translation disabled by default.

Status: Needs review » Needs work

The last submitted patch, 34: views_data_export-untranslated-labels-1344592-34-D7.patch, failed testing. View results
- codesniffer_fixes.patch Interdiff of automated coding standards fixes only.

Danny.Wouters’s picture

Hi, I have a view with the labels translation disabled. In this view there are fields with a custom labels and fields with the default value (title) of the field.
When I export the view, the labels of the field with a custom value are shown. The labels of the fields with the default value are missing.
I added an extra check on the title definition to the patch from comment #34

dmsmidt’s picture

Title: Labels get translated » (CSV) Export labels not translated
Priority: Normal » Major
Issue summary: View changes
Status: Needs work » Needs review

Since a new issue about the fact that labels don't get translated was marked duplicate I'm changing the title and IS to reflect the current problem.
Marking this as a Major problem, since existing projects got broken by the change.

The last submitted patch, 36: 1344592-36.patch, failed testing. View results
- codesniffer_fixes.patch Interdiff of automated coding standards fixes only.