Subject: [Ltru] does the Draft gives all the guidelines required by the Registry

From: Jefsey Morfin <[email-masked]>
Date: Wed, 06 Jul 2005 15:17:01 +0200

This WG has to reorganise a IANA registry (since for the time being the RFC 
3066 IANA Registry is considered). Here is the most recent registration in 
that Registry. I will try to underline some of the complexity and confusion 
it contains by lack of RFC guidance, so everyone may check that the current 
Draft addresses these lacks and provides the guidelines and forms necessary 
to the language tags reviewers .

This quick review will probably be useful for those on this list who work 
on an ISO 11179 metamodel for languages.

>LANGUAGE TAG REGISTRATION FORM
>Name of requester          : Karen Broome
>E-mail address of requester: [email-masked]

This information is of no interest to the users. It gives Karen Broome and 
possibly Sony a stewardship on the American Spanish some could seriously 
object.

 From this who is the es-419 steward in 2105?

>Tag to be registered       : es-419
>English name of language   : Latin American Spanish

Do we have a definition of language? Can the concept of "Latin American 
Spanish" be accepted as a language or as a metalanguage or as a variant or 
a language family, etc. according to this definition? Obviously references 
to ISO 639-4 will help but are not available yet.

>Native name of language (transcribed into ASCII): espanol de America 
>Latina, espanol latinoamericano

This information misses the French name of the language.

>Reference to published description of the language (book or article):
>
>Lipski, John M. 1994. Latin American Spanish. Addison Wesley 
>Publishing  Company.
>Martin, Patrice. 2005. "The Quest for El Dorado: A Single Spanish for 
>All." Multilingual Computing & Technology. Vol. 12, No. 6

This kind of quote are of interest to some, but may also be contentious. I 
am not sure there are guidlines enough to avoid the contention. I also 
wander why such an information would be provided for this langtag while it 
is not for other. There should be only one metamodel for a concept in order 
to avoid conflicts.

This part is alse a partial attempt to transform the es-419 concept into a 
value (registration by reference, instead of registration by declaration). 
I am not sure that this value is explicit enough and can not be considered 
as a registration by real documentation . It can be explicit for a 
linguist. I am not sure it is explicit for all the users. Have some rules 
been given that a computer or a non linguist could use to distinguish 
es-419 from es?

>Any other relevant information :

Same remark as above.

>It is a common business practice to localize content into a neutral 
>version of Latin American Spanish to serve all or most Spanish-speaking 
>regions in Latin America. This code is intended to identify this neutral 
>variant of Latin American Spanish and distinguish it from Castilian found 
>in Europe.

This is a standadisation text. "all or" does not fit (it seems however in 
line with the lack of clarity of RFC 3066 which the advantage of RFC 3066 
as it can accept much). This rises the question of the American Spanish: 
what are the differences. What is the New Mexico Spanish?

>This tag is intended for use on content that has been tailored for Spanish 
>audiences throughout Latin America.

"use on content": I do not understand the full meaning. I expected 
identify, describe ...?
"audience": is this a generic enough name? Is the Registry to consider the 
mode or the language? The use of "audience" seems to imply that the tag is 
to characterise "out" streams (IETF takes care of network protocols).

>  It is not a collection for all Latin American Spanish varieties; it 
> merely indicates that the author made choices in vocabulary, grammar, 
> spelling, etc. that would make the content reasonably acceptable to speakers

Here we have a confusion. The text both speaks of author (source of 
content) and of speakers (other sources of content). I suppose that he 
wants to say "readers". This kind of confusion would be removed if instead 
of having to comment the tag, the examiner was provided a form giving him 
strict guidlines (identical for every tag).

>  of most or all  Latin American Spanish varieties. (This tag does not 
> imply any further details regarding what those choices may have been, however.)

This seems odd in a standardisation comment as it says that two people may 
legitimately have two orthogonal understandings of es-419.

>This tag is intended primarily for cataloguing of localized content and 
>resources, rather than for specifying language preference on retrieval.

This insist on the "out" or "sending" definition of a langtag. I have no 
problem with that, except that through "Latin America" the specification is 
through an "audience", i.e. through the expectation of a population? Or 
does that means that the langtag is to identify the way an authors responds 
to the expectations of a local population expressed in its own way to 
speak. I have no objection to that (it corresponds to a relational 
definition), but the definition should be explicit somewhere and scalable. 
Scalable means that the definition should be generalised and its technical 
implications (relation modes, non human interlocutors, etc.) should be 
addressed, so the examiner and the user of the registration form has a 
protocol defnition/documentation tool;

>Ideally, a system should be able to deliver content labelled with this tag 
>in response to requests for any specific Latin American Spanish variety, 
>including but not limited to the following:

the "not limited" seems to create a confusion with the "419" from the UN 
list. Unless it is a way to characterise the speaking audiences considering 
themselves attached to an es-419 community. I have no problem with that 
since it would be an IETF consistent definition attaching a language to an 
indentified network. But  the notion should be generalised and its 
implications measured since they are certainly one of the basic elements of 
CRCs (Context and Reference Centres). But then we fall into the alanysis of 
Referents and Context issues which are the keys to the "not limited" vs. 
not "universal". In Internet architecture this means lingual classes.

>es-AR, es-BO, es-CL, es-CO, es-CR, es-CU, es-DO, es-EC, es-FK, es-GT, 
>es-HN, es-MX, es-NI, es-PA, es-PE, es-PR, es-PY, es-SV, es-UY, es-VE.
>
>Of course, systems can also be implemented to offer this tag as a 
>user-preference option,

Good. So we also have the langtag as a "in" descriptor. But here we have a 
partial decription: we have user preference but ignore if we can use it as 
a user capacity description. Can we use the langtag for language 
negociation and relation tuning towards best person to person 
interintelligibility. Also we have no hint about the kind of relation: is 
that a one to one, one to many, many to many? Is the negociation between 
pairs (senders or receivers) also possible in using the tag?

>  and a server should deliver content labelled with this tag when 
> requested for the same.

Why? Does the Draft mention that SHOULD. What is the fall back possibility 
if it cannot. Up to now we are in a fluid human to human environment (also 
imposed by the current Draft). All the sudden we are on a machine to human 
(web site), machine to machine (web service), machine to underfined (mail, 
broadcast) environement.

>On the other hand, it is not valid to assume that a request for "es-419" 
>can be serviced by returning content labelled as es-AR, or es-BO, es-CL, etc.

Accepted. But is this the proper place to see this explicited? Should it 
not be part of warnings printed in the Draft defined form. Which other 
warnings should be provided to the user?

>It would be appropriate to deliver content labelled with this tag in 
>response to the more generic request, "es" (cf. section 2.5 of RFC 3066).

The wording seems extermely confusing. Why to use a specific es-419 if the 
wording is appropriate? At least priorities should be given and described: 
es-419 before es seems OK, but is as-AR to be delivered before or after es?

I do not think these are minor questions. I am sure they belong to the 
Charter. I am not sure they belong to the Draft.

jfc

_______________________________________________
Ltru mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ltru