| Project: | Drupal core |
| Version: | 7.x-dev |
| Component: | locale.module |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs work |
| Issue tags: | i18n sprint, needs backport to D6 |
Issue Summary
For the default' ("built-in interface") locale textgroup, translations can be made in languages other than English. For other locale textgroups, translations can be made in any language except the default one.
However, the translation status table's "Languages" column - that one that shows what translations have and have not been made - covers only the first case. That is, it always shows all languages except English, whether or not the string's textgroup is 'default'. This is confusing as, e.g., if the default language is 'fr', 'fr' will always show as untranslated for strings in textgroups other than default, but when you click on edit there is no option to translate to French (and no need to do so).
What we need to do is apply the same logic as is applied on the string translation edit form. That is exclude 'en' for default textgroup strings and exclude the default language for other textgroup strings.
Patch attached. Untested. I don't have a module for HEAD that implements a textgroup other than default.
| Attachment | Size | Status | Test result | Operations |
|---|---|---|---|---|
| translation-languages.patch | 1.77 KB | Idle | Failed: 7873 passes, 0 fails, 3 exceptions | View details | Re-test |
Comments
#1
The last submitted patch failed testing.
#2
Fixed up, shd pass tests now.
#3
#348671: locales_source has no record of source language marked as duplicate.
#4
This comment, which I copied from elsewhere, needs to be adapted, since here we don't have a $source variable.
<?php+ // We don't need the default language value, that value is in $source.
?>
Should be something like:
<?php+ // Don't display translation status for the language of the source string. The source
+ // is assumed to be in English for the default text group and in the default language
+ // for other text groups.
?>
#5
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_p70bas 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.#6
Added locale_test.info and locale_test.module, still a fail in the test which I'll investigate later.
#7
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.
#8
The last submitted patch failed testing.
#9
#10
#11
The last submitted patch failed testing.
#12
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...
#13
#361597: CRUD API for locale source and locale target strings, which will bring user-entered string handling into core, is getting close now, and in any case this is an issue that shows up in contrib in D6. So we can go ahead and fix now.
#14
Patch re-roll against latest head.
Cheers,
Stella
#15
The last submitted patch failed testing.
#16
Re-rolled again. The simpletest included already exists in the file, so removed that from the patch.
Cheers,
Stella
#17
The last submitted patch failed testing.
#18
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)
#19
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
#20
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.
#21
@#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/languageand 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 translationsNote: 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)
#22
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.
#23
@#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
#24
This looks critical, but what's the status here? Seems like we have two entirely different patches?
#25
errr, no, not critical at all.
#26
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")
#27
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.
#28
subscribe
#29
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.