Tex,
Locale is a weak concept. However, it is a "stronger" concept than
"language", which is how David was referring to pages and page
contents. The "language" of a page doesn't fully capture the *other*
formatting issues that his software will need to be aware of in order to
fully internationalize.
So I have slavishly used the term "locale" instead of language to try and
make the point that there is more to proper page formatting than just
loading the right text and graphics.
I agree that user's have more complex needs and desires than a monolithic
locale can provide. Since I frequently set my browser (directly or
indirectly) to "request" various non-English locales (often in languages I
don't speak, such as Korean), I know all too well the frustration of
having "no way out" of the programmer's assumption that I actually *want*
Korean ;-).
So:
I'm engaged in trying to move the conversation from "language" to
"locale" (and showing that more than one can be in operation
simultaneously: failure to recognize this is a common I18n fault in Web
and C/S systems)
Your point is that I should be moving from "locale" to "user
preferences" (a common failing of internationalized systems). I wish you
could have been at the meeting *I* was at yesterday afternoon ;-)
Best regards,
Addison
===========================================================
Addison P. Phillips Principal Consultant
Inter-Locale LLC http://www.inter-locale.com
Los Gatos, CA, USA mailto:addison@inter-locale.com
+1 408.210.3569 (mobile) +1 408.904.4762 (fax)
===========================================================
Globalization Engineering & Consulting Services
On Fri, 8 Dec 2000, Tex Texin wrote:
> Addison,
>
> I think locale is a weak concept to begin with, but
> I can accept that it is good enough for initializing a set of
> properties to approximately what a user might want.
>
> Once those settings are made, unless the user wants to make
> a gross change in all of the settings, I let him change
> the individual properties.
>
> A familiar example, is Windows regional control. You can choose
> a region which sets many properties. The user can then
> go and override a specific number, date, time, etc. format.
> Changing the date format shouldn't require the user to pick
> another locale or implicitly change locale.
>
> If overriding some property was an operation that was frequently
> performed, then
> I could see creating a new personalized locale for the user.
> i.e. ar_EG_tex for Egypt with a modified date format...
>
> I don't think most users are familiar with all of the locales
> and what property settings they use. Therefore I think it
> is only a very gross setting, which the user might tweak
> to meet their needs more exactly.
>
> I think we are in agreement everywhere else.
> (Hey, it's kind of like we are using the same locale with
> me overriding one property! ;-) )
> tex
>
>
> addison@inter-locale.com wrote:
> >
> > I think I see what Tex is saying. He's saying that the DATA locale may
> > affect display of some page elements. For example the table containing
> > result sets might be laid out RTL if the result set is RTL. This implies
> > to me, however, that the result set has an intrinsic locale, as opposed
> > to just specific data in specific fields.
> >
> > If the result set is "multilingual", I don't think that the data locale
> > should affect the chrome of how the result set is displayed. If the result
> > set is *always* within a single locale then this might be a different
> > story.
> >
> > I also agree with Tex that the user must be provided with a way to
> > override the user locale that the browser negotiates with the server. But
> > (I think) I differ with him in thinking that the new setting should result
> > in a new user locale (e.g. select ar_EG to see an Egyptian Arabic RTL
> > layout, select en_US to see a US English layout, etc.).
> >
> > Which means that you may wish to provide for non-localized but RTL laid
> > out versions of specific locales if this is a common requirement of your
> > application (e.g. an ar_EG locale page that is not actually translated
> > into Arabic, for example)
> >
> > Best Regards,
> >
> > Addison
> >
> > ===========================================================
> > Addison P. Phillips Principal Consultant
> > Inter-Locale LLC http://www.inter-locale.com
> > Los Gatos, CA, USA mailto:addison@inter-locale.com
> >
> > +1 408.210.3569 (mobile) +1 408.904.4762 (fax)
> > ===========================================================
> > Globalization Engineering & Consulting Services
> >
> > On Thu, 7 Dec 2000, David Tooke wrote:
> >
> > > > Since you have the technology to flip the page direction, it is easy to
> > > make a button override. And as
> > > > there are examples where the user's locale is wrong for establishing the
> > > page direction, it seems silly to me > to ask the user to change his locale
> > > Tex,
> > > I appreciate what you are saying. I do think, however, that the user's
> > > selected locale should establish (at least initially) the page direction. I
> > > can see that we should probably allow the page direction change as well as
> > > the locale change. I really think that the locale should set the default
> > > for the page direction. As I said before, I thinking switching between an
> > > Arabic locale and US English *should* flip the page direction. It seems
> > > fundementally wrong to have the user have to make that switch as well as
> > > changing the locale. I think having the locale as ar_EG and the direction
> > > as "LTR" or the locale as en_US and the direction of "RTL" should be the
> > > exception rather than the rule. The user should have to explicitly set
> > > these states. Otherwise ar_EG = RTL and en_US = LTR.
> > >
> > >
> > >
>
> --
> According to Murphy, nothing goes according to Hoyle.
> --------------------------------------------------------------------------
> Tex Texin Director, International Business
> mailto:Texin@Progress.com +1-781-280-4271 Fax:+1-781-280-4655
> Progress Software Corp. 14 Oak Park, Bedford, MA 01730
>
> http://www.Progress.com #1 Embedded Database
>
> Globalization Program
> http://www.Progress.com/partners/globalization.htm
> ---------------------------------------------------------------------------
>
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:21:17 EDT