Hi

I created a cck field for images and labled it "Bilder" which is german for images. Now I export the feature and the content.inc contains:

  // Translatables
  array(
    t('Bilder'),
  );

t() shouldn't get strings in other language than english or it will mess up the translation table.

features_translatables_export() should check what language is the current global language.
If its other than "english" it should not add the found strings to t().

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

yhahn’s picture

Status: Active » Closed (won't fix)
git add -p

More seriously, yes, this is a problem.

But no, it is not fair to assume that the current global language is the same as the language used in the object being exported. For example, your english-speaking colleague may create a field with the label 'Images' and then you may export it while using the site in german.

The short is that the way Drupal handles translations, especially of user-provided strings, needs a serious overhaul, and until that happens this is going to remain a problem.

yhahn’s picture

Status: Closed (won't fix) » Active

Reopening.

yhahn’s picture

Title: features_translatables_export() should check the current default language. » Features language normalization when processing exports
Category: bug » task
Priority: Normal » Major

As described by @Kars-T there are a variety of cases where t() in exportables can behave in unexpected ways.

Some cases to know about

  • Object's properties (name, description, etc) are not in english. Export contains t() source strings that are not english. @Kars-T describes this issue.
  • An administrator hits admin/build/features or related page on a multilingual site and not in english. In order to retrieve the state of a component, Features "re-exports" the normal object which has been localized and renders t() strings again around localized strings e.g. t('Perfil'). If this gets evalued, e.g. for a diff operation, the evaluation of t() will pollute the locale sources table.

Both of these are very bad behaviors that we should address -- however, they may require serious changes to how Features handles translatables and localization. Some options discussed:

  1. Move away from instances of t() that can be evaluated. This is the most promising option, and may require only a small change to potx. Commented out instances of t() that can still be parsed by string extractors would be a simple, ideal solution.
  2. Attempt to manage global $language when doing Features operations. This means either disallowing users to hit admin/build/features/* pages in a language other than the site default or trying to hijack and then restore global $language in the middle of a page load. None of these options look very attractive.

We'll keep track of this issue here... expect movement on this after Features goes 1.0 stable.

xamanu’s picture

Version: 6.x-1.0-beta11 » 7.x-1.x-dev

I wrote a little module, using @yhahn second option as the approach. It is available in my sandbox which should work (drupal 6): http://drupal.org/sandbox/xamanu/1161994

But anyway IMHO this should be "fixed" within Features itself. At least as an option on export. Which could be a checkbox on the UI (Create feature in English language) and an argument on the drush features-* commands (f.e. drush features-update --language=en YOURFEATURE).

I'm willing to write a patch. But I want to know before the maintainer's opinion on that.

xamanu’s picture

Here comes the patch for Drupal 7 version. It is now only exporting English strings.

skilip’s picture

subscribe

neurojavi’s picture

Subscribe

neurojavi’s picture

Hi:

Thanks Xamanu, patch #5 works for me.
I think it's a good solution, perhaps it can be committed?

Kars-T’s picture

Status: Active » Needs review

Setting the task to "needs review" so it is not overlooked.

@neurojavi maybe set it to rtbc than?

neurojavi’s picture

Status: Needs review » Reviewed & tested by the community

Well, it works for me, so I think we can set it to RTBC.
Perhaps patch needs to be update to las dev. It works but gives some offset warnings that make it fail in drush make files...
I'll try to update it if Xamanu doesn't do it...

neurojavi’s picture

Status: Reviewed & tested by the community » Needs work

ops!
Sorry, I've tested the patch with a previous dev version. It fails with last dev... Perhaps Xamanu can reroll the patch?

Changing to needs work

Cyberwolf’s picture

Subscribing.

smk-ka’s picture

Status: Needs work » Needs review
FileSize
1.02 KB

Instead of patching all entry points, why not simply change the language inside the central exporting function, like in the attached patch?

khezer’s picture

Subscribing

zilverdistel’s picture

Subscribing, I'm trying the approach in #13.

febbraro’s picture

Let me know how #13 goes, I like that approach better than #5.

smk-ka’s picture

Status: Needs review » Needs work

Unfortunately, #13 has its quirks, as some item translations seem to be already statically cached - for example, content types, but also exported Views showed inconsistent results. However, it *should* be possible to overcome those, therefore "needs work".

zilverdistel’s picture

The approach in #13 seems to work, but have to say I haven't tested thoroughly.

zilverdistel’s picture

@smk-ka: can you describe the "inconsistent" results?

HnLn’s picture

sub

neurojavi’s picture

#13 is working for me.

I don't know if it has something to do but I get some automatic comments in exported views in spanish and not in english, as expected.

- /* Sort criterion: Content: Title */
+ /* Criterio de ordenación: Contenido: Título */

AdamGerthel’s picture

We're having the same issues as mentioned in #21

When we build multi-language sites as well as single language we always prefer to code and develop in English. This is because we are a lot more comfortable developing in english, and using the UI in english, rather than our native language (swedish). At the end of a site development phase, we add Swedish (if it's single language site) and set it as default, but keep english as the language of origin (and admin language).

This works well using the UI to export features, but Drush uses the default language. It all becomes a mess with commits in our repos containing nothing but translated views comments.

zilverdistel’s picture

With the patch in #13:

When I set a default language other than english, drush fd myfeature shows overrides in that default language. However, drush fu myfeature works as expected, the non-english string is not included in my feature.

BarisW’s picture

Having the same issue. My default language is Dutch. When I export the feature using drush, I see Dutch comments in my features (.views-default.inc). However, when I switch the site to english and create the feature via the interface, all works fine.

This prevents me from using Drush to update my features. Would be nice to have this working though.

By the way: I've tested both patches and neither solve the issue.

Johnny vd Laar’s picture

I have the same problem as BarisW but then when I export a feature from the interface.

JesseDP’s picture

FileSize
80.47 KB

I'm having the same problem.

Allso my feature keeps being overridden because of this.

fago’s picture

That's still a problem - as of now it's not possible to create a regular English feature on a site with a non-English default language, e.g. Views exports are broken. Features should have an option which allows setting the default language used when processing exports. E.g. see http://drupal.org/sandbox/xamanu/1161994

fago’s picture

For the meanwhile, I've create a custom command file which ensure drush is always running in English. Sof if a site is developed in English, just place the file in sites/all/drush. (no module needed)

fago’s picture

FileSize
248 bytes
KLicheR’s picture

Locale can determine what is the Default language.
i18n can determine the Source language (/admin/config/regional/i18n/strings), which should be use, when available, to determine in which language the features should be export.

Usage context

My website, for example, has to be bilingual (french and english).
The Default language is french (most people talk french here) and the Source language is english, to be able to create, for example, taxonomy in english and translate it with a french .po file.

All components of my features has to be in english and are traslate with french .po file (cause an english .po file can cause you alot of headaches). So if Features would take the Source language for export, it would be more logic.

dynamicdan’s picture

This is also affecting image style exports. I don't even have the option to clear the 'help' text from an image style :(

My user has English set. The site is in German. It's easier to find where drupal errors come from when they are not translated.

From profile_setup.features.inc:

/**
 * Implements hook_image_default_styles().
 */
function profile_setup_image_default_styles() {
  $styles = array();

  // Exported image style: 280x230.
  $styles['280x230'] = array(
    'name' => '280x230',
    'effects' => array(
      2 => array(
        'label' => 'Skalierung',
        'help' => 'Scaling will maintain the aspect-ratio of the original image. If only a single dimension is specified, the other dimension will be calculated.',
        'effect callback' => 'image_scale_effect',
        'dimensions callback' => 'image_scale_dimensions',
        'form callback' => 'image_scale_form',
        'summary theme' => 'image_scale_summary',
        'module' => 'image',
        'name' => 'image_scale',
        'data' => array(
          'width' => '280',
          'height' => '230',
          'upscale' => 0,
        ),
        'weight' => '1',
      ),
    ),
  );

  // Exported image style: 800x600.
  $styles['800x600'] = array(
    'name' => '800x600',
    'effects' => array(
      1 => array(
        'label' => 'Skalierung',
        'help' => 'Eine Skalierung behält das Seitenverhältnis des Originalbildes bei. Sofern nur eine Seitenlänge angegeben ist, wird die andere berechnet.',
        'effect callback' => 'image_scale_effect',
        'dimensions callback' => 'image_scale_dimensions',
        'form callback' => 'image_scale_form',
        'summary theme' => 'image_scale_summary',
        'module' => 'image',
        'name' => 'image_scale',
        'data' => array(
          'width' => '800',
          'height' => '600',
          'upscale' => 0,
        ),
        'weight' => '1',
      ),
    ),
  );

  return $styles;
}
sanduhrs’s picture

Updated to use i18n_string_source_language, when set.
Falls back to en.

Rename the attached file to englishdevel.drush.inc and save to sites/all/drush.

sanduhrs’s picture

FileSize
340 bytes

Updated to use i18n_string_source_language, when set.
Falls back to en.

Rename the attached file to englishdevel.drush.inc and save to sites/all/drush.

BarisW’s picture

An in-between solution is to add a Redirect to your virtual host on the dev environment.

RedirectMatch ^/admin/structure/features/(.*)$ /en/admin/structure/features/$1

This makes sure that every time you access the features interface, you get redirected to /en.

sanduhrs’s picture

For the previous to work you need to enable the URL detection method on admin/config/regional/language/configure.

KLicheR’s picture

If I want to use drush features-update or even drush features-list, I use a drushrc.php file in my site (sites/my_site/drushrc.php) to force drush to use english for commands.

$options['variables']['language_default'] = (object) array(
  'language' => 'en',
  'name' => 'English',
  'native' => 'English',
  'direction' => '0',
  'enabled' => '1',
  'prefix' => 'en',
);

Tested with Drush 5.

dynamicdan’s picture

I also came to this solution..

Our site is in DE and I've set the DE prefix to '' and EN to 'en'. I export features in the DE language and when I need to test in EN I just add the prefix to the url like /en/some-page-with-an-error

A better solution is required.

bforchhammer’s picture

@KLicheR: awesome, that works perfectly! Thank you very much :)

rudiedirkx’s picture

I've 'solved' this completely (including Views' comments and weird sometimes-translations) by:

/**
 * Implements hook_language_init().
 */
function YOURMODULE_language_init() {
  global $language;
  if (arg(0) == 'admin' && arg(1) == 'structure' && (arg(2) == 'features' || arg(2) == 'views')) {
    $language->language = 'en';
  }
}

When I implemented hook_init() like this, I was too late, because the menu system calls access callbacks, which call export functions which do all kinds of unfathomable stuff. I don't mind my interface being English on Views UI en Features UI. Only admins use it. I understand this is NOT an acceptable solution, but the problem is much bigger than just Features. For one it's Views and CTools. See
view::views_object_types() in views/includes/view.inc if you want to know why (and have 4 hours too much).

rudiedirkx’s picture

Scratch that. Now everything's falling apart somehow and it never switches back to Dutch again... This is so weird! Drupal languages OMG!

marcvangend’s picture

Re #34:
Here is the .htaccess rewrite I use. Besides redirecting the features page to english, it also makes sure that you are sent back from english to the default language on all other pages. Obviously this is only useful on single-language sites.

  # Force /admin/structure/features/* to run in English to prevent translation
  # problems when working with features.
  RewriteCond %{REQUEST_URI} ^/admin/structure/features(.*)$ [NC]
  RewriteRule ^ /en/admin/structure/features%1 [L,R=302]
  # In other cases, return to the default language if needed.
  RewriteCond %{REQUEST_URI} !^/en/admin/structure/features [NC]
  RewriteCond %{REQUEST_URI} ^/en(/(.*))?$ [NC]
  RewriteRule ^ /%2 [L,R=302]
rudiedirkx’s picture

My hook_language_init() solution seems to work fine now. You'll need it in both Features and Views, because Views' field edit forms too.

kmajzlik’s picture

I was thinking about this last day... My mind?
Create module called like "Set language EN"

/**
 * Implements hook_language_negotiation_info()
 */
function set_language_en_language_negotiation_info() {
  return array(
    'set_language_en_language_provider' => array(
      'callbacks' => array(
        'language' => 'set_language_en_callback',
      ),
      'file' => drupal_get_path('module', 'set_language_en') . '/set_language_en.module',
      'weight' => -99,
      'name' => t('Set language EN'),
      'description' => t('Set language to english for custom sites.'),
    ),
  );
}

/**
 * Custom callback for setting up language
 */
function set_language_en_callback($languages) {
  if (arg(0) == 'admin' && arg(1) == 'structure' && (arg(2) == 'features' || arg(2) == 'views')) {
    $lang = 'en';
  }
  /* TODO: create admin page and use variable for custom paths like admin_theme does */

  return $lang;
}

and set this language switcher to be first. I think it will be cleaner solution then implementing some language things in Features module.

kmajzlik’s picture

Maybe, better should be name of module admin_language (same like we have admin_menu and admin_theme)

kmajzlik’s picture

Ok, there is already https://drupal.org/project/admin_language which can help fix this issue.

HnLn’s picture

I already made a post in admin_language suggesting #43, as they currently use hook_init: https://drupal.org/node/2059421

kmajzlik’s picture

admin_language does NOT work properly for our needs. For example: adding new action to image style starts with my frontend language. I am searching and testing my solution now.

rudiedirkx’s picture

What I do at work is create a language negotiation that sets language to EN for user # 1. Enable and drag to the top. Everything root does is now EN. All other users have normal language negotiation.

Still doesn't work for drush well enough though, since drush runs as anonymous.

Everything else about admin_language should be in the admin_language queue.

mpotter’s picture

Status: Needs work » Closed (won't fix)

I am not seeing any patch for Features 2.x in this, so closing this issue in Features. If it's still an issue Features needs to solve, please post an updated patch.

markus_petrux’s picture

Issue summary: View changes

Just posting to share idea...

I'm trying an approach similar to #43, but using a hook alter of the original url rewriting callback.

In a custom module, this:

/**
 * Implements hook_language_negotiation_info_alter().
 *
 * Make sure Features UI is in english while keeping the rest of the admin UI
 * in default language.
 *
 * Alternativelly, the admin_language could be another possibility.
 *
 * @link https://www.drupal.org/project/admin_language
 * @link https://www.drupal.org/node/874760
 *
 * @see MODULE_language_url_rewrite_url()
 */
function MODULE_language_negotiation_info_alter(&$negotiation_info) {
  $negotiation_info[LOCALE_LANGUAGE_NEGOTIATION_URL]['callbacks']['url_rewrite'] = 'MODULE_language_url_rewrite_url';
}

/**
 * Rewrite URLs for the URL language provider.
 *
 * @see MODULE_language_negotiation_info_alter()
 */
function MODULE_language_url_rewrite_url(&$path, &$options) {
  locale_language_url_rewrite_url($path, $options);
  if (variable_get('locale_language_negotiation_url_part', LOCALE_LANGUAGE_NEGOTIATION_URL_PREFIX) == LOCALE_LANGUAGE_NEGOTIATION_URL_PREFIX) {
    if (!empty($options['prefix'])) {
      if (preg_match('`^admin/structure/features.*$`', $path)) {
        $options['prefix'] = 'en/';
      }
      elseif (preg_match('`^admin/structure/features.*$`', $_GET['q'])) {
        // Keep the the rest of the Admin UI with default language.
        // @todo works for me, but surelly could be improved somehow...
        $language_default = language_default();
        if ($language_default->language != 'en') {
          $options['prefix'] = $language_default->language . '/';
        }
      }
    }
  }
}
PascalAnimateur’s picture

Solution #36 works perfectly with drush in my case, even when english language is disabled (but it should still be installed!).

dawehner’s picture