When I translate a node (with entity_translation) I expected the displayed language names to be translated. But they are displayed in English, no matter which content/interface language is active.
So,
on an English node it says "French" (which is correct),
on a German node it says "French" (and not "Französisch"),
on a French node it says "French" (and not "Français").
Also, the language name translation sometimes switches for all translations; so sometimes I have German language names on English/French/German nodes. I'm not sure how it exactly happens, couldn't reproduce it everytime. But I think it has to do with which node is saved last.
Comments
Comment #1
no2e CreditAttribution: no2e commentedThe translations works if you enable the field setting "Field translation". But you would have to re-do all the work and select all desired languages for all translations again. It's safe to say that this would inadvertently become out of sync easily.
The 'Synchronize translations' i18n sub-module doesn't help here, because it seems to work only for Content Translation, not for Entity Translation.
Comment #2
no2e CreditAttribution: no2e commentedI created a support request at Entity Translation (#1761474: Synchronize field content (select list by languagefield)?), because I'm not sure what the right way would be.
Comment #3
johnvI am afraid this module does not support translations yet.
I suppose we'll encounter the same problems as countries module .
Comment #4
Alan D. CreditAttribution: Alan D. commentedI'm still not overly sold on the way that webflo done that there. But I've never done an i18n site and he is a co-maintainer for i18n... Personally I think providing the UI for translation only and wrapping everything in the t_countries(), or whatever I called it, would be the best way forward. But that is a completely different kettle of fish!
To the issue at hand.
This returns
$tname = t($value[0]);
, so the results of this should be being returned translated.So the issue is with the load and that there is (almost) always field caching here.
This needs to be changed to a hook_field_prepare_view(). Completely untested first stab...
And a update script that flushes the field caches (or a manual cache flush)
Comment #5
Alan D. CreditAttribution: Alan D. commented@johnv
Did you ever resolve that field non-caching thing?
Comment #6
johnv@Alan,
IMO just using t(language) or t(country) seems to correct and straight-forward method, perhaps including a plain_text()-function.
PS. The countries-caching is still on my list. It reveiled some problems with other modules, too.
Comment #7
Alan D. CreditAttribution: Alan D. commentedThis is what we use here, but this is done too early, moving to pre_view should resolve most issues around this. As countries use user data too, rather than a predefined list here, it changes the scope / issues with i18n.
Patch should resolve these. Noticed what appeared to be another bug, so created three options to test this, name / name with native / (more for testing) native as display options.
Guess the RTL languages need work, but leaving that out of this patch.
Comment #8
Alan D. CreditAttribution: Alan D. commentedNative formatter setting is going be a performance issue, this is dropped in this patch.
Comment #9
Alan D. CreditAttribution: Alan D. commentedRight patch this time
Comment #10
johnv@Alan, it seems like the patch is not made against lates 7.x-1.x git-code.
Comment #11
johnvPatch #9 solves a caching problem. I am not sure how this helps OP's problem.
1. I have tested this in the following cases:
1. A.
- Enabled 'Translation'.
- Set user-language to 'nl' (Dutch)
- Create 3 nodes. Each with either 'und', 'en' or 'nl'
- Make sure a translation exists for the word 'Dutch' using module 'localization' (there was none in my system.)
- Show each node.
These are the restults:
- each node shows the user's translation of the field. This might be ok for 'und'-node. It is ok for 'nl'-node. But is it OK for 'en'-node. Shouldn't the translation be that of the node, instead of the user?
1.B.
- Enabled 'Translation, with field translation'. Enable 'field translation' for the language field.
On normal text field, I would get an option to change the value of the field. For the languagefield, I did not get this oppotunity,
so I could not test this further.
2. on some pages, e.g. the node edit page, hooks languagefield_field_load/languagefield_field_prepare_view are called with every possible language_code. The last one is the last one in the langage-list. Can this explain OP's "sometimes I have German language names" ?
Comment #12
johnvA patch is coming up.
Comment #13
johnvPlease check out latest -dev-version.
I committed attached patch.
I get better results. I did not (yet) activate hook_field_prepare_view().
Comment #14
Alan D. CreditAttribution: Alan D. commentedJust a heads up, I think load is too early for an i18n site as the results will be cached. Switching to preview means that these will be more responsive to the current language of site.
Comment #15
johnv@Alan, I noticed. hook_field_load is loaded on every page, 1 time for every entity in the system. I guess more modules use this hook to often. I'll remove it in next commit.
Comment #17
sportel CreditAttribution: sportel commentedI'me not sure what this discussion is all about. But I do know that the 7.x-1.x-dev version doesn't translate the languages, but the 7.x-1.0 version does! So, isn't the problem just in the dev-version?
Mike.
Comment #18
Alan D. CreditAttribution: Alan D. commented@john
"hook_field_load is loaded on every page" - i really must get a dump of your site to investigate this more. This is NOT normal behaviour!
@sportel
Yes, using load has resulted in the cached entity storing the translated values (these are not store in a language specific cache), thus my recommendation to use prepare view hook here.
Comment #19
johnvsportel's #17 is right.
I committted this small patch, that should solve the issue.
Comment #20.0
(not verified) CreditAttribution: commentedadded switiching translation