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')
>
> 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
-~----------~----~----~----~------~----~------~--~---
