Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
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().
Comment | File | Size | Author |
---|---|---|---|
#33 | englishdevel.drush_.inc_.txt | 340 bytes | sanduhrs |
#29 | englishdevel.drush_.inc_.txt | 248 bytes | fago |
#26 | overridden_feature.png | 80.47 KB | JesseDP |
#13 | features-locale-874760.patch | 1.02 KB | smk-ka |
#5 | 874760-5-feature_exports_strictly_english.patch | 4.28 KB | xamanu |
Comments
Comment #1
yhahn CreditAttribution: yhahn commentedMore 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.
Comment #2
yhahn CreditAttribution: yhahn commentedReopening.
Comment #3
yhahn CreditAttribution: yhahn commentedAs described by @Kars-T there are a variety of cases where
t()
in exportables can behave in unexpected ways.Some cases to know about
t()
source strings that are not english. @Kars-T describes this issue.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 renderst()
strings again around localized strings e.g.t('Perfil')
. If this gets evalued, e.g. for a diff operation, the evaluation oft()
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:
t()
that can be evaluated. This is the most promising option, and may require only a small change topotx
. Commented out instances oft()
that can still be parsed by string extractors would be a simple, ideal solution.global $language
when doing Features operations. This means either disallowing users to hitadmin/build/features/*
pages in a language other than the site default or trying to hijack and then restoreglobal $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.
Comment #4
xamanu CreditAttribution: xamanu commentedI 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.
Comment #5
xamanu CreditAttribution: xamanu commentedHere comes the patch for Drupal 7 version. It is now only exporting English strings.
Comment #6
skilip CreditAttribution: skilip commentedsubscribe
Comment #7
neurojavi CreditAttribution: neurojavi commentedSubscribe
Comment #8
neurojavi CreditAttribution: neurojavi commentedHi:
Thanks Xamanu, patch #5 works for me.
I think it's a good solution, perhaps it can be committed?
Comment #9
Kars-T CreditAttribution: Kars-T commentedSetting the task to "needs review" so it is not overlooked.
@neurojavi maybe set it to rtbc than?
Comment #10
neurojavi CreditAttribution: neurojavi commentedWell, 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...
Comment #11
neurojavi CreditAttribution: neurojavi commentedops!
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
Comment #12
Cyberwolf CreditAttribution: Cyberwolf commentedSubscribing.
Comment #13
smk-ka CreditAttribution: smk-ka commentedInstead of patching all entry points, why not simply change the language inside the central exporting function, like in the attached patch?
Comment #14
khezer CreditAttribution: khezer commentedSubscribing
Comment #15
zilverdistel CreditAttribution: zilverdistel commentedSubscribing, I'm trying the approach in #13.
Comment #16
febbraro CreditAttribution: febbraro commentedLet me know how #13 goes, I like that approach better than #5.
Comment #17
smk-ka CreditAttribution: smk-ka commentedUnfortunately, #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".
Comment #18
zilverdistel CreditAttribution: zilverdistel commentedThe approach in #13 seems to work, but have to say I haven't tested thoroughly.
Comment #19
zilverdistel CreditAttribution: zilverdistel commented@smk-ka: can you describe the "inconsistent" results?
Comment #20
HnLn CreditAttribution: HnLn commentedsub
Comment #21
neurojavi CreditAttribution: neurojavi commented#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 */
Comment #22
AdamGerthel CreditAttribution: AdamGerthel commentedWe'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.
Comment #23
zilverdistel CreditAttribution: zilverdistel commentedWith 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.Comment #24
BarisW CreditAttribution: BarisW commentedHaving 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.
Comment #25
Johnny vd Laar CreditAttribution: Johnny vd Laar commentedI have the same problem as BarisW but then when I export a feature from the interface.
Comment #26
JesseDP CreditAttribution: JesseDP commentedI'm having the same problem.
Allso my feature keeps being overridden because of this.
Comment #27
fagoThat'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
Comment #28
fagoFor 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)
Comment #29
fagoComment #30
KLicheR CreditAttribution: KLicheR commentedLocale 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.
Comment #31
dynamicdan CreditAttribution: dynamicdan commentedThis 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:
Comment #32
sanduhrsUpdated to use
i18n_string_source_language
, when set.Falls back to
en
.Rename the attached file to
englishdevel.drush.inc
and save tosites/all/drush
.Comment #33
sanduhrsUpdated to use
i18n_string_source_language
, when set.Falls back to
en
.Rename the attached file to
englishdevel.drush.inc
and save tosites/all/drush
.Comment #34
BarisW CreditAttribution: BarisW commentedAn 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.
Comment #35
sanduhrsFor the previous to work you need to enable the
URL
detection method onadmin/config/regional/language/configure
.Comment #36
KLicheR CreditAttribution: KLicheR commentedIf I want to use
drush features-update
or evendrush features-list
, I use a drushrc.php file in my site (sites/my_site/drushrc.php) to force drush to use english for commands.Tested with Drush 5.
Comment #37
dynamicdan CreditAttribution: dynamicdan commentedI 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.
Comment #38
bforchhammer CreditAttribution: bforchhammer commented@KLicheR: awesome, that works perfectly! Thank you very much :)
Comment #39
rudiedirkx CreditAttribution: rudiedirkx commentedI've 'solved' this completely (including Views' comments and weird sometimes-translations) by:
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()
inviews/includes/view.inc
if you want to know why (and have 4 hours too much).Comment #40
rudiedirkx CreditAttribution: rudiedirkx commentedScratch that. Now everything's falling apart somehow and it never switches back to Dutch again... This is so weird! Drupal languages OMG!
Comment #41
marcvangendRe #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.
Comment #42
rudiedirkx CreditAttribution: rudiedirkx commentedMy
hook_language_init()
solution seems to work fine now. You'll need it in both Features and Views, because Views' field edit forms too.Comment #43
kmajzlik CreditAttribution: kmajzlik commentedI was thinking about this last day... My mind?
Create module called like "Set language EN"
and set this language switcher to be first. I think it will be cleaner solution then implementing some language things in Features module.
Comment #44
kmajzlik CreditAttribution: kmajzlik commentedMaybe, better should be name of module admin_language (same like we have admin_menu and admin_theme)
Comment #45
kmajzlik CreditAttribution: kmajzlik commentedOk, there is already https://drupal.org/project/admin_language which can help fix this issue.
Comment #46
HnLn CreditAttribution: HnLn commentedI already made a post in admin_language suggesting #43, as they currently use hook_init: https://drupal.org/node/2059421
Comment #47
kmajzlik CreditAttribution: kmajzlik commentedadmin_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.
Comment #48
rudiedirkx CreditAttribution: rudiedirkx commentedWhat 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.
Comment #49
mpotter CreditAttribution: mpotter commentedI 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.
Comment #50
markus_petrux CreditAttribution: markus_petrux commentedJust 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:
Comment #51
PascalAnimateur CreditAttribution: PascalAnimateur commentedSolution #36 works perfectly with drush in my case, even when english language is disabled (but it should still be installed!).
Comment #52
dawehner#1988252: Use the same language consistently in generated comments and strings seems to be the successor of this particular issue