So, suppose all the data from the database is in Hebrew...and the user's
browser is set to Hebrew. You are saying that because we have some headings
in English; the entire page should be formatted LTR not RTL.
I have to disagree. The *content* of the page would be Hebrew. The
headings are simply utilitarian, they shouldn't affect that.
I think we have established it would be impractical to base the
directionality on that of the database because of the presence of mixed
languages...in order to create a uniform experience for the user.
I don't think it should be based of the application. A Hebrew document
written by a user on an untranslated word processor is *still* a Hebrew
document.
This just leaves the users locale. I know you balk at having it like your
second example, but what is so bad about it? It looks kinda strange to you
and me. But would it to a native speaker of a RTL language? I would be
interested in their opinion. (I am assuming you are not a native speaker of
a RTL language.)
----- Original Message -----
From: "John Cowan" <jcowan@reutershealth.com>
To: "Unicode List" <unicode@unicode.org>
Cc: "Unicode List" <unicode@unicode.org>
Sent: Thursday, December 07, 2000 11:01 AM
Subject: Re: OT (Kind of): Determining whether Locales are left-to-right or
> This message is best viewed with a monowidth font.
>
> addison@inter-locale.com wrote:
>
> > For example, I might look at a page that contains an very large result
set
> > from a database query, presented as a table. The results would comprise
> > 90% of the text, let's say, of the document. If the results are all in
> > Hebrew, should I re-layout the page, if the headings and the footer and
> > other information is in English?
> >
> > I think the answer is "no"--in other words, the opposite of what you're
> > saying.
>
> So far so clear. The page as a whole is LTR with RTL inclusions,
> namely the database content, like this (as usual, lowercase is
> LTR text, UPPERCASE is RTL text):
>
> top dogs by country
>
> country firstname lastname
> ------- --------- --------
> u.s. bill clinton
> israel DUHE KARAB
> u.k. tony blair
> syria RASHAB DASSA-LA
>
> > If the *user* locale is en_US, then the page should be laid out
> > for that user's preferences, even if the data itself (in individual
> > fields) is RTL.
>
> But now your message seems to go off the rails. If the application is
> *not* localizable in Hebrew (it insists on presenting header, footer,
> etc. in English), but the browser's locale setting is "il-he", you want
> the page to be presented RTL with the header and footer as embedded
> LTR, like this?
>
> top dogs by country
>
> lastname firstname country
> -------- --------- -------
> clinton bill u.s.
> KARAB DUHE israel
> blair tony u.k.
> DASSA-LA RASHAB syria
>
> > > If a user requests a page that contains data that could, potentially,
be in
> > > multiple languages. What criteria does one use to determine
directionality
> > > of the page? The directionality of the *text* is implied by each
data
> > > element itself. But what about the page?
>
> My view is that the base direction of the page is the direction of the
fixed
> elements on the page. If these fixed elements are in English, the base
> direction is always LTR. If the fixed elements are localizable based on
> the browser settings, then whatever language/script they are localized
> into determines the base direction.
>
> In short, Example 1 good, Example 2 bad, no matter what the browser
setting is.
> Of course, if the application can cope with an "il-he" browser setting and
> render the fixed elements into Hebrew, then the base direction should be
> RTL.
>
> --
> There is / one art || John Cowan
<jcowan@reutershealth.com>
> no more / no less || http://www.reutershealth.com
> to do / all things || http://www.ccil.org/~cowan
> with art- / lessness \\ -- Piet Hein
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:21:17 EDT