On Mon, Nov 23, 2009 at 12:47 PM, Thadeus Burgess <thade...@thadeusb.com>wrote:
> I just don't want my code littered with
>
> error_message=languages[0]
>
> print languages[1]
>
> alert(languages[3])
>
:-)
I agre, that would TRULY be terrible!
If anything, if Massimo would want to go in that direction (instead of
firmly back in the "translation" concept; latter has some distinct
advantages down at the gluon level) then this kind of stuff would have to
happen "behind the scenes", in gluon.
- Yarko
>
> -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
-~----------~----~----~----~------~----~------~--~---
