Re: [g-a-devel]recent gnopernicus "Language" files and support

[Bill Haneman <bill haneman sun com>]

Hi Janina:

Nice to hear from you.

On Sat, 2003-01-25 at 16:23, Janina Sajka wrote:
> I want to speak up in strong support of appropriate approaches that
> support on the fly language changes. Frankly, it should even be possible
> to change laanguage in the middle of a document given the appropriate
> XML/HTML tagging.

The trouble is, most documents don't have such tagging.  And there's no
current way (to my knowledge) that applications can indicate what locale
or language they are currently operating in.

> I have no idea whether GNOME is multilingual, or simply supports
> numerous I18N defaults. 

GNOME is based on the various Unix and international standards with
respect to language and locale (such as they are).  GNOME is "fully
internationalized" in that respect, and in fact supports a very wide
base of languages and locales.  

However in the UNIX/Linux world (and, in fact, generally), there is very
little notion of a "multilingual" application in the sense of an
application that can simultaneously support multiple locales. 
Applications can use Unicode and encodings such as GNOME's "UTF8" to
ensure that they can handle multilingual strings and data.  

However the on-the-fly translation and localization mechanisms that are
used to provide multilanguage application support make the assumption
that every application runs in an environment with a single "locale". 
This is usually a reasonable assumption, and certainly the concept that
an application can simultaneously have multiple locales is inherently
troublesome.

Applications like gnopernicus are a very unusual case in that they are
interposed to some extent between an application and the end user.  The
"correct" approach is generally said to be this: an application is
solely responsible for the localization of its interface, and all
translation of strings is the responsibility of that application
according to its locale, using standard localization mechanisms.  Thus a
user's desktop can feature programs running in several locales,
potentially.  The "correct" case for gnopernicus would be to present to
the end-user the same strings which the applications themselves present,
in whichever locale they are using.  Gnopernicus itself runs in a
locale, thus messages from gnopernicus would also be localized.

The desire to do something different arises if users wish to have
messages from gnopernicus presented not in gnopernicus' own locale, but
in the locale of the "foreground" application or the application in
whose context the user is operating.  It is not clear to me that this is
actually the best approach (it leads to inconsistent messages from
gnopernicus, for instance) and it can potentially break existing
localization features since there is no standardized means of
accomplishing this behavior.

If and when we have a standard language tagging mechanism for text
content, then I believe that it is reasonable and correct to provide
some gnopernicus strings in the "content" locale rather than
gnopernicus' locale.  The more general case of changing gnopernicus'
message localization according to the application context is, in my
opinion, more problematic and I don't think we should do it until we
have identified at least some proposed standards in this area.  In other
words, I think the language tags are something we can look at now, but
the general case should be deferred.

In any case, gnopernicus will work with the existing GNOME language
framwork and can be made to speak its messages in any language or locale
for which translations (and voices or braille encodings) are available. 
If the gnopernicus locale matches the application locale (the "normal"
GNOME desktop case), then gnopernicus and applications should work
seamlessly with these applications.  Content which is in another locale,
or multi-language content, should also work well provided braille
encodings and/or speech engines are available, if the content contains
language tags. 

best regards,

Bill

> So, I can speak to the appropriateness of any
> particular approach. I do know that AT has to date failed miserably in
> this regard--no doubt a reflection of too much U.S. influence in the AT
> industry. It would be very good for that to change, of course, and it
> would be most delightful if GNOME accessibility, Mozilla, and
> Gnopernicus could come out of the gate, with version 1.0, setting a
> standard for others to emmulate.
> 
> 
> 
> remus draica writes:
> > From: remus draica <rd baum ro>
> > 
> > 
> > Hi Michael,
> > 
> > The idea is to change language at run-time.
> > Let suppose that user is using gedit with english interface. He opens a 
> > document in german. If somehow gnopernicus can find that the document is in 
> > german, it will display characters on braille using german translation table 
> > and will ask speech to speak in german.
> > 
> > A more general idea is:
> >   - gnopernicus is started with LANGUAGE=en
> >   - one application is started with LANGUAGE = de and other with LANGUAGE = ro
> > when gnopernicus read first application is nice to show on braille and to 
> > speak in german, and, for the second is nice to use romanian.
> > 
> > If these scenarios are not realistic, please let me know.
> > 
> > Best regards,
> > Remus  
> > 
> > On Tuesday 21 January 2003 12:53, you wrote:
> > > Hi Remus,
> > >
> > > On Fri, 2003-01-17 at 12:21, Bill Haneman wrote:
> > > > It's unusual for users to choose a language for an application other
> > > > than via the standard environment variables.
> > >
> > > 	Quite; what is the purpose of that ? ultimately, all the apps that are
> > > being poked at via at-spi, will be returning strings localised to the
> > > values of the standard environment variables; what advantage is there
> > > then to having one app in a different language ? seems like it could be
> > > a big source of confusion:
> > >
> > > 	 "why doesn't the language change when I change it in
> > > 	  gnopernicus"
> > >
> > > 	etc. since the language can only be effectively changed at login time.
> > >
> > > 	HTH,
> > >
> > > 		Michael.
> > _______________________________________________
> > Gnome-accessibility-devel mailing list
> > Gnome-accessibility-devel gnome org
> > http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
-- 
Bill Haneman <bill haneman sun com>