Hi David,
Actually, I think that the directionality of the page *CONSIDERED AS A
WHOLE* is directly related to the locale of the user.
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. 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.
IOW, locale has more than one level and you can have more than one locale
on a page... but the "overriding" locale--the "page default" should go
with the USER'S language preference, not with the specific data currently
being retrieved. That way you can still do reasonable things when mixing
disparate languages in the same page. It also means that the user
experience will be homogenous during a session---once in the RTL layout,
always in the RTL layout.
thanks,
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:
> > 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