On Mon, Nov 23, 2009 at 11:33 AM, mdipierro <[email protected]> wrote:
......
> I still stand that those apps have a bug (because when we added
> translations I did not set the current language) not languages.py.
>
Then we must agree to disagree.
For me, it is quite evident (by tracing execution of JUST gluon/languages.py
- without consideration of any application, and BEFORE any application is
even called by gluon/main) that languages.py selects a language based
(incorrectly) on:
- whatever the first match is between the http_request_language and an
available app directory/languages translation file
The concept that you will translate "from no specified language" to some
language is in itself faulty.
IFF the app/lanugages translation files held the target string by index,
then your argument might hold some merit.
AS IT IS, the design even of the translation files is that each translation
file contains a "dictionary" pair: the DEFAULT LANGUAGE string as the key,
and the TARGET SERVE language string as the fetched item.
If the design you had was NOT of tranlation, but rather of serving strings /
localization (e.g. indexed strings), then expecting to find a string file
for the http_request_language would make some logical sense.
As it is, you are translating from a default language (which in the
distribution is 'en') to a target language.
Perhaps this is really pointing to a need to review the overall string
serving design.
For example, with an indexed based, language string file, it would be
possible to set [1] a site default language for error messages, and
simultaneously a different language for an application (I'm not sure that is
easy to do right now).
To make clear what I am talking about (as an example)
Current design is based on the concept of TRANSLATION, so that
app/langes/it-it.py (for example) holds:
'Welcome to web2py': 'Ciao da wek2py',
'click here for online examples': 'clicca per vedere gli esempi',
I am suggesting that a "serve language" concept (rather than translation)
would have some string index (rather than translation-based index), perhaps
something like this; in place of lanugages.py, perhaps a strings/en-us.py:
controller.default[1]:'Welcome to web2py'
controller.default[2]:'click here for online examples'
and for strings/it-it.py:
controller.default[1]': 'Ciao da wek2py',
controller.default[2]: 'clicca per vedere gli esempi',
This is just for illustrative purposes...
What I am saying is how you talk about _this_ (is it a bug? is there
something missing) requires a shift - to the concept that we do not do
translations; we serve strings in some language, and to do that you must
have the strings existing in that language (then translation becomes a
utility function, and not a web2py term).
As it currently is, mixing these two perspectives is problematic: Does
web2py translate (if so - then FROM which language? I need a default
language declared somewhere), or does web2py serve strings on a per-language
basis (if so, then default language is irrelevant; all I need is that one of
the http_request_languages exist).
Massimo seems to say that languages/translate.py operates in the latter
fashion, but this is incongruent with _even_ the name of that class (class
translator), and the function T('string to translate from').
Consider how even the programming paradigm changes if you shift to the
"serve string" concept (away from the translate model).
Of course, it is natural to talk about "translate" to a web writer; the the
internal model does not need to follow the external structure - it can do a
engineering-layer translation to what Massimo is saying - but to do so,
there must be clear separation: "here, we think of it this way; in gluon,
it accomplishes it this way...".
There is room for much discussion around this, but for now I believe this is
simply a bug in gluon/language.py given the current design, (e.g. names used
for classes/functions).
- Yarko
Nevertheless it is easier to change the default behavior than change
> three apps.
>
> If no objection from people overseas, I will change this in trunk.
>
> To people overseas: If your app is in polish (for example) and you
> provide an english translation, the english translation will not work
> anymore until you re-set the current language to polish. Now it does
> not make any assumption about the current language.
>
> Massimo
>
> On Nov 23, 11:12 am, Yarko Tymciurak <[email protected]>
> wrote:
> > On Mon, Nov 23, 2009 at 12:20 AM, Thadeus Burgess <[email protected]
> >wrote:
> >
> > > if web2py is mostly written in English, then it needs to default to
> > > English, and allow for easy overriding of this default.
> >
> > I agree.
> >
> > More explicitly - whatever the web2py distribution default is should
> behave
> > correctly;
> >
> > If an application declares it's own default language (and it should be
> easy,
> > and clear - how should that look to the application writer?), then that
> > should override the distribution default for requests to that
> application.
> >
> > To see why there is currently a bug,
> >
> > - set your languages to more than one in (for example) Firefox
> > - e.g. [1] 'en'; [2] 'it'
> > - go tohttp://www.web2py.com/examples/simple_examples/hello6 (or any
> of
> > the simple examples)
> > - despite 'en' being the first language, the example displays
> "Slave
> > Mondo' (incorrect behavior)
> >
> > The current default behavior is incorrect; the proposal (which is fine
> for
> > overriding a site defailt) is that EACH APPLICATION must declare the
> default
> > language.
> >
> > This (currently) is necessary for the system to behave reasonably.
> >
> > The reason Massimo's proposed "solution" is NOT sufficient for the
> > installation default should now be quite evident: the "patch" for the
> bug
> > MUST propogate to EACH AND EVERY APP for the system behavior to be
> correct.
> >
> > This is NOT a bug in examples; this is a bug in gluon/languages.py. To
> see
> > this yet another way, write a unit test for gluon/languages.py.
> >
> > Since examples do not behave correctly, and - in general - with Massimo's
> > proposal multiple, and constantly changing (as applications are
> > installed) points of correction must be made in order to accomplish
> > reasonable behavior: this by itself is sufficient evidence to point
> > directly to the bug in gluon/languages.py. Additionally, a suggestion
> that
> > "examples" has a bug (it does not) is a suggestion which breaks
> "backward
> > compatibility" (but backward compatibility is not the point at all here
> -
> > that correcting a bug at its source is the proper approach is what is in
> > discussion here)
> >
> > Once all recognize this clearly, then we can move on to talking about
> what a
> > good solution would look like.
> >
> > - Yarko
> >
> >
> >
> > > -Thadeus
> >
> > > On Sun, Nov 22, 2009 at 10:04 PM, mdipierro <[email protected]
> >wrote:
> >
> > >> rammer always explicitly say which languages do not need
> > >> transla
> >
> >
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"web2py-users" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en
-~----------~----~----~----~------~----~------~--~---
