Translated strings not marked as translated when default language is not English

the same here, is this solved
I use en, fr, de, if de is the standard it the interface is wrong
clicking on edit will show the correct description but after that the de string is still marked as untranslatet

Drupal still assumes all your source strings are in English, and everything is translated from English. It does not allow for different source languages based on textgroup, it just assumes English across the board.

Same issue for me: German is the default language and English has language prefix but translate interface lists 'de', 'fr' but not 'en' on the search page. When I click to edit translation it displays proper source and translations, i.e. lists all languages for a string.

Same problem here, Im translating a view header and footer, that where in english, and when i look for that string in the "Translate Search" interface it says it is in Spanish (my default language) so i can only translate it to english :S.
The strange thing is that if I change the string to a spanish string, i search for that string and it says to me that the string is in English, so i can only translate it to spanish , that module is sure playing me a joke or something.

Anyway after I change the header from english to spanish and back to english, i am no longer able to refresh the strings, it keeps showing me it in spanish (the second translation i did).

Found a way to work this problem, when you search for that string, and if the string is in the incorrect idiom, you have the option to DELETE it, delete it, then go to the page that has the string (you have to do this to call the t() function indirectly), change your language to another one, and go back again to find this string, i dont know the exact logic of what language do Drupal save the string, but its must have something to do with the language that the string is first read. So if you access your page the first time or after a string delete with english, the string is going to have english in it. Correct me if im wrong plz

I have also had my share of frustration with this issue...

Is there an official guideline to set the default language only after you have localized everything, to avoid english terms being listed as another language?

The current behaviour is totally counter-intuitive!

Actually, I am totally unable to translate taxonomy when the default language is not English. I switched to English and localized the terms and it worked fine for nodes and views, the localized terms got displayed.

Upon switching the default language back to another language, these mapping are lost, the translate interface page only allows translation to English even though these terms are in English. I suppose Drupal considers the original text to be in the site default language. However there must be a way to have non-English as the default language and to be able to make this work.

Please advise on how to input taxonomy terms so that the are stored as English so that the translation functionality allows localization to another language. Should they be entered in the other language and then translated to English? How come this works for other stuff like Block titles, where Drupal does allow translation to other languages, and not to English again? Why is the original text considered English there?

Thank you

subscribe

Error still appears in D7 (and probably in D8 as well).

Patch is based on the fact that, as #2 notices, the admin/config/regional/translate/edit/% page does display correctly, whereas the admin/config/regional/translate/translate page does the wrong thing. So I copied some code from file locale.admin.inc function locale_translate_edit_form() (= correct code) to file locale.inc function _locale_translate_language_list() (as well as that I needed to pass in more info from the calling side (only 1 place)).

Can someone from the subscribers do the backport to D6? if the locale module has not been changed too much this should not be too difficult. I hope that this D7 patch applies to D8 as well, if not, I will see if I can spend some more time on this.

Looks good. It would be great to add some more comments that Drupal uses English for built-in UI strings while it uses the site default as an assumption for other textgroups. Or something along those lines...

Also needs backport to Drupal 7.

I copied code from locale.admin.inc including the comments, but thus also including any lack of comments ... So the comments would have to be added to both places. BTW: is the stated assumption correct in the first place? I noticed that it is correct for taxonomy and for built-in (hard coded), but did not look at other groups.

Proposed comment for locale.admin.inc:

function locale_translate_edit_form($form, &$form_state, $lid) {
  ...
  // Include default form controls for *all* *target* languages.
  // - *all*: thus also for empty, this ensures that the languages always
  //   appear in the same order in the form.
  // - *target*: the source language does not have to be added. The source
  //   language is English for built-in strings and the default language for
  //   all other strings.
  $languages = language_list();
  $default = language_default();
  $omit = $source->textgroup == 'default' ? 'en' : $default->language;
  unset($languages[($omit)]);
  ...
}

and for locale.inc

function _locale_translate_language_list($string, $limit_language) {
  ...
  // Include *all* *target* languages in the list.
  // - *all*: thus both already translated and not yet untranslated languages.
  // - *target*: the source language does not have to be added. The source
  //   language is English for built-in strings and the default language for
  //   all other strings.
  $languages = language_list();
  $default = language_default();
  $omit = $string['group'] == 'default' ? 'en' : $default->language;
  unset($languages[$omit]);
  ...
}

