Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Hello, I'm using French as Defaut language and I can't translate string in english. I don't have the englsih prefix appears in /admin/build/translate/search, so I can't translate in English...
In the documentation, it said:
"If the default is other than English you will be able to import/export English translations too using the localization interface."
but I export english translation and import it, but still nothing.
How can I do to make the english translation appears in string translation?
Comments
Comment #1
Junro CreditAttribution: Junro commentedHello,
no solutions?
Comment #2
Buntstich CreditAttribution: Buntstich commentedHello Junro,
this is a little error of this module, if you have another default language as english.
Sorry, no solution yet.
I am also looking for the right workflow on a clean installation.
Comment #3
Junro CreditAttribution: Junro commentedHello buntstich,
It's what I was thinking... no solutions... I'm so desperate lol
In fact, I don't need French as defaut language... so I can set english as defaut language. And I could change all defaut strings to english.
The probleme is my site is nearly finished and I read in book page that change defaut language could cause big trouble...
SO what do you think about it? Could I change my defaut language to English?
What king of problems could I have?
Thanks a lot for your support :)
Comment #4
Buntstich CreditAttribution: Buntstich commentedKing of problems ;-)
you can create a testsite, use your DB backup and check it out, refresh strings on the language page. The bigger Problem is, if your site in google index or not — it break incomming links (on smaller site you can use this http://drupal.org/project/path_redirect ).
I take some test on a new site with different Language standard and negotiation:
Path prefix only: your original domain looks better (example.fr and example.fr/en)
Path prefix with language fallback: double domain looks bad (example.fr/fr and example.fr/en)
Domain name only: on multistite, you have no browser language auto detection.
Ok maybee you find a solution for any problem. I think the best way is english as standard and Path prefix with language fallback.
So it works fine without hazzle.
Comment #5
Junro CreditAttribution: Junro commentedok, thanks.
But i've got a solution:
You could create a new language translation: English 2 (or English bis, super English whatever lol). It will be English translation for site with non-english defaut language.
It could works.
It could works? :)
Comment #6
Buntstich CreditAttribution: Buntstich commentedYes, it`s a dirty Hack!
1. This give you a wrong Language code for english, may be you change from en to en-us. Most users have „en“ as default language in their browser preferences, please take your own test — http://drupal.org/node/376223.
2. More important is the language code in the source of your site for google (Ok, it`s also english).
3. If you disable the default english, it dosent work on content translation and make translators worry.
Comment #7
Junro CreditAttribution: Junro commentedok, it's not a good solution :)
Comment #8
manveru CreditAttribution: manveru commentedI have a real mess in my translation of content type. I've added couple new modules after I've change default language to Polish. The original English texts become put into Polish language in the strings tables. That is really stupid thing, as there is no easy way to mark such translation back to English. Could anyone solve this?
Comment #9
Junro CreditAttribution: Junro commentedWhy do you change defaut language to Polish? The only reason is your site is only in Polish language...
Otherwise, keep english as defaut value.
It's a very frustrating bug, and there are no solutions yet. You have to keep English as defaut language.
Comment #10
Junro CreditAttribution: Junro commentedHello, some news about this desperate problem?
Any solutions in sight? Working on it? Just to know if have to deal with it, or hoping some fixe ^^.
Comment #11
geodaniel CreditAttribution: geodaniel commentedThe issue I've just created is related to this: #422610: Foreign language strings get added to database as source strings, though perhaps not an exact duplicate.
Comment #12
Junro CreditAttribution: Junro commentedMaybe.
@buntstich
Still work on this? Always no solutions??
Comment #13
Jose Reyero CreditAttribution: Jose Reyero commentedAbout user defined strings, http://drupal.org/node/313293
It works as explained there.
Comment #14
ilw CreditAttribution: ilw commentedi'm waiting also for solution.
Comment #15
boazr CreditAttribution: boazr commentedSame here. I started a site in Hebrew as only langauge, and had to add others (English and French). Took me awhile to find where to add /en as a prefix, but now, t() strings in hebrew, can't get translated to english. Hopefully I dont have much Views to fix. But this is not a little problem, and should be addressed in official code.
Comment #16
Junro CreditAttribution: Junro commentedNo solutions, You have to use English as default language.
Comment #17
asak CreditAttribution: asak commentedInteresting.
It may sound like a bug - but i can understand the trouble in this.
I'm not sure if this clarifies as a bug (or a re-coding feature request).
It should however be better noted to users. much better.
Comment #18
Junro CreditAttribution: Junro commented"It should however be better noted to users. much better."
Totally agree with you!
Comment #19
mansspams CreditAttribution: mansspams commentedsubscribing and asking to see discussion here http://groups.drupal.org/node/24438
Comment #20
dan.hu CreditAttribution: dan.hu commented"When translating user-defined strings, the source string is stored using the site default language instead of English" - I think this is the key problem.
The source string should be a KEY in the database and should not be changing all the time. Definitely, it's a design drawback. The user can't be forbidden to change the default language - that's a very common need.
Comment #21
dan.hu CreditAttribution: dan.hu commentedhey, guys. i just came up with a solution to this problem. which is:
1. at /admin/settings/language/, keep the default language to English.
2. edit the language "English". leave empty for path prefix and enter "http://en.you-domain.com" for the language domain.
3. edit the language that you wish to set to default. leave empty for path prefix and enter "http://www.your-domain.com" for the language domain.
4. at /admin/settings/language/configure, choose "Domain only" for language negotiation.
now when the user visits http://www.your-domain.com, your preferred language will show up and English is still the "default" language.
Comment #22
dariogcode CreditAttribution: dariogcode commentedGood solutions. But i have problem with "www", because if I enter in admin/settings/language/edit/{es} url with "www" it work only if the user enter with www, but url like http://mydomain.com not work, it show default language. And also, if I enter http://mydomain.com in settings, www.mydomain.com is showing default language (english). Any ideas?
Comment #23
dariogcode CreditAttribution: dariogcode commentedI fixed it select my other language as default, i18n continue working because negotiate only with domains. Thanks!!!
Comment #24
quazardous CreditAttribution: quazardous commentedin fact it's a lot easier to allow editing all locale_target just by removing the language clause in the locale_translate_edit_form() that filter the default language.
// Fetch translations and fill in default values in the form.
//$result = db_query("SELECT DISTINCT translation, language FROM {locales_target} WHERE lid = %d AND language != '%s'", $lid, $omit);
$result = db_query("SELECT DISTINCT translation, language FROM {locales_target} WHERE lid = %d", $lid);
while ($translation = db_fetch_object($result)) {
$form['translations'][$translation->language]['#default_value'] = $translation->translation;
}
so you can edit all the target translations you need even a non english default one ;p
Comment #25
micheleannj CreditAttribution: micheleannj commentedsubscribing.
This issue needs to be clearly documented at the very least! I assumed I could have a French site with (optional) English translations but this totally isn't the case.
Comment #26
reydempto CreditAttribution: reydempto commented#21 fixed this problem for me. Well it's more like a duct tape solution, but it works for me :)
Comment #27
knalstaaf CreditAttribution: knalstaaf commentedSubscribing (proposed solutions are not working in my case)
Comment #28
knalstaaf CreditAttribution: knalstaaf commentedI've tried all the thinkable options at this moment (my default language being Dutch from the very start).
After every single proposed method I followed the standard procedure of
All with no result.
This is a critical issue that can't be minimalized. Precautions should at least be thoroughly mentionned in all related documentation.
Comment #29
knalstaaf CreditAttribution: knalstaaf commentedLooks like switching the default language to English (with language fallback) and re-creating the strings is the only solution so far indeed. It's giving me the shivers though, but I guess we'll be alright :)
Comment #30
quazardous CreditAttribution: quazardous commentedWhen i had to upgrade to 6.22 I had to repatch the inc/locale.inc and I ve found out that #24 was not enough...
What I did was :
and line 2300 :
Comment #31
nikosnikos CreditAttribution: nikosnikos commentedThanks #30 worked perfectly for me.
But my english translations didn't appeared in the interface of my web site. I had to modify includes/common.inc file at line 919 :
Comment #32
lowfour CreditAttribution: lowfour commented#30 & #31 you are geniuses. Now both the swedish (default) and english string fields appear when I search with Translate Interface. But when I add the strings still nothing happens and my block titles don't show the right language. Straaaaaange.
In fact, when I save a new string for english the process seems to be ok, but then when I search for that string again the english one still appears blank.
EDIT: I was wrong, I had made a mistake and commented the wrong line in common.inc. Works like a charm! REALLY BIG THANKS!
Comment #33
Jose Reyero CreditAttribution: Jose Reyero commentedThough you may consider the default language issue an ugly hack -which it is-, it is the best solution we've found so far and the module works just as expected.
So please don't mark it as 'bug' just becuse it doesn't fit your needs. I works as it is supposed to work. Then of course you can discuss here as many other ugly hacks as you want.
Comment #34
quazardous CreditAttribution: quazardous commented#33 sorry but IT IS A BUG cause some file uses hard coded 'en' language as default and others use the user defined default language so THERE IS A PROBLEM OF CONCEPTION HERE.
Comment #35
Jose Reyero CreditAttribution: Jose Reyero commentedYes, so we have a site default language and a source language that may not be the same. So what?
Comment #36
lucuhb CreditAttribution: lucuhb commentedMy site has 2 languages (french and english), with french as default language and no prefix, and prefix 'en' for english.
I tried the #24, #30 and #31 : when I search the cck label to translate in admin/build/translate/search , english and french are now displayed in the results table, and I can edit the english translation but this is not taken into account when I see the content with this label.
In this results table, with or without the previous patchs, I remark that the fields for which the translation does not work are not classified, for the "Text group" column, in "CCK" but in "User interface". In addition, in the "String" column, I have
while for the others cck label for which translation works I see something like
So the label that I would like to translate seems not be considered as a ckk label (but it is really one!), and perhaps it is why I can not translate it. Has somebody a solution ?
Comment #37
Jose Reyero CreditAttribution: Jose Reyero commentedOpen too long, no follow-up nor patch.
Really, consider using Drupal 7 version.