NB: This might be a core bug, but this happen only with extra string that i18n let us translate, that's why I'm posting it here.
So, the bug is that when I go to the Translate interface, the column Languages only show French (in my case), even if French is the system language and default language. For the built-in string, it make sense that fr is shown with or without a strikethrough since the orignal text is in English (see the top part of the screen shot).
But when it comes to other kind of string (Fields, Node types, Menu, Taxonomy, Blocks, etc.), the languages column still only show fr and always with a strikethrough. In my case, since the original text is in French, it doesn't make any sense. And yet, as you can see in the bottom part of the screenshot, Drupal seem to know that the missing language is English (he ask for that english missing string), and probably know that the original string is in French. Even though in the overview they are all at 0% translated (even if they are all French string... See the screenshot)
If it's not a i18n bug, let me know, I'll report this where it goes (probably core, content translation module)
| Comment | File | Size | Author |
|---|---|---|---|
| #11 | i18n_string-translation_interface_language_fix-1188334-11.patch | 6.11 KB | robertom |
| #8 | i18n_string-translation_interface_language_fix-1188334-8.patch | 6.11 KB | drclaw |
| overview.png | 7.86 KB | sharky999 | |
| translation.png | 29.17 KB | sharky999 |
Comments
Comment #1
jox commentedSubscribing and mentioning this post which is a consequence of this bug: #1197404: Content-Type name translation
Comment #2
jose reyero commentedWe are moving away from using that 'Translate interface' page, we won't have these issues anymore when it is completed, #1191662: Migrate away from textgroups to own storage in i18n
Comment #3
jose reyero commentedForget my previous comment, we are still using this UI for now. So we should fix this one.
Comment #4
jose reyero commentedThere was another related issue with strings source language (that can be configured now) and was not being used for these translations form.
As a first step, done a full replacement of the translation form. Will need a full cache clear and a menu rebuild.
About the original issue (wrong translation languages displayed), marking it as minor, maybe for later.
Comment #5
cyberwolf commentedSubscribing.
I confirm the problem in the translation form (string source language not used) is fixed in the latest dev release of i18n_strings. Great!
Comment #6
lsolesen commentedAny progress on this one?
Comment #7
geek-merlinSee #2534898: Translation overview page does not respect i18n source language
Comment #8
drclaw commented@axel.rutz that's a nice clean fix, but I don't know how likely it is that they'll accept a core patch that relies on a variable provided by a contrib module...?
Here's a solution (patch attached) in the same vein as the translation form fix mentioned in comment #5. We just override the translation interface listing page with a hook_menu_alter and fix what we need. Most of the code is just copied from the core locale module but with a few function overrides and @axel.rutz's patch.
Thanks!
drclaw
Comment #9
damienmckennaI closed #2534898: Translation overview page does not respect i18n source language as it's a duplicate.
Comment #10
devad commentedI have tested patch #8 and it fixes the issue the same way as @axel.rutz patch #1 from #2534898: Translation overview page does not respect i18n source language.
Changing issue status as "Reviewed & tested by community". Thanx @drclaw. More reviews are welcome of course.
Comment #11
robertom commentedattached a rerolled patch
Comment #12
paulvandenburg commented+1 for the RTBC. Has been in use for several years in several productions sites in our DvG distribution: #2676858: Fix i18n issue without a core patch
Comment #14
joseph.olstad