Forum OpenACS Q&A: acs-lang problem! needed help

Collapse
Posted by Kevin Lau on
Dear all,

I have found a weird behaviour in lang::user::set_locale and need help and suggestion.

I am running a tri-lingual site that would switch languages between English, Simplified Chinese and Traditaional Chinese. I use /acs-lang/change-locale?user_locale=$locale&return_url=$path to switch language. Mostly the page can be changed but occassionally the browser has no effect on the language change.

I tracked the code of lang::user::set_locale in acs-lang/tcl/locale-procs.tcl and put ns_log mark and found that the line "util_memoize_flush [list lang::user::site_wide_locale_not_cached $user_id]" seems not to be excuted (I put some log mark insdie lang::user::site_wide_locale_not_cached but not displayed).

This problem is persisted that the weird response will not disappeared once it happened on a particular browser and PC until the cookie was removed. But it would appear sometimes later in unpredictable manner.

I use OpenACS 4.6 and the code snippet in acs-lang/tcl/locale-procs.tcl for your reference at the end of this post.

Thank you for any suggestion.

Kevin

++++++++++++++ code +++++++++++++++++++
ad_proc -public lang::user::set_locale {
    {-package_id ""}
    locale
} {
    set user_id [ad_conn user_id]

    if { $user_id == 0 } {
        # Not logged in, use a cookie-based client locale
        ad_set_cookie -replace t -max_age inf "ad_locale" $locale

        # Flush the site-wide user preference cache
        util_memoize_flush [list lang::user::site_wide_locale_not_cached $user_id]
        return
    }
...
...

Collapse
Posted by Malte Sussdorff on
I guess the problem is that you have to move the util_memoize_flush our of the "if" statements and flush in any case, as the case which you are dealing with ($user_id > 0) will not flush the site_wide_locale cache.
Collapse
Posted by Malte Sussdorff on
Please post if this works. If it does, commit this change to 5.2 as well, or just post that it indeed does work and solve your problem.
Collapse
Posted by Samer Abukhait on
There is another flushing statement after that for other cases.

Memoizing the locales for not logged in members was not a good idea and I guess it was solved in 5.1

Kevin's problem could be browser specific, it need some extra tracing.
What is obvious from the above description is that the server couldn't replace the previously existing cookie in the browser (But it could write a new one when the cookie was removed).

Collapse
Posted by Kevin Lau on
First thank you for all your suggestion.

More detail can be given to the caes
1. For the case of the problem happened, the user_id is equal to 0, ie. not-login user. I have no idea if login user would have the problem. But not login user has problem and I am trying to narrow down the case first.

So I guess moving util_memoize_flush may not help the case.

2. The problem happened in both Firefox and IE. And I found that I can change the cookie ad_locale correct but the expiry time is infinte. I have two other cookies that one is session_id with 2 hour life time and one is ad_user_login with infinte lifetime.

Or should I disable memoize cache?

Thank you.

Kevin

Collapse
Posted by Kevin Lau on
Hi,

I have try to set the parameter "UsePackageLevelLocalesP from 0 (false) to 1 (true) and the problem seems disappear.

But I don't know if the problem is temporarily removed because I have login using the problem browser+server.

Any idea or comment?

Kevin