2009/11/23 Yarko Tymciurak <resultsinsoftw...@gmail.com>
> On Mon, Nov 23, 2009 at 12:59 PM, Yarko Tymciurak <
> resultsinsoftw...@gmail.com> wrote:
>
>>
>>
>> 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')
>>
>
sorry - probably should have been something like this:
print T(message['some_context'])
>
>> alert(T("Hey! Please don't do this!")
>>
>
>
> (sorry - hit send prematurely)... so I'm suggesting some new, crisp
> concept, but of the same form; perhaps something like:
>
> T.default_language('it') # if you don't declare it in your app, it will
> be 'en-us' by default;
> ...
>
> error_message=T("This is an error message.")
>
> print message['some_context')
>
> @T.use_language('pl') # some temporary overide, only for the next block
> of code
> alert(T("To jest komunikat o błędzie"))
>
> How gluon finds any of these string is not important to the application
> writer. What is important in this example: by shifting (at gluon level) to
> a string-serving concept, and away from a translation concept - the last
> message (in Polish) does NOT need to exist at all in en.py;
>
> This raises some questions, as well as opens some doors. For example:
> Q: what language file would some tool put the last fine into?
> A: Well - the language of the current context (pl.py in this case).
>
> Q: How would I create an English translation of this?
> A: WIth tools; the underlying implementation should be hidden from the
> application writer.
>
> Q: What happens if I change the decorator to 'en'?
> A: Good question (e.g. with this new "concept" of contexts for language,
> what would be reasonable behavior?)
>
> .... and so on...
>
> But my biggest point: we are currently in the "translate" model, and should
> be careful to be explicit about that, since any crossing over the line to
> "serve-string" style of thinking about this requires new questions we have
> not even asked yet. We _might_ want to do that; it _might_ offer something
> useful, but right now, what is implemented is too fuzzy, and needs to get
> crisper - pick a way, and stick with it.
>
> - Yarko
>
>
>>
>>
>>
>>
>>>
>>> - 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
-~----------~----~----~----~------~----~------~--~---
