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:

<?php
 
// 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().

Comments

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.

Status:Closed (won't fix)» Active

Reopening.

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.

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.

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

subscribe

Subscribe

Hi:

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

Status:Active» Needs review

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

@neurojavi maybe set it to rtbc than?

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...

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

Subscribing.

Status:Needs work» Needs review
StatusFileSize
new1.02 KB

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

Subscribing

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

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

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".

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

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

sub

#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 */

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.

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.

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.

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

StatusFileSize
new80.47 KB

I'm having the same problem.

Allso my feature keeps being overridden because of this.

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

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)

StatusFileSize
new248 bytes

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.

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:

<?php
/**
* 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;
}
?>

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.

StatusFileSize
new340 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.

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.

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

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.

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

Tested with Drush 5.

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.

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

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).

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

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]

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.

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

<?php
/**
* 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.

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

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

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

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.

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.

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.