Field labels are being translated resulting in different keys

I'm having the same issue. I'm using Chinese Simplified as the default language, so that the site admin can maintain the contents in chinese. You can find the lines(actually they are unicode in json output) which should be field labels in the attached screenshot. For those field labels which have not been translated, they seem OK.

I also find a workaround, when you set an alias for the label with an unique alphabet string the output will be correct. e.g: "view3_title", this will be ok for service output in XML or json. Might because it has no translation string yet.

Anyway, this is a huge problem for most asian languages.

thanks in advance for any patch or quick fix.

I have committed attached patch as proposed by Berdir ($view->localization_plugin = views_get_plugin('localization', 'none');). It should solve the issue.

Please, commit the patch in last beta or in -dev.

Edit: Ops, is already committed in dev, sorry :)

I have that problem back on 7.x-1.0, despite the line 121

$view->localization_plugin = views_get_plugin('localization', 'none');

my fields labels are always translated.

Any clue?

I am also getting this problem despite this supposed fix. It appears to always happen when view is in default state. Also I found an issue with a possible fix #1344592: (CSV) Export labels not translated, but that would not fix it for other style plugins, and it doesn't look like the fix is ready yet.

This problem reoccured for me today. Is it still an issue? The Label for Image field got translated to Swedish, Danish, Norwegian, Finnish.
Quick-fix, removed translations of "Image" from Drupal altogether.

Services: 7.x-3.12
Services Views: 7.x-1.1
Views: 7.x-3.11

I've the same problem with field image, it is translated to imagen.

Bug still active in 7.x-1.1

Experiencing same problem an API or WEBSERVICE must be based on keys and not on traslatable entities. This is a major bug from my point of view. What mantainers think about that since this issue is open from 3 years? we need to consider this module unmaintained?

This one just hosed our production site. :(

I have encountered this issue too. The only viable approach I can think of is the one outlined in #6 and on the related issue over at https://www.drupal.org/node/1344592. The approach I've taken in this patch is to load the field info array from the view itself ($view->display_handler->get_option('fields')) which will contain labels in the source language. In the event that the field has not had a custom label applied to it the fallback is to use the label() function on the field itself.

It is not ideal by any means; as pointed out in the related issue this is a heavy handed solution and removes any ability to translate the field keys. Also if you have a field with no custom label, but the same string is translated elsewhere without context, the translation can still be output in the label in services views.

Anyway it's a start.

Small update to my previous patch. I spotted an issue where if a view was defined with fields that have empty labels it would cause a fatal error when accessing that view over services.

See the updated patch.

It seems like problem was solved once in services_views_execute_view() by setting localization plugin:

  // Avoid translation of the field labels.
  $view->localization_plugin = views_get_plugin('localization', 'none');

So I copied same code to services_views_retrieve(). It seems to work as expected.

Bug still active in 7.x-1.3

Then review the patch. You are misusing issue status.

I have the same issue in 7.x-1.3.

The key I used "language" was translated into Chinese as "語言".

This worked for me.