Features created from the UI have non-english language

Your patch includes a LICENSE file that should not be there.

Also, this needs further investigation. The _features_export_language() is only intended to be used internally when computing the component state. I don't think it was intended to force all exports to be in English. So this will require a lot more input from people in the multi-lingual community to comment and test on this before it gets committed. Given all the side effects of other recent changes for language I am leary about making these kinds of changes at this late stage of development. This change would completely change the current export of features and also likely cause a large number of overrides.

The patch from #6 is working really nice, although I wasn't here because of a language issue. In fact I came here because the drupal_flush_all_caches comes with a massive performance hit when you do a drush feature-update-all on a larger site.

Thanks a lot @axel.rutz for this fix, it saves us tons of hours.

#6 patch works for me.

attached a rerolled patch

Some observations. Not sure if they are blockers.

Nested inception

With this patch, we will have cases with multiple levels of "inception" with _features_export_language().
E.g.
- _drush_features_export() calls _features_export_language() to set the language to English temporarily.
- _drush_features_export() calls features_export_render()
- features_export_render() calls _features_export_language() to (again) set the language to English temporarily.
- features_export_render() calls _features_export_language() to "restore" the language back to English.
- _drush_features_export() calls _features_export_language() to "restore" the language back to what it was before.

I currently don't see a real problem with this, it is just a curious observation.

Static reset when restoring original language?

Currently (incl the patch) the functions that set a new language temporarily call drupal_static_reset() to avoid polluted data.

However, when restoring the original language, I don't see anything being reset. Shouldn't this be the case?

Furthermore, if we do this on every call to _features_export_language(), perhaps it should be part of that function?

try / catch / finally?

If there is an exception while the language is set to English, the restoration of the original language will never happen.
To do this, we would need try/catch/finally, possibly with a re-throw.
Restoring the original language would happen in the finally case.

No more flush caches in drush?

For drush, this patch replaces the drupal_flush_all_caches() with a static reset.

Also changed drush to only reset static cache, not db cache.

What is the implication of this?
Why did we originally clear all caches?
It is great if we don't need to do this anymore, but it would be good to get an idea as to why :)

Also, is this in scope of this issue or should this be a separate issue?

Issue summary

The issue summary is quite short, would be useful to add more info.

Re-roll?

There have been some doc and code style fixes lately, which means this patch no longer applies cleanly.
I suggest to wait at least for #3081268: Non-controversial whitespace code style fixes, before uploading a new patch.

I already tried this patch locally. It applies to an earlier version of 7.x-2.x, and from there I can rebase it cleanly to where I have the local changes. So all is still good.

Progress / perspective:
As @mpotter mentioned, this change might be risky.
I want to at least test this myself, before I commit anything.

I am also thinking of perhaps doing this in 7.x-3.x, and/or we could make it opt-in somehow?
I will think about it :)

Overall I think the idea is good, and @axel.rutz is spot-on in #4.

I remember having this problem myself in the past, where I or a colleague would export a feature in the "wrong" language.

Side effects?

There is a possibility that some teams got used to exporting their features in another language (e.g. French) always.
This is a recipe for disaster, but we should know by now that this does not stop people..

Of course a team which does this would have other problems already:
- They cannot use drush for the export, because drush switches to English always.
- They can't use some other operations which also switch to English always. (not sure which, to be checked).
- Likely problems with t() called with non-English strings.

Changing this behavior now would mean that all of a sudden these features would be exported in English instead.

Inconsistency in existing code

I think there are more places where _features_export_language() should be called, but it is not.

E.g. drush_features_diff() calls features_detect_overrides() which calls features_get_normal().
I don't see _features_export_language() being called anywhere in this chain.

I am sorry, the solution proposed here does not restore consistency drush vs UI.

In drush, the language switch wraps two parts:
- _drush_features_generate_export(), which does all the hook_features_export() pipe stuff.
- features_export_render().

In the UI, with the patch #10, the language switch would only be inside features_export_render().
All the rest would still happen in the currently active language:
- _features_export_build()
- _features_export_generate().

I am not sure atm if this would make a difference.
But we should aim for consistency.

We should also check if other operations suffer from the same problem, e.g. features diff.

Ideally we should add tests..

Affected by the same bug...