Problem with i18n_string + features + sites with different default language

Question

(I will talk about i18nviews in this question, but I think the problem applies equally to other cases of i18n_string)

Background

With regular Drupal t(), Drupal will always assume that the original string is in English.

With i18n_string, it is assumed that the original string is in the site default language.

Use case / problem

I have multisite with two sites, one with default language German, another with default language English.

I created a page view on the German site, with a page title "Produkte finden".

I exported this view as a feature, and want to enable this feature on the English site. On the English site, the page title should be "Find products".

I thought I can use i18nviews (which uses i18n_string) to translate the page title configured in the view.

However:

• In the German site, Drupal thinks that the exported page title is in German.
• In the English site, Drupal thinks that the exported page title is in English.

This means that Drupal will never attempt to translate the views page title. So I would get the same, non-localized page title on each site.

Question

I want to find a way to export a view into a feature that can be installed on sites with different default language, and have localized labels on each site.

If this can be done with i18n_string, great. If not, I am open for other suggestions.

Thoughts

I think to make this work, the exported feature would have to contain information about the language with which it was exported, which could then be picked up by i18n_string (which I assume it is not really capable of atm).

Or all sites would need to have default language = English.

Answer 1

My solution:

• Do not enable i18nviews.
• Create all views with English strings.
• Use the core translation system to translate all those strings.
• Optionally, use features_translations to export translations.

I do not claim that this solution works for all cases where i18n_string assumed source language causes trouble. But in this case it seems to be sufficient.