- From: Eric Brunner-Williams in Portland Maine <brunner@nic-naa.net>
- Date: Tue, 16 Apr 2002 10:10:23 -0400
- To: Tom Garland <Tom.Garland@sun.com>
- cc: www-i18n-workshop@w3.org, aphillips@webmethods.com, brunner@nic-naa.net
> ... if my system or service doesn't have "locale X" installed, it can > obtain the requisite locale data (or call the function) from a trusted > external source and use that data to perform as if that locale were actually > installed locally. Preface: A locale-based approach to legacy, and contemporary data, meets requirments which can't be met otherwise. I'm trying to come up with use-cases where not having a locale is a real problem. I know of one, but it is atypical, using very small buffers, and a nightmare in several dimensions. Here, "not having" means going outside of the vendor's supported product range of solutions, which could be ONC-RPC it from some publication host. Outside of the handset, moving data to processing seems dubious. Getting the processing to the data the better course. Now the reason someone chose to use dynamic load to allow the arbitrary extant .so to provide the possibility of 3rd-parties writing their own new .so(s), without having to get someone in Building 5 or COSL to get this new code merged into a release or patch, and available at the next release or patch point. The cost of creating a new locale is quite low, relative to the cost of merging and maintaining new code in monolithic, statically bound, system libraries. I'm not seeing it. If one assumes ANDF or a JVM, some form of solving the system dependent portion of hetrogeneous locale provisioning, then OK. But in the absence of such ... In summary, locale announcement is good, XML has the charset and lang, which are necessary, but not sufficient. Finding the locale after finding which locale to use, may be a srvloc problem, I don't know. Anyone got a use case? Eric
Received on Tuesday, 16 April 2002 10:16:44 UTC