What a Locale is.... (Re: [Fwd]: Response to Mark's message])

[Addison Phillips [wM]]

Peter wrote:

>Perhaps the only thing we can say a locale *is* is that it's an artifact
>of legacy implementations. I think your observations reflect that locale
>is not that useful a notion (apart from the fact that legacy
>implementations require them).

I dunno... locales really are the way that "legacy implementations" tag
their resources (that is the language-bearing files). The locale may also
have some impact on processing, but we can ignore this here.

In a distributed environment, what is important is finding a way to do what
Mark is calling Just-In-Time localization. That is, resolving data to a
string as late as possible. Locales have historically played a key role in
this process, in systems written in a wide variety of languages on many
platforms. The locale and language loading hierarchy is generally inferred
from Accept-Language in HTTP environments or from strategically places
xml:lang attributes in XML files.

In every language-aware web server or distributed system that I am aware of,
either a locale or a locale-like deterministic fallback search system is
used to load both static (such as HTML) and dynamic (resources, database)
content. These fallback systems are "legacy" only if we have something to
replace them with (like Unicode replaces legacy encodings). RFC3066bis can
help in this regard by providing a fix to the very long standing problem
with two distinct sets of resources ("language materials") falling back to a
single set that cannot accomodate both. Like Chinese, right?

It's easy to make fun of implementations. Let's focus instead on the problem
at hand (distinguishing languages appropriately). I have no objection to NOT
registering fully qualified values if that makes sense. Let's just be sure
we describe it well.

Best Regards,

Addison