That patch was against the already patched version, thus only included the comments...

subscribe

locale.module? Main change of this patch is in includes/locale.inc, modules/locale(locale.admin.inc) only receives an updated comment.

Well, it is still the UI of the locale module and not related to the overall language component. It is at the right place in locale.module :)

Sorry, but this is definitely not a major bug.

Better title.

+++ includes/locale.inc	Mon May 30 12:44:28 2011
@@ -1977,16 +1977,23 @@
+  // Include *all* *target* languages in the list.
+  // - *all*: thus both already translated and not yet untranslated languages.
+  // - *target*: the source language does not have to be added. The source
+  //   language is English for built-in strings and the default language for
+  //   all other strings.

+++ modules/locale/locale.admin.inc	Mon May 30 13:01:53 2011
@@ -1130,11 +1130,14 @@
+  // Include default form controls for *all* *target* languages.
+  // - *all*: thus also for empty, this ensures that the languages always
+  //   appear in the same order in the form.
+  // - *target*: the source language does not have to be added. The source
+  //   language is English for built-in strings and the default language for
+  //   all other strings.

Please remove the *emphasized* formatting/syntax and express the importance (if any) in natural language.

Powered by Dreditor.

Rephrased as:

  // Include both translated and not yet translated target languages in the
  // list. The source language is English for built-in strings and the default
  // language for other strings.

Will the fixes for this preserve the mapping of translated strings even when the default language is changed?

Which logic is preferable?

1. Strings that are considered to be built-in are in English (current logic, from what it seems). I am unsure at this moment if built in means "comes with Drupal/module", because some user input also appears to be considered "Built in". Other text groups are treated as being in the site default language. Again, I'm unsure which these "other" text groups are. It has been a matter of trial and error so far.
2. All strings are English (regardless of default language), can be translated from English through the translation interface.

Thank you

Sorry, accidentally changed the status, reverting to "needs review"

#21; in practice, option 2 is not really an option because this would mean that site editors must know English to enter texts, even if their site will only be in e.g. Russian and Ukrainian and they don't know a single English word. See also issue #1157426: Field system uses t() incorrectly and inconsistently (or why you will have to re-translate al lot of your own input when upgrading from D7.0 to D7.2)

This patch only will change the way languages are displayed (striked-through or not) in the translate screen).

Patch from #20 contained incorrect modifications. Trying again.

#24: 495930-24.patch queued for re-testing.

WTF?

Eventually it will pass...

What does the comment module have to do with this patch? I don't think that the failed tests are caused by this patch. Anybody else who can tell me more about this?

Failed tests:
Test name Pass Fail Exception
CommentBlockFunctionalTest 112 3 0
Message Group Filename Line Function Status
Comment not found in block. Other comment.test 1544 CommentBlockFunctionalTest->testRecentCommentBlock()
Comment found in block. Other comment.test 1545 CommentBlockFunctionalTest->testRecentCommentBlock()
Comments were ordered correctly in block. Other comment.test 1547 CommentBlockFunctionalTest->testRecentCommentBlock()

Could this be an issue with translating test strings?

    // Test the only the 2 latest comments are shown and in the proper order.
    $this->assertNoText($comment1->subject, t('Comment not found in block.'));
    $this->assertText($comment2->subject, t('Comment found in block.'));
    $this->assertText($comment3->comment, t('Comment found in block.'));
    $this->assertTrue(strpos($this->drupalGetContent(), $comment3->comment) < strpos($this->drupalGetContent(), $comment2->subject), t('Comments were ordered correctly in block.'));

#15: 495930-15.patch queued for re-testing.

I also don't see a reason for the patch to fail. On visual patch review, it looks like it is as good as it can get. My concerns were resolved.

@marktheshark: the patch does not change Drupal's existing assumptions about which string is in which language, it just makes the display correct according to those assumptions. At this point Drupal 7 is in feature freeze, so its logic for these strings will not change. We can make such changes in Drupal 8, but let's concentrate on fixing the bug here instead of going on a whole journey or redesigning it in this issue :) Please follow and participate in http://groups.drupal.org/internationalization to get involved with the Drupal 8 work.

The "CommentBlockFunctionalTest" is failing randomly on several unrelated issues, see for instance:

#1178480-8: field_view_field() does not pass language to hook_field_attach_view_alter() implementations
#1178500-13: hook_field_*() prepare/view have no access to the requested language

I think HEAD might be "partially" broken, in the sense that we have a committed test that in some conditions fails.

Hmm its strange it always fails on language related patches...

#30: 495930-30.patch queued for re-testing.

Patch from #15 succeeded, retesting #30 again...

Well, @plach follows language related issues, so naturally those are the examples he gave :)

FYI I'd like to get through the removal of textgroups in Drupal 8. They are a flawed concept for object translation. See #1188430: Rip out textgroup support from locale module. That would move this issue down to Drupal 7. Until that happens though, this is considered a bugfix applicable to Drupal 8 and should be applied there first :|

subscribe

Textgroups are now removed from Drupal 8, so this does not apply to Drupal 8 anymore. Moved down to Drupal 7!

A patch for D6 could still be useful... is it planned or is it a wontfix ? Thx :-)

@FiNeX: yes, that should be possible after this lands in Drupal 7.

Thanks Gábor :-)

@FiNeX and/or hibersh: please help this patch get through by testing and reviewing the patch and reporting back here.

@fietserwin: of course! but I've not found the D6 one :-(

In the meantime I'll test the D7 very soon (tonight or at most tomorrow) :-)

Just bumped into this issue, is this still relevant for D7?

Yes, so please review.

Tried and it worked

Hmm, worked for me.

Although "patch -p1" failed, maybe that's the problem? Testbot also claims it can't apply the patch.

Rerolled the patch.

The reroll is different from the one in #495930-30: Translated strings not marked as translated when default language is not English. The documentation in locale.admin.inc more specifically. I'd love to RTBC this if you could clear up which version we should keep.

My fault, this is the patch as it should be. Thanks for reviewing.

Passed, so RTBC.

Sorry guys but applying #46 to locale (dev version) I see the following error

can't find file to patch at input line 5
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git a/includes/locale.inc b/includes/locale.inc
|index c168da0..dd6f269 100644
|--- a/includes/locale.inc
|+++ b/includes/locale.inc
--------------------------

I tried to patch it with the command patch -p1.

Any suggestion?

56: 495930-56.patch queued for re-testing.

Patch applied to Drupal 7.34 and works like a charm. Thanks!

Setting back to RTBC based on #57, #61 and a successfull retest per #62.

That was a bogus test failure, so back to RTBC for now. (I didn't review the patch myself.)

Testbot fluke.

Committed to 7.x - thanks!

A test would have been nice here, but the patch has been waiting for a while and it's the kind of bug where writing a test might be painful, so I guess it's OK as is. This mostly just seems to make the code consistent with similar code elsewhere.

Technically this issue was marked for Drupal 6 backport; not sure there's much chance of it getting committed to Drupal 6 at this point, but moving it back there anyway.

I've had a small problem with this patch since upgrading to 7.36. The i18n_string module allows you to set the source language to a language other than default. In my case, the site's default language is Spanish but the source language is set to English. Since upgrading to 7.36, for text groups other than Built-in strings the Translate interface page shows the 'en' language code with a strike-through for all strings, both translated and untranslated. I've rolled a patch against 7.36 that uses the i18n_string_source_language variable if i18n_string is installed, and the default language if it's not installed.

I've already install Drupal 7.36 but there is this bug yet.
There is no way to translate the Built-In interface. The string in default language is still in English and not my real default language.
Only a question: WHY?

Read the issue and you'll know.

Code in core does not depend on specific features from contrib modules. So, IMO i18n_string should alter the form, meaning that the version and status should be set back as in #72.

Agreed.

Ok, sorry but I continue not understand the problem. I have a site in my local workstation that has the default language not English. So, i export my configuration with Features in production but i can't be able to translate anything because all the strings are imported into built-in interface.
So, how I do proceed for this issue? I really need to translate the strings but i can't able!

#78: This issue was only about a glitch in the UI, not about strings not being translatable. So I think you should search for other issues that match your problem or file a new one yourself.

OK. I suspected my patch wasn't the correct way to fix the problem, but didn't know how to go about doing it the right way. I'll take a look at i18n_string and see if I can make a patch for it. Thanks.