From: Edward H. Trager (ehtrager@umich.edu)
Date: Tue Apr 26 2005 - 09:42:26 CST
On Tuesday 2005.04.26 05:21:48 -0700, Andrew C. West wrote:
> On Mon, 25 Apr 2005 14:22:31 -0400, Patrick Andries wrote:
> >
> > Andrew C. West a écrit :
> >
> > >Guilty as charged. It is not at all obvious to me that it is not appropriate
> to
> > >use the Unicode names in a UI.
> > >
> > It is certainly a good thing.
> >
> > >I was thinking of releasing versions of BabelPad and BabelMap with all Unicode
> > >names expunged and "Search by Name" function disabled, just to please Jill and
> > >Peter; but then again I write software to please myself, not anyone else, so I
> > >think I'll leave things just the way they are.
> > >
> > If they are no memory or time constraints, allowing searching aliases
> > would be also good (as an option).
> >
>
> As you know, searching for aliases, as well as for Unicode 1 names, ISO
> comments, code chart notes and cross-references is already available through the
> "Advanced Character Search" function of BabelMap (and BabelPad).
>
> It would be trivial to allow alias searches within the main "Search by Name"
> function and/or to auto-correct Unicode typos (e.g. return U+FE18 when the
> search string "BRACKET" is entered); but as I see it, that way can only lead to
> the topsy-turvy world of Word, where the application's "intelligence" overrides
> user expectations. I suppose I could make it an option, but then too many
> options just ends up confusing, and the "average user" will probably have no
> idea what the "Search for aliases as well as character names in Search by Name"
> option means anyway.
>
> I was thinking about localised character names last night, and from my
> perspective there are severe practical problems to using them instead of the
> standard Unicode names in application UIs. Unicode character names are part and
> parcel of a character's identity, and so exist from the moment that a new
> version of Unicode is released, but localised names for new characters will in
> all probability only be available some time after the release of a new version
> of Unicode. Even with the expertise of WG2 participants such as Patrick, Alain
> et al. the French names for the Unicode 4.1 additions have not yet been
> finalised; when localised Unicode character names are created for dozens of
> locales, reliant on part-time volunteers, there will undoubtedly be a long time
> lag between the release of a new version of Unicode and the updating of the
> various localised name lists; moreover, some localised name lists will be ready
> sooner than others, and some more obscure locales may never get updated at all
> due to volunteers dropping out. I release new versions of BabelPad and BabelMap
> as soon as a new version of Unicode is released, and cannot wait indefinitely
> for all the localised names lists to catch up with the standard. If I change
> BabelMap/BabelPad to use localised character names based on the current system
> locale, what do I do for new additions to the standard for which names in the
> user's locale have not yet been defined ?
Apple has taken the correct approach to localization in OS X : a user is presented
a sorted list of language-locales, and the user simply places his or her preferred locales
at the top of the list. The computer then displays UI menus and messages using the
first choice when available, the second choice language when the first choice is
not available, the third choice when the second choice is also not available, and so
on. For example, I could specify "Français -> Espanol -> English" if I wanted.
Even if an operating system does not inherintly support this approach, there is
certainly nothing stopping a software designer from implementing it. So, for example,
when localized character names start to become available in CLDR (starting with, say,
the localized English, French and Finnish names), BabelMap/BabelPad could similarly
allow a user to set a localization preference list. If I chose "French -> English",
then BabelMap could display the character names in French, if the French localization
existed, followed by English if that existed, followed by the original non-localized
official Unicode name as a fallback. This would, I think, work very well for a lot
of people.
>
> And where does an application expect to get the various localised names lists
> from ? Does it store them internally (BabelMap/BabelPad store all Unicode data,
> including names, internally to avoid the overhead of parsing external files that
> may or may not exist on the user's system), or does it read them from file ? If
> the former, then the application may need to be updated with alarming frequency,
> especially as localised names may be prone to occasional revision.
The application could do any of the following:
(1) Parse XML files directly from a known application data directory.
(2) The application could contain a utility for converting XML files into a
compiled or pre-parsed format that the application would actually use.
(3) The application could be "intelligent" enough to recognize when new XML
files arrived in its data directory, and silently convert them to the compiled
format.
(4) The software distributor could provide the pre-parsed/pre-compiled localized
files on a web site which a user could download and place in the data directory.
In my opinion, a solution like (3) would be the best. This way, a user could just download
XML files from CLDR, and would even have the opportunity of customizing them if he/she were
not satisfied with some of the localized names.
Of course the application would only load the localizations that the user specified
in their preference list.
> latter, who is responsible for updating the user's names list files ? Will new
> versions of the files magically appear on the user's system as soon as a new
> version of Unicode is released or updates to one of the files is made (remember,
> not all computers are connected to the internet) ?
>
> So whilst it would be fairly simple to add an option to use either "Standard
> Unicode Character Names" or "Localised Character Names" to the UI, the
> practicalities mean that I won't be doing this for the forseeable future.
>
> Andrew
>
>
>
>
This archive was generated by hypermail 2.1.5 : Tue Apr 26 2005 - 09:22:11 CST