> >For (1) we must urge the client developers to make their
> >program internationalized - preferably through the standardized
> >"i18n" methods. Some work is being done for at least Mosaic (in
> >Germany and in Sweden), but apparently not in cooperation with
> >the developing team, with all the disadvantages that entails.
>
> As I understand i18n, it is not suitable for anything we should
> be envisioning for WWW. It is not a multilingual standard,
> but a method for helping software developers localize their sys-
> tems. The distinction here is critical. Localization is the
> process of gearing a package for one specific locale. This is
> not a method for generalizing display methods for multilingual
> use.
I think you are mixing (1) and (2). I was referring to just (1)
here: the possibility to localize the client. In our research
and education environment we would like to offer our students
the Mosaic user-interface in Swedish and that Mosaic fetches in
the first place Swedish-language documents if such exist, else
English. In parallell to this, our non-Swedish guest
researchers must be able to use just English language. The i18n
methods could make the user-interface choice possible through
the use of "locale" settings, still having just one binary
program file. The default document language choice could also
be controlled by "locale", but if a language priority list is
desired, additional "preferences" settings is required.
Peter Svanberg, NADA, KTH Email: psv@nada.kth.se
Dept of Num An & CS,
Royal Inst of Tech Phone: +46 8 790 71 40
S-100 44 Stockholm, SWEDEN Fax: +46 8 790 09 30