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