Ticket #4770 (closed Bug: fixed)
Language changes of ATCT-Object to the lang of a cookie
| Reported by: | Anonymous User | Owned by: | hannosch |
|---|---|---|---|
| Priority: | major | Milestone: | 4.0 |
| Component: | Internationalization | Keywords: | |
| Cc: |
Description (last modified by hannosch) (diff)
I've got a Problem with ATCT plus LinguaPlone under Plone 2.1. When an Author sets the Language for himself (let us say english) he gets a cookie with prefered language in it. When he edits the properties of an object after that, the language of the object changes to the language the Author prefers.
Limi says this:
The reason it happens is because the cookie is set with the same name as the language field - thus the value of the language isn't actually set to the value it shows before hit the save button.
But they should of course be different.
Will look into fixing it later.
Change History
comment:2 Changed 6 years ago by hannosch
- Component changed from Content Types to Internationalization
- Description modified (diff)
comment:6 Changed 6 years ago by hannosch
Mental note to self: Enabling PloneLanguageTool doesn't solve this issue, as the issue submitter told me.
comment:7 Changed 6 years ago by alecm
- Priority changed from minor to major
- Milestone changed from 2.5 to 2.5.x
comment:8 Changed 6 years ago by limi
- Milestone changed from 2.5.x to 2.5.1
This is something I would like to have fixed for 2.5.1, as it is messing up translations in LinguaPlone.
comment:10 Changed 6 years ago by hannosch
Ok, I looked into this some more. Right now I cannot reproduce the problem on the current Plone 2.5 branch anymore.
I found one real problem though and one that might be one as well and at last one thing I'm not sure about ;)
The real problem shows up if PloneLanguageTool is not used. If you go to your personal preferences and change your member language, after hitting save you get the Plone UI translated to that language. Viewing the page again, ignores the setting again.
The problem here is that PlacelessTranslationService has a 'RequestGetAccept' language negotiator which has the higest priority per default and looks for a 'language' attribute in the form section of the REQUEST. I think this handler is stupid and should just be removed.
The second problem I found is in PloneLanguageTool. Part of the language negotiator code there is to set 'language' in the REQUEST. It never reads that value though. The only place we use that value is in the plone view to determine which language we should set in the HTML header. If nothing is found in the request it looks up the language of the content object or falls back to the site default.
Now I'm not sure what the HTML header should be set to. For example if you view a page written in German, with the language set to German on the object itself, but have the UI in English as per browser settings. So your site is partially German and partially English - how do we set the header?
Right now I would favor to give precedence to the content language and only if this one is not set to look up the current language used for the UI.
The last questionable item I found is that setting your member properties language field has no effect at all, besides the bug mentioned earlier. I think it was supposed to determine the content language of newly created items once, but that does not seem to work right now. If one has PloneLanguageTool installed this gets even more complicated as PLT has an option to force all newly created items into language neutral mode. So the member property should only be checked if this option is not set. But right now all content is always set to neutral regardless of these settings.
I should probably note that I did not test any of this with LinguaPlone installed which probably adds some more options to the whole game.
Right now I think the only sane approach is to redefine how things should work and implement this from scratch as part of my plone.i18n / plone.negotiator work.
comment:11 Changed 6 years ago by hannosch
- Milestone changed from 2.5.1 to 2.5.x
Needs discussion, so nothing for 2.5.1.
comment:12 Changed 6 years ago by hannosch
There is already a ticket for the first problem (#4986).
comment:13 Changed 5 years ago by hannosch
- Milestone changed from 2.5.x to 3.5
All the open mentioned issues involve API changes, so nothing for <=3.0.
comment:14 Changed 3 years ago by hannosch
- Status changed from new to closed
- Resolution set to fixed
All the mentioned issues have been fixed in Plone trunk as far as I can see.
This is very bad behavior. Perhaps we should just disable postback on the Language widget. Ideally we would have the postback look only in the request.form/other and not at the cookie, but that would require a (perhaps undesirable) change to AT or a custom widget.