Forum OpenACS Development: Explicit locale for not logged in user

This comes from working with xowiki, though it is a problem that we might encounter in general.

Use case: We have a site http://www.crfproject-eu.org/?site=E4 which we want to transfer over to xowiki for a couple of reasons. Getting the content in is the easy part (now that I know how to do it). What bothers me though is the fact that when I click on a language flag on the existing site, I see the content and the navigation in that language. In XoWIKI I can set the language flag to eg. ua:index or pl:index, but this will not change the categories language to the left, as this is still dependent on the browser setting (which may not be pl or ua by default).

Obviously I could rewrite the categories portlet to take the locale (explicitly like " -locale "en" ") and pass it the locale given by the URL. But this will only help me if I'm not allowing a fallback to the default language (e.g. if there is no Polish page, do not show the English one, otherwise, if you show the English one, the categories portlet would show up in English as well). I am aware that you would not be able to navigate to the English page through the categories while looking at them in Polish, but maybe someone provided an internal link ...

So much for the lengthy use case, now to the question. How can I set a locale for a user who is not logged in.

Rationale is, if I could set the locale explicitly for a user who is not logged in, then the problem would go away. Even better, if he looks at the site, the whole site shows up in his locale (e.g. forums, blogger etc.). And, once he registers, we would be able to set the default locale for him accordingly.

I checked and acs-lang does not seem to set a cookie, it relies on the browser setting and the user locale in the database. Question though is, is setting a cookie the smartest solution here? Or is there another trick?

Collapse
Posted by Gustaf Neumann on

In XoWIKI ... categories ... still dependent on the browser setting (which may not be pl or ua by default).
if the package parameter use_connection_locale is set, the used locale depends on the browser setting or on the setting from /pvt/home.


Obviously I could rewrite the categories portlet to take the locale (explicitly like " -locale "en" ") and pass it the locale given by the URL.
you don't have to rewrite it, it is already implemented to behave so. You just have to pass in a locale (e.g. "en_US") and not a language prefix.

As you note, the problem exists mostly for users not logged in, since for others, one could alter the per-user settings in the database. On the other hand: a user perferring a certain language has most likely the browser set to his perferred language already, so the problem might in the real world not be so big. but what, if you have to implement a web-site with the language flags for not logged-in users due to a user-requirement - most likely your case.

you are only mentioning the categories. Don't you care as well for the message keys? If you care only about the categories, the simplest approach is to set a cookie and query this e.g. in the locale_clause in xowiki-portlet and make the setting e.g. cookie+default+system.

The generic solution is to alter ::lang::conn::locale to look additionally for locale-cookies. I would dicuss the specifics in a TIP, and specify the precedence and a simple API, ... and i would clear the cookie, if the locale is changed in /pvt/home. I think, this is a very reasonable extension.

Collapse
Posted by Michael Aram on
If I understand the approved TIP (https://openacs.org/forums/message-view?message%5fid=545011) right, the system should always use the ad_locale cookie if present and update its value when the user switches languages.

This seems not to be implemented in this form in OACS 5.3

I tested using an updated plain OACS 5.3 checkout (acs-lang 5.3.1) and found the following behaviour:

The cookie is only updated when the user is logged out. A language change of a logged in user is only saved in the database and the cookies value is left untouched.

This means:

1) Anonymous user comes to homepage -> Browser settings based locale is used
2) Anonymous user switches language -> Cookie bases locale is used
3) User logs in -> Locale stored in DB is used
4) User changes language -> Locale is updated in DB but not inside the cookie. DB version is used
5) User logs out -> Cookie based value is used again

We can have 4 different languages here in these 5 steps...

Is this analysis right or did I make any basic mistake in testing?

PS: You can test this behaviour directly on the openacs.org homepage, because here it is the same, although acs-lang 5.2.3 is installed here.