Re: dynamic language switching

On Nov 26,  8:53pm, Bob Jung wrote:

> Jim Saunders wrote:

> > Chris Lilley wrote
> > > A further example, not mentioned at the time, is the public access
> > > terminal or kiosk - internet cafes, tourist information services,
> > > library terminals, hotel room terminals. Any situation in fact where
> > > the machine and the browser stays put and there are multiple users.

> > This is the best example that I've seen to date. Keep them coming,
> > what other business models absolutely require on the fly changes to
> > the localization rather than exiting the application to change
> > localization.

> Playing devil's advocate:
noted

> On the other hand, most kiosk systems I've seen (not that I've seen
> very many) hide the platform, and the kiosk application takes over
> the entire UI.

I have seen a lot of public access systems, and I agree that at their
most specialised they do attempt to hide the platform (a memorable
event on the journey back from the Sevilla symposium was the active
model of Barcelona airport, with a touch screen proudly displaying
the text "BDOS error on A:").

On the other hand, the typical internet cafe setup is simply a bunch
of PCs or Macs running some browser, you buy connect time and use an
already running browser.

>  In this model, there is a need to for the content
> to dynamically switch UI, but not necessarily the browser.

Whether the UI language is switched using a menu, a special page of
content with flags, or a secret handshake is an implementation issue.

> The public access terminal example might be different. If it's
> restricted to just web browsing, then dynamic UI might be nice.

Grin. Nice. I sentence you to four hours attempting to work with a
browser whose menus are in Urdu.

> However if the usage includes email/groupware functionality,
> then each user probably will want to "log-in" somehow and not
> just sit down in front of an already running browser.

That is an extra level of functionality and would indeed provide
even higher levels of productivity. As one of those options would
undoubtedly be the specification of the user interface language,
however,this observation does not really take us much further forward.

> Multiple user support is a larger issue than just switching UI.
> This may require multiple copies of user preference data.

Only if the users each use the system more than once. Last time I
used a cash machine in a different country, it offered me a selection
of different user interface languages. It didn't store my preference,
since the chance that use the same cash machine at the same airport is
somewhat slim.

> Is there
> a need for dynamic run-time switching of such data or just the
> ability to switch at launch time (equivalent to logging in)?

Being able to switch at launch time is certainly better than having to
run a whole different application. But how would this be done - using
some command line option? Awkward, if the browser is started by clicking
on an icon.

A separate starter application, perhaps, that constructs a
baroque command line behind the scenes and then call s the browser?  But
then you need to define a whole user interface for it, prefereably with
help optiona and so on. This takes effort.

What many people are doing nowadays is using a browser to produce the
user interface. For example, the configuration of Netscape servers
uses a browser as the user interface. So, launch a browser that offers
the option of changing the UI language and then starts another
browser ... no no no, too slow. How about the first browser just keeps
running with the new UI language?

<grin>

-- 
Chris Lilley, W3C                          [ http://www.w3.org/ ]
Graphics and Fonts Guy            The World Wide Web Consortium
http://www.w3.org/people/chris/              INRIA,  Projet W3C
chris@w3.org                       2004 Rt des Lucioles / BP 93
+33 (0)4 93 65 79 87       06902 Sophia Antipolis Cedex, France

Received on Wednesday, 27 November 1996 10:02:13 UTC