On Tue, Nov 24, 2009 at 2:31 PM, mdipierro <mdipie...@cs.depaul.edu> wrote:
>
> I agree with you. Besides most of the current messages have been
> written by Fran and Jonathan who are both in Europe. How are we to
> decide what is en-us and what is en-uk?
>
as I think about this statement, I think that 'en' _is_ the correct
setting, as it says "uk or us styles / spellings might be mixed",
and if someone has an audience sensitive to this, they would _want_ to
provide (say) a 'en-uk' and 'en-us' translation...
yes, this seems like the right thing, to set it to 'en';
also, as I read the IETF stuff, I _like_ "content_language" for the name of
the translator function I added to set this
T.content_language() says a couple of things:
It says clearly what the source language is;
It removes the ambiguitiy of "languages" - that is an "accept", not a
"content" thing, and - indeed - is somewhat clearer about what the code does
/ should do (that is, process a list of accept-content, and match it against
the apps either content-language, or available translation files).
What do you think?
- Yarko
> On Nov 24, 2:28 pm, Thadeus Burgess <thade...@thadeusb.com> wrote:
> > new install on ubuntu is [en-us, en].
> >
> > I think it should just default to 'en', if you want uk english or us
> > english, then these are different languages, and should be forced.
> >
> > -Thadeus
> >
> > On Tue, Nov 24, 2009 at 2:25 PM, Yarko Tymciurak <
> >
> > resultsinsoftw...@gmail.com> wrote:
> > > On Tue, Nov 24, 2009 at 2:10 PM, Thadeus Burgess <
> thade...@thadeusb.com>wrote:
> >
> > >> Why can't it just be 'en'?
> >
> > > It probably could.... I just checked the request environment in a "new
> > > install" browser I've never used ("Konquerer on Ubuntu) and web2py is
> > > picking up
> > > http_accept_language=['en-US', 'en']
> >
> > > So if a client had ['en-UK', 'en'], if no translation file for
> en-uk.py
> > > existed, it would "pick up" the en, and deliver in the site / apps
> > > internally encoded strings (which would be appropriate).
> >
> > > If this is consistent, that the ordering from a client is first
> > > country-specific, then country-agnostic, then this would probably be
> > > reasonable. The only downside: if I complained (from UK for example)
> > > about "color" being misspelled (if I think it should be "colour"), then
> the
> > > app is not being explicit enough about what it says it's servering.
> >
> > > Having said that, I am now convinced (pretty well) that 'en' should not
> be
> > > part of the gluon/languages initialization. I think it should be
> explicit,
> > > and only one language - the more specific declaration, not the broader
> one.
> >
> > > So - I think that the original patch I sent (with only 'en-us') is
> correct,
> > > and what we should use.
> >
> > > - Yarko
> >
> > >> -Thadeus
> >
> > >> On Tue, Nov 24, 2009 at 1:01 PM, Yarko Tymciurak <
> > >> resultsinsoftw...@gmail.com> wrote:
> >
> > >>> a short version of this (context: U.N. type of meeting):
> >
> > >>> you (in effect) changed the translator initialization code to say
> "The
> > >>> default language [string] I will present you is TWO lanugages",
> Massimo, it
> > >>> is _as if_ you said something like: "I'm speaking Itailan, or another
> way
> > >>> for you to think of it - I am speaking Russian"
> >
> > >>> It cannot be! I cannot "hear" you that way - I have to know _which_
> > >>> language, if I am to have any hope of "hiring' the right translator!
> >
> > >>> There is no "can of worms" in the _problem domain_; it is in your not
> > >>> being specific enough in what you told me you would be speaking!
> >
> > >>> :-)
> >
> > >>> On Tue, Nov 24, 2009 at 12:51 PM, Yarko Tymciurak <
> > >>> resultsinsoftw...@gmail.com> wrote:
> >
> > >>>> On Tue, Nov 24, 2009 at 12:37 PM, mdipierro <
> mdipie...@cs.depaul.edu>wrote:
> >
> > >>>>> I put en-uk not en-gr.
> >
> > >>>> right, en-uk; from a software analysis perspective, only one
> language
> > >>>> should be in the initialization (addition of a non-country specific
> version
> > >>>> of said language should also be acceptable).
> >
> > >>>> You see, this is a big can of worms. How do you
> > >>>>> know that the default application is in en-us and not en-uk?
> >
> > >>>> This is not can of worms at all: you do not "know" - you declare;
> the
> > >>>> patch as you made it, you in effect declared TWO languages (two
> contry
> > >>>> specific versions of the same base language, but for understanding
> this it
> > >>>> is clearer to ignore the "non-country-specific" part - and just
> think of it
> > >>>> as TWO languages.
> >
> > >>>> When you look at this as TWO languages, and your translation class
> code,
> > >>>> you will see that once any language is in accepted languages, it
> will not be
> > >>>> picked up from the application's languages/*.py file.
> >
> > >>>> And that is the bug - you should not be initializing two languages,
> > >>>> because you prevent the (potential) translations of either of them
> from
> > >>>> being picked up, and served to the client.
> >
> > >>>> I can see that you considered this as "all english" - but if you
> think
> > >>>> of this as separate languages, and in terms of how you read-in the
> language
> > >>>> translation files, then the mistake is easy to see.
> >
> > >>>>> This is
> > >>>>> way it was not specified before. This is why I am still not
> completely
> > >>>>> convinced it is a good idea not to let the users be explicit.
> >
> > >>>> You are not looking at this in the right way; you are wrong - look
> in
> > >>>> terms of your design, and it should be immediately clear.
> >
> > >>>> For example, think about setting "default language" as 'it' and 'es'
> ---
> > >>>> and try to walk thru the logic in gluon/languages.py - then it
> should be
> > >>>> very clear that only _one_ language should be initialized.
> >
> > >>>> After that point, you can extend this to see that adding a
> non-country
> > >>>> specific language to the initialization does not cause any bad
> behavior, and
> > >>>> can be useful (help deliver the language appropriately more often).
> >
> > >>>> Just remove 'en-uk' from this patch, and it will be fine.
> >
> > >>>> - Yarko
> >
> > >>>>> On Nov 24, 12:14 pm, Yarko Tymciurak <resultsinsoftw...@gmail.com>
> > >>>>> wrote:
> > >>>>> > On Mon, Nov 23, 2009 at 2:25 PM, mdipierro <
> mdipie...@cs.depaul.edu>
> > >>>>> wrote:
> >
> > >>>>> > > Yarko's patch is tentatively in trunk since nobody seems to
> > >>>>> complain
> > >>>>> > > about this change in behavior.
> >
> > >>>>> > You made an error with the change you made in this patch: you
> added
> > >>>>> 3
> > >>>>> > languages, 'en', 'en-us', and 'en-gr';
> > >>>>> > This should only be either 'en-us' (the language of the distro),
> or
> > >>>>> at most
> > >>>>> > ['en-us', 'en'].
> >
> > >>>>> > As you've done it, you've introduced another bug.
> >
> > >>>>> > Putting en-gr will prevent 'en-gr' from being seen if it is a
> > >>>>> translation
> > >>>>> > file UNLESS application FORCES a base language (for example).
> > >>>>> > This means that 'behavior' and 'behaviour' will not be
> > >>>>> appropriately
> > >>>>> > picked up from a languages/en-gr.py file UNLESS EACH application
> > >>>>> forces
> > >>>>> > language to 'en-us' (or some other, non-[en-gr] language).
> >
> > >>>>> > For example, a 'en-us' app will NOT be able (with this app) to
> > >>>>> correctly
> > >>>>> > display to someone in England, who has their language set as
> 'en-gr'.
> >
> > >>>>> > Please fix this in trunk: to ['en-us']; ['en-us', 'en'] would
> > >>>>> also work
> > >>>>> > appropriately and be acceptable.
> >
> > >>>>> > - Yarko
> >
> > >>>>> > > Massimo
> >
> >
> >
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
