> The application isn't "english", it's "an application". Properly done, it
> should be internationalized and thus able to be an "Arabic
> application" when serving Arabic pages and English when serving English
> pages.
I totally agree. This is actually what I am trying to achieve and what I
was trying to convey to John. Unfortunately, the nature of the application
means that certain labels from the application are exposed to the user which
may be in a different language to the data they pertain. I have been using
the example of English for the application data and Arabic for the data from
the database. In reality, the application will be translated into several
(probably about 8 languages). The data in the database is stored in Unicode
and so could be in any language supported by Unicode...and the browser of
course. The actual data is maintained by users via a web interface. It
is conceivably possible that data can be entered by multiple users in
multiple languages...some of which RTL and some LTR. We will, of course,
allow the user to tag the data with a language identifier.
However, I guess my problem boils down to this.
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?
I don't think that examining all the data elements and saying well there's
70% RTL data so lets put the page in RTL. I didn't think that was
practical. Especially, if it causes means that one user is going to see the
same page in RTL or LTR based on selection criteria over the database.
My reasoning was that a user that has expressed a preference for a RTL
language would not mind seeing the page formatted for a RTL language.
Especially, if that there is a high probability that that data they will be
seeing is in that language. (If they have indicated a preference for that
language, then they would probably enter the data in that language.) I
know this reasoning is somewhat flawed but I am trying to the best with what
I can.
I would be interested to hear the opinion of a native Arabic or Hebrew (or
one of the other RTL language) speakers as to how they would prefer to view
a page such as that. My thought would be that such a person would have a
preference for a RTL page; their eyes would naturally scan RTL formatted
pages easier than LTR formatted pages.
Hell, if they have no preference then I can just leave the directionality of
the page to always be LTR...it's, obviously, less work! :-)
David Tooke
dtooke@interproinc.com
----- Original Message -----
From: <addison@inter-locale.com>
To: "David Tooke" <dtooke@interproinc.com>
Cc: "Unicode List" <unicode@unicode.org>
Sent: Friday, December 08, 2000 2:54 AM
Subject: Re: OT (Kind of): Determining whether Locales are left-to-right or
> Hi David,
>
> I sense a subtle (and not uncommon) disconnect in your last response.
>
> The application isn't "english", it's "an application". Properly done, it
> should be internationalized and thus able to be an "Arabic
> application" when serving Arabic pages and English when serving English
> pages. You might have instances where an "English application" is
> *showing* some Arabic data, in which case you have some Arabic data on an
> English formatted page.
>
> Now: the data locale, page (user) locale, and server locale are three
> separate, independent things and each has a certain validity under certain
> circumstances. Just because you're showing the date stamp for some event
> in Riyadh (sp?) doesn't mean you should use an Arabic date format (if the
> user's locale is English). Similarly, the date stamp for an event in
> London *would* be in an Arabic format for an Arabic user, no?
>
> Trying to rely on the range of characters or some heuristic to determine
> what the data locale is implies a hole in your database schema. The page
> layout will vary by *user* locale, but data presented in it may be
> formatted for its own locale (for example, an Arabic piece of text, say a
> customer's name, will be presented RTL *within* a generally LTR page).
>
> So, in short, you need to negotiate a locale with the user in your
> application and use that to determine the overall page layout. *Within*
> that page there will be specific instances (or not) of the data locale
> being used to format content.
>
> An "Arabic application" run from your server will have directionality tags
> in the HTML (at least for modern browsers) which will greatly assist the
> "relayout", plus it will load explicitly RTL page elements (such as
> graphics, etc.) and use an Arabic locale for formatting non-String
> datatypes.
>
> Good luck,
>
> 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 Wed, 6 Dec 2000, David Tooke wrote:
>
> > > I think it would be very weird to render an English-language
application
> > with
> > > labels on the right of their fields, just because the user also
> > understands
> > > Arabic.
> > The application is a database application where the majority of fields
are
> > from a Unicode database and user-entered. Their text is likely to be in
> > Arabic. Therefore, as far as I am concerned, the *content* of the page
is
> > in Arabic not English despite it being an English application. So the
page
> > should be formatted as if it an Arabic page with some English text.
> >
> > As it is a Unicode database; I do not want to try to determine what
> > language/script *exactly* is being used. That would involve scanning
the
> > Unicode characters and a lot more giggery pokery than I need.
> >
> >
> >
> >
>
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:21:17 EDT