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

Junro’s picture

Category: feature » support

Hello,

no solutions?

Buntstich’s picture

Assigned: Unassigned » Buntstich
Priority: Normal » Critical

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

Junro’s picture

Hello 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 :)

Buntstich’s picture

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

Junro’s picture

ok, 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? :)

Buntstich’s picture

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

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en-US" lang="en-US" dir="ltr">

3. If you disable the default english, it dosent work on content translation and make translators worry.

Junro’s picture

ok, it's not a good solution :)

manveru’s picture

I 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?

Junro’s picture

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

Junro’s picture

Hello, 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 ^^.

geodaniel’s picture

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

Junro’s picture

Maybe.

@buntstich

Still work on this? Always no solutions??

Jose Reyero’s picture

Status: Active » Closed (works as designed)

About user defined strings, http://drupal.org/node/313293

It works as explained there.

ilw’s picture

i'm waiting also for solution.

boazr’s picture

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

Junro’s picture

No solutions, You have to use English as default language.

asak’s picture

Interesting.

About the site default language

When translating user-defined strings, the source string is stored using the site default language instead of English. If the default is other than English you will be able to import/export English translations too using the localization interface.
Warning: Whenever you change the default language, you'll need to manually recreate all the source strings so they are defined in that language. This means you may need to edit all your menu items, (localizable) taxonomy terms, etc.. The translations for other languages will be kept though.
Thus you need to decide your default language early on, when setting up your site. Changing the default language back and forth is unsupported and strongly discouraged.

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.

Junro’s picture

"It should however be better noted to users. much better."

Totally agree with you!

mansspams’s picture

subscribing and asking to see discussion here http://groups.drupal.org/node/24438

dan.hu’s picture

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

dan.hu’s picture

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

dariogcode’s picture

Good 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?

dariogcode’s picture

I fixed it select my other language as default, i18n continue working because negotiate only with domains. Thanks!!!

quazardous’s picture

in 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

micheleannj’s picture

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

reydempto’s picture

#21 fixed this problem for me. Well it's more like a duct tape solution, but it works for me :)

knalstaaf’s picture

Status: Closed (works as designed) » Needs work

Subscribing (proposed solutions are not working in my case)

knalstaaf’s picture

Status: Needs work » Active
Issue tags: +internationalization, +default language, +string translation

I'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

  • Refreshing the strings (admin/build/translate/refresh)
  • Updating the translations
  • Clearing the cache

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.

knalstaaf’s picture

Assigned: Buntstich » Unassigned
Category: support » bug

#4: I think the best way is english as standard and Path prefix with language fallback.

Looks 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 :)

quazardous’s picture

When 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 :

  // $omit = $source->textgroup == 'default' ? 'en' : $default->language;
  // unset($languages[($omit)]);

and line 2300 :

    //unset($languages['en']);
nikosnikos’s picture

Thanks #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 :

  // Translate with locale module if enabled.
  //elseif (function_exists('locale') && $langcode != 'en') {
  elseif (function_exists('locale')) {                                                                  
    $string = locale($string, $langcode);
  }
lowfour’s picture

#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!

Jose Reyero’s picture

Category: bug » support
Priority: Critical » Normal

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

quazardous’s picture

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

Jose Reyero’s picture

Yes, so we have a site default language and a source language that may not be the same. So what?

lucuhb’s picture

My 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

The label in French (field_my_field)
/

while for the others cck label for which translation works I see something like

The label in French
field:my_content_type-field_my_field:widget_label

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 ?

Jose Reyero’s picture

Status: Active » Closed (won't fix)

Open too long, no follow-up nor patch.

Really, consider using Drupal 7 version.