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 01730http://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