On Mon, Nov 23, 2009 at 12:56 PM, Yarko Tymciurak <
resultsinsoftw...@gmail.com> wrote:
> 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 agree, 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.
>
... to make this comment more concrete - it is one of clear, crisp concept,
approach than anything - about being intentional and explicit.
So, consider now what you have "littered" (and it's quite readable, I
think):
error_message=T("This is an error message.")
print message['some_context')
alert(T("Hey! Please don't do this!")
>
> - 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
-~----------~----~----~----~------~----~------~--~---
