Views strings not translatable when loaded from a feature

This is the intended behavior.

Default views are assumed to be provided by modules and are thus considered normal interface strings and are translated via t(). Without this behavior, default views provided by modules can't be shipped with translations. When you turn a view into a feature, you need to translate it through the normal interface, not the i18n strings interface.

Wouldn't it be possible to make this an option? To be able to choose if the exported view is run through t() or i18n_strings? Because when building the site the view usually lives in the DB and then everything is translated and it's only when everything is done that it goes to code?

Moreover the great thing about i18n_string is that translations are not lost when changing the source string! So if you have a feature with a views and a string changes (for example you use a synonym which means the translations are still valid) then you have to provide new translations in the update as well...

Also, this causes issues with string extraction, because the templates that get extracted assume that they will be applied via i18n_strings, when in fact if they are translated that way they won't apply to a default view with t(). So you'll extract a po file for translation, and when you import the translated files they won't actually apply.

I understand the rationale for this, but it does seem like there should be some kind of option here. For now I'm planning on maintaining a local patch to views to always return true for is_translatable, because all of our views need to be translated this way.

Here is a small patch to make this configurable, allowing exported views to use the same translation method as "normal" or "overridden" views.

The option can be found under: /admin/structure/views/settings/advanced

Please test.

Updating category since this is not a bug.

The additional option did the trick for me. +1 to #5.

This appears to be working for us.

I think the workflow of starting in configuration and moving to a feature is pretty common.

Another argument for having this facility is that even if you do potx import or migrate all your translations to use built-in string translation, you can no longer easily override a view since that will break all the translations.

I do agree that in a world with features you want to be able to use i18n based translation if possible for things which changes quite often, like exported views.

+    // Use translation no matter what type of view.

Can we expand that comment to mention that we want to be able to use the localization plugin. Translation could be slightly misread here.

Isn't there a way for us to set this to TRUE by default instead, while still allowing for modules ship with translations?

#10: patch contains a typo: #description line should end with a comma.

@all: I stumbled on this with probably an equal use-case: deploying Views with Features and translating those Views with i18nviews.

The above patch is critical for it, but it doesn't do enough...

When we looked deeper in the translation behaviour of Views + Internationalization Views + Features, one thing came up quite surprisingly:
default values are not translated!

It means that if you create a View with original field-labels or pager texts ("next ›"), then export it to Features and then reset them to the code-state, you have a problem.
This gets very obvious when you enable i18n_string_debug ($ drush vset i18n_string_debug TRUE).
The 'default' values + debug-info won't show up when rendering your view. It does show up as translatable under /admin/config/regional/translate/translate . That makes it only more confusing.
But non-default values (an overridden field-label) do show up (only with patches from this issue!)

The reason that non-default values of a 'default state' View won't get translated is that those values are not exported to code and/or not available when i18n kicks in.
In Drupal 8 this problem is solved by just exporting default values to code (see https://www.drupal.org/node/1938654).
To me, that seems a good solution for 7.x too.

So there are 2 problems regarding Views + i18nviews + Features where the source is in Views:

1. A View-object that is in 'default' state is marked as 'not translatable'. That issue is fixed with patches #10 and #5.
2. Elements of a View-object that have a 'default' state (pager-link, field-label, ...) are not exported to code.

So I updated patch #10:

• Option_definitions of all plugins/handlers that are "Translatable" got an extra property "export" => "export_option_always".

Note:

• If you feel I am hijacking this topic I can open a new issue. But I put it here because it feels like the same problem at the end.

@ndf: It's actually i18n_views causing strings to not get exported with views - #2245917: Exported views do not include t() translatables

@milesw #12: that patch adds the translatables perfectly to the t() function, but that does not trigger i18n_string.
To trigger i18n_string the translatable (a field-label) must be part of the export.

So something like:

/* Field: Content: Title */
  $handler->display->display_options['fields']['title_field']['id'] = 'title_field';
  $handler->display->display_options['fields']['title_field']['table'] = 'field_data_title_field';
  $handler->display->display_options['fields']['title_field']['field'] = 'title_field';

Should be like:

/* Field: Content: Title */
  $handler->display->display_options['fields']['title_field']['id'] = 'title_field';
  $handler->display->display_options['fields']['title_field']['table'] = 'field_data_title_field';
  $handler->display->display_options['fields']['title_field']['field'] = 'title_field';
  $handler->display->display_options['fields']['title_field']['label'] = 'Title';

to trigger i18n_string.

Note: that if you change the default label to something different it will be exported without patching.

patch #11 does export it like this:

/* Field: Content: Title */
  $handler->display->display_options['fields']['title_field']['id'] = 'title_field';
  $handler->display->display_options['fields']['title_field']['table'] = 'field_data_title_field';
  $handler->display->display_options['fields']['title_field']['field'] = 'title_field';
  $handler->display->display_options['fields']['title_field']['label'] = 'Title';
  $handler->display->display_options['fields']['title_field']['alter']['text'] = '';
  $handler->display->display_options['fields']['title_field']['alter']['alt'] = '';
  $handler->display->display_options['fields']['title_field']['alter']['prefix'] = '';
  $handler->display->display_options['fields']['title_field']['alter']['suffix'] = '';
  $handler->display->display_options['fields']['title_field']['alter']['more_link_text'] = '';
  $handler->display->display_options['fields']['title_field']['empty'] = '';

ndf said in #11:

If you feel I am hijacking this topic I can open a new issue. But I put it here because it feels like the same problem at the end.

I wouldn't call it hijacking, but please let us get this in first and the solve the much more complex issue of #11 in a followup.

I'm setting #5 RTBC as of #7.
(Implicitly deciding to reject #10 as this might break existing sites.)

(Implicitly deciding to reject #10 as this might break existing sites.)

Oh yes!

Committed #5 and pushed!

Oh what a bliss when the pain stops. Thanks ya all!

Good its in!

HI all,

I see the same problem with the context I mean when I export page manager with features the strings are not translatable.
is there any solutions?
thanks
A