I just don't want my code littered with
error_message=languages[0]
print languages[1]
alert(languages[3])
-Thadeus
On Mon, Nov 23, 2009 at 12:23 PM, Yarko Tymciurak <
resultsinsoftw...@gmail.com> wrote:
>
> On Mon, Nov 23, 2009 at 11:33 AM, mdipierro <mdipie...@cs.depaul.edu>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 <resultsinsoftw...@gmail.com>
>> wrote:
>> > On Mon, Nov 23, 2009 at 12:20 AM, Thadeus Burgess <
>> thade...@thadeusb.com>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 <mdipie...@cs.depaul.edu
>> >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 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
-~----------~----~----~----~------~----~------~--~---
