FYI -
This should not impact anyone; if a clent browses your site with multiple
language preferences (which will probably not be the majority of visitors),
then those people will have correct language selection (that is the fix).
If you have a site in some language, and it is other than English, AND you
have a translation file for English, you will want to be aware of the
following (for the purpose of discussion, I will assume an app written in
Italien, but the same will hold for other non-English apps):
- If there is no italian translation file people browsing in Itailan will
still see Italian (although now gluon will assume this is English, the
behavior should that it will do NOTHING with languages files, but rather
display the default - in this case, your apps Italian - strings)
- COULD SOMEONE CHECK THIS AND REPORT: If there is an English
translation file, and you have not declared / forced any language in your
app (e.g. in db.py or 0.py), then the displayed language will be still be
Italian (since the "default" language to gluon will be english, the selected
language - Italian - will not have a translation file, so the default
behavior will be to do nothing, no translation file - and so you should be
displaying the "native" app strings, with no access of the translation file.
- HOWEVER: if the client has multiple languages set, and ONE of them
has a translation file, this will be the displayed language.
For example:
If client has prefernce languages (in order): Italian, English,
AND there is
an English translation file, ENGLISH will be serverd.
- Since this will be NEW and NOT DESIRED (and also not the usual
case), you will need to update your app to declare / force Italian as the
default language, either of these ways:
- in db.py (or 0.py, or any early controller), add:
- T.current_languages=['it-it'] # replace with what your app is
using for language
T.force(T.http_accept_language)
- new (I added, because I like it saying what it is doing more
clearly; it is equivalent functionaly to the above):
- T.app_default_languages('it-it') # since current_languages can
be multiple, so can this
So this ONE SPECIAL CASE is the only where you will want to change your
app. SInce this is ALSO the case where clients (multiple language choices)
will have "incorrect" language behavior, either way it is a bug for those
clients, and you would have to make this same kind of change for them
regardless. This patch just REDUCES the number of times you need to worry
about this.
I hope this helps.
Regards,
- Yarko
On Mon, Nov 23, 2009 at 2:25 PM, mdipierro <mdipie...@cs.depaul.edu> wrote:
>
> Yarko's patch is tentatively in trunk since nobody seems to complain
> about this change in behavior.
>
> Massimo
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en
-~----------~----~----~----~------~----~------~--~---
