If you export a view in code through features and then revert it so that it only lives in code the translation system no longer works. This is an issue when doing releases with features.

Steps to reproduce:

  1. Create a view with a header text
  2. Translate the header text
  3. Check that it shown translated
  4. Make a feature with the view in it.
  5. Revert the view
  6. Text is no longer translated

If afterwards you just edit the view and save it everything works again. Attached the difference between a code only view and one that is saved.

views-issue.diff2.88 KBJax


Jax’s picture

Apparently this code is responsible for that:

   * Determine whether a view supports admin string translation.
function is_translatable() {
// If the view is normal or overridden, use admin string translation.
    // A newly created view won't have a type. Accept this.
return (!isset($this->type) || in_array($this->type, array(t('Normal'), t('Overridden')))) ? TRUE : FALSE;

A reverted view has a type of Default.

Jax’s picture

netsensei’s picture

Issue summary:View changes


I have a NL (Dutch)/EN translated Drupal installation with i18n_views and I have a few views exported in a feature using i18n_views exposed filter handlers with translated/translatable filter labels. After translating those labels, the view is shown as "overridden", the dutch strings for the labels are shown for "Normal" but I can't revert the view.

Looking at the code above: this happens to me now.

- $this->type resolves to 'Standaard' which is the dutch translation of 'Default' or 'Normal'
- t('Normal') was translated via the translate interface to 'Normaal'

Obviously the check above would return a FALSE because we've mucked the labels.

Translating 'Normal' to 'Standaard' and magically, my feature isn't shown as overridden anymore.

I double checked the exported code in the feature and the view stored in the db => both contain the same, english strings for the labels. By all rights, the view shouldn't be shown as "Overridden"