German as used in Liechtenstein
JFC (Jefsey) Morfin
jefsey at jefsey.com
Fri Dec 24 13:03:34 CET 2004
At 01:45 24/12/2004, Doug Ewell wrote:
> > I have 42624 locations in the UN/LOCODE. I have 33000 French cities in
> > my Web of France reference data base and more than 500 listed local
> > language associations I should attach to them. The algorithm I use
> > permits to roughly relate them to one of the 266 "business areas"
> > considering that such areas are also historical and cultural areas.
> > (For the time being I am focusing on European France only).
>
>My Thomas Guide has hundreds of thousands of public and private streets
>in Los Angeles and Orange counties.
Street listing is an obvious must, but today no many countries have
standardized their description (may be for radio frenquency maps?). However
there is a centuries old algorithm which permits mail to be distributed. I
am documenting the need of such a canvass algorithm. And I have no problem
in accepting RFC 3066bis tags as language "zipcodes".
>None of these is usable under RFC 3066bis or 3066 or 1766. There was a
>proposal many, many months ago to allow UN/LOCODE identifiers, but there
>was apparently no consensus for that level of precision in language
>tagging.
Sorry to tell you you are wrong. You currently propose UN/LOCODE with a
country neuronal level which is ISO 3166. What you want and only cas say is
"there is no consensus right now for that level of precision in RFC 3066bis
language tagging", what I support.
But you also say :
>Country-level tagging is probably not precise enough in all imaginable
>cases, but town-level tagging is probably unnecessary. As usual, the
>truth lies somewhere in between.
We are not in a "truth/lie" case. We are in an appropriate response level
case, with scores of different level needs. RFC 3066bis gives an urgently
needed patch and let it be blessed.
But what we need is a more flexible and well devised canvassing algorithm
permitting to consistently address all the not fully RFC 3066bis supported
needs, through solutions fully RFC 3066bis interoperable. They will most
probably be based upon and adapt the smallest granularity which is the
human being. Shakeaspeare English is not exactly Whodehouse English which
is not exactly 5th Avenue English which is not exactly my Franglish
(hopefully :-).
Also, an important point: languages are an important part, but for a
computer scripting is more. In the case of multi-scripted languages it
makes a real difference.
Another point important to consider is the country related synonyms. I am a
cofounder of Eurolinc for European languages to be supported on the
Internet and the web. One of our main interest is European multilingual
e-governement issues. When you create an automated registration form local
legally used synonyms are to be used, because a word can have locally added
meanings that is ported by another word in the same language but in another
country. A simple example is the name of Ministries, University Grades,
personnal situation, health status ... were people may not understand, be
mislead or hurt by a correct word used in a wrong way in their national
legal language flavor. You refer to language tags. Another form of tags are
icons. Which icon to use for a language version of a website - this is as
much important than a code : an icon is a tag for the brain.
Again, this is not to delay RFC 3066bis, but to speed it. I was not aware
of the work and I am glad you did it! It addresses a need and permits to
consider RFC 3066ter, from the experience from RFC 3066 towards RFC
3066bis, and from the real life users expectations and needs.
jfcm
More information about the Ietf-languages
mailing list