Incorrect languages shown for translation status in locale search results (plus tests)

#348671: locales_source has no record of source language marked as duplicate.

Here's an updated patch with the beginnings of a test.

Hit a blocker though - http://api.drupal.org/api/function/_locale_translate_seek_query/7 takes variables from $_REQUEST and I get Undefined index: simpletest_p70b as an exception when running tests. Also, we shouldn't be building an SQL query by grabbing stuff from $_REQUEST, this code must be from long before FAPI.

Added locale_test.info and locale_test.module, still a fail in the test which I'll investigate later.

OK here's a working test as well as a working patch now. While the test implements some of hook_locale() there's all the refresh stuff which looks completely untested at the moment, however that will be non-trivial to test and is out of scope for this specific issue.

I think this should wait till we have other textgroups implemented so at least we can test it

Anyway after seeing this issue, I think we will need a way to know the language of the source string. This may be in locale_source table or maybe the text-group could define it, I'm working on a 'hook_locale' extension for some other patches...

Patch re-roll against latest head.

Cheers,
Stella

Re-rolled again. The simpletest included already exists in the file, so removed that from the patch.

Cheers,
Stella

this might get back ported to D6,
it seems to be a critical issue for multilingual sites with default language other than English

makes dealing with existing/missing English translations agonizing or even impossible

as a D6 bug it seems to me pretty "major" issue
nevertheless, can't brake backward compatibility changing a function signature, but can work around it
at least providing a minimal support (D6 draft patch attached)

this is really painfull in D6
just attempting to make English translatable somehow without making the bug worse

thus, attempt to display English as languages are meant to be
but for Built-in group fall back to current implementation

Arhak, I applied your patch in drupal 6 and there is no error until now.
I landed in this thread because of a problem with a term. My default language is spanish. I have a content type that is also a "content profile". I have to put the title in spanish, cause if a put it in english the translate interface only lets me translate it to english. As it's a content profile, there is a new term created automatically for the title of that node in the profile page, but unlike the content type, Drupal think this term is in english and only let me translate it to spanish, when the original name is already in spanish.
Sorry I ask here, but I couldn't find any solution to this. Is there a way I can tell drupal the original term is no in spanish or not in english?

Thanks, and sorry again for asking here.

@#20 Drupal is not ready to handle every combination someone might need, nevertheless, having a "default input language" other than English might be supported with this patch (and maybe another couple of modules/patches)

"I think" that your use case should work like a charm if you go to admin/settings/language and set Spanish as your default language, which means Drupal should assume every input is in Spanish, that will create your taxonomy terms in Spanish and make them available for English translations
Note: I said "I think" because that might not be your use case, but I'm sure it works since I have done

WARNING: changing the "default input language" in the middle of a running site has consequences, most of all with the i18n module
be aware, make backups before any regretfully change
probably you will need to fix language for already entered data (maybe not if you are not using i18n module)

Arhak, I already have spanish set as default since I started developing the site.
With the particular case I told before, the problem is still there. I had to force a template to show a fix title depending on the language of the site, without calling the original title, cause the site is soon to be launched and I couldn't make it work.

As I see, not all modules identify the language, to send the term in the correct language.

It's a little annoying this problem cause I'm just the designer, not a translator, and I have to verify if the translator will be able to translate from spanish to english. And, in a lot of cases, I had to put original term in english, and then translate it myself to spanish cause drupal didn't identify the language right.

Thanks for your answer. I hope d7 has a better multilanguage support, and I hope it to be launched soon.

@#22 If you like open a forum post describing as much as you can and contact me through my contact form, then we exchange experiences over there

This looks critical, but what's the status here? Seems like we have two entirely different patches?

errr, no, not critical at all.

none of the patches have received feedback
@#16 patch for D7 which probably will need to be re-rolled
@#19 another approach for D6 (no API change, rather kind of "bug half-fix", can't be totally fixed without braking the "code freeze")

I'm not sure what the status is here or if this has already gone into a recent release? I run a site with German as default language (i.e. with source strings in both German and English) and I do agree that the translate interface needs to be updated to accommodate non-English default languages. I'm attaching a screenshot with an improved "Languages" column.

subscribe

During installation:
* Notice: Undefined index: pt-es in locale_add_language() (line 390 of /includes/locale.inc).
* Notice: Undefined index: pt-es in locale_add_language() (line 391 of /includes/locale.inc).
SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'name' cannot be null

=> renamed file from pt-es.po to es.po (THAT NAME IS USED SOMEWHERE IN INSTRUCTIONS, but I had it on D6 without pt in front)
=> halted during loading translations
=> reload button browser
=> drupal 7 installed.