RE: ISSUE-88 - Change proposal (new update)

Hi.

 

From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> 
Date: Sat, 15 May 2010 02:04:38 +0200


Mark Davis , Fri, 14 May 2010 11:13:26 -0700:

>> I'm guessing that the best characterization of "audience languages" 
>> is that someone who doesn't speak one of "audience" languages would  
>> not find the document as a whole to be understandable.

> Content-Language is just a way to reach and/or define an audience. So 
> one could very well define an audience which did not understand the 
> text. What yields the result the author wants w.r.t. targeting an 
> audience, is what is right. E.g. Content-Language may also be used to 
> present different non-texts - like images - to specific audiences. RFC 
> 2616 suggests "en" as Content-Language tag for a Latin text (a lesson) 
> aimed at an English audience. 
> http://tools.ietf.org/html/rfc2616#section-14.12

>> For example, I 
>> could have a document that is mostly English with a some Hebrew 
>> phrases mentioned. While both English and Hebrew occur in the 
>> document, it would not be useful for a non-English speaker, while it 
>> could be useful for an English speaker who didn't know Hebrew.

> If it was an important treaty for Jews, written in English - but for a 
> few keywords in hebrew - then why wouldn't the author put Hebrew as one 
> of the Content-Language languages?
Well yes it should be listed as one of the Content-Languages, if it is expected that only persons who speak both English and Hebrew will be interested in the document;
however if the document targets speakers of all languages but just happens to have the Hebrew words included for clarity then it might not be appropriate to list Hebrew anywhere but as the language of the elements containing text in Hebrew.  (IMO, it depends how important the Hebrew is.)

> . . .

> Does any of your comments above mean contain any concrete idea w.r.t. 
> that proposal? Note that I had already stricken the word "audience 
> language" from that proposal.
It's 'locale language' now, right  or 'Content-Language'
(the term 'Content-Language' might be confusing; locale language is not quite so bad; but 'Content-Language' is the http term and not our term).

>> While 
>> we can't make a syntactic change for compatibility reasons, there 
>> should at least be an explanation of that it is just a syntactic 
>> pidgeonhole that people have to deal with.

>I suppose that the pigeonhole you speak about here, is known as @lang, 
>right? That's eventually another change proposal, I think ...
Finally I am confused; yes there is one language for @lang -- 
that is, for the language attribute on the root element, which is the document language --; whereas multiple languages can be used in the http header (now called the locale and no longer the audience language[s]).
However Mark had just said that it was 'tenuous' at best to distinguish between audience and document language
and now says we cannot talk about just language but perhaps should talk about languages -- and of course in the http header there are multiple languages but not for the hml lang attribute as I've noted above (which is for display though I do not think it's used much). Yes it is a bit inconvenient not to be able to specify all the text processing languages -- is that what Mark means here?


I agree that the language tag may not really be used so much for text processing as the document encoding info. 


And yes languages are all mixed up anyway so there is no such thing as an unchanging language; they are much less fixed than scripts (see:  http://en.wikipedia.org/wiki/List_of_French_words_and_phrases_used_by_English_speakers for example ; the reverse is true in French and many words that the French borrowed from the English -- for example 'surprise party' -- are words we originally borrowed the roots of from the French).

 

Best,

 

C. E. Whitehead
cewcathar@hotmail.com