Re: [office] xml:lang settings. Confused.

["Charles-H. Schulz" <charles-h.schulz@arsaperta.com>]

Hello,


I'd like to bring in my two cents of Euro here.
While I'm in favor of using a standard way to define the linguistic
settings inside ODF (and thus to use xml:lang), I'd like to point out
that when it comes to i18n and l10n the format cannot do everything and
has to be versatile enough to allow extremely various use cases. The use
of multiple languages and thus encodings inside one document as
described by Eike is a good example of that.

That requirement of "versatility" and flexibility put aside, we have to
include that xml:lang inside the 1.2 spec if possible. I guess this
should be a quite consensual decision so maybe we could do it "fast".


Cheers,

Charles.

Eike Rathke a écrit :
> Hi Dave,
>
> On Saturday, 2007-06-16 07:56:00 +0100, Dave Pawson wrote:
>
>   
>> I'm OK with that, though why use fo: rather than xml:lang seems
>> a bit NIH?
>>     
>
> No idea, I wasn't involved with the original decision.
>
> Btw: NIH? Not Invented Here? (please bear in mind that this is an
> international list and not all participants have a full understanding of
> every English acronym and abbreviations)
>
>
>   
>>> I wish xml:lang was used, would had made the latest adaption to be able
>>> to support RFC 4646 moot, as xml:lang already says "The values of the
>>> attribute are language identifiers as defined by [IETF RFC 3066], Tags
>>> for the Identification of Languages, or its successor". Which RFC 4646
>>> is.
>>>
>>> Does anyone happen to know why xml:lang exactly was not used?
>>>       
>> Even stronger, please can we change to xml:lang then standard XML
>> processors can do what they should do?
>>     
>
> How exactly should a "change to" look like?
>
>
>   
>>>> I'm curious. When I initially open a document authored in Japanese or
>>>> Chinese,
>>>> how would I know whether to look at style:language-asian or fo:language?
>>>>         
>>> I guess you don't without actually looking at the script type of the
>>> textual content.
>>>       
>> Which, IMHO, is a big hole in the ODF spec.
>>     
>
> Seconded. On the other hand, having two attributes, for example Western
> and CTL, for an entire paragraph gets rid of the need to define
> alternating xml:lang (or whatever) attributes whenever the script type
> changes. And having alternating CTL and Roman scripts is quite common.
>
>
>   
>>>> I guess that defines what I meant by 'primary language' of the document?
>>>>         
>>> The <dc:language> element may give a hint what might be the "primary
>>> language";
>>>       
>> Give a hint? Surely the spec needs to be stronger, and explicit in how
>> the default language is obtained.
>>     
>
> Well, the <office:document-meta> <office:meta> <dc:creator> element
> specifies the document's default language. I said this is only a hint
> because it may get overridden at any time, and usually also is on
> a paragraph level. So in practice it is not sufficient to only obtain
> the <dc:creator> value, one must follow also the document's flow.
>
>
>   
>>> however, if overridden by character attributes it may as well
>>> be useless. Independent of whether a fo:language-asian is present
>>> additionally to fo:language or not.
>>>       
>> I can't respond through knowledge to that one. I certainly object
>> to basing text string language on character attributes though.
>> That sounds quite wrong.
>>     
>
> May be misleading. Character attributes here means characters in the
> sense of a portion of text. If there is a language assigned to a portion
> of text the character attributes span that portion of text with an
> fo:language attribute. How else would you assign a language to
> a sequence of characters?
>
>
>   
>> An I18N mess?
>>     
>
> Seems like.
>
>   
>> How to get this on the agenda for  1.2?
>>     
>
> I'd like to hear what the decision was to have this Western/CJK/CTL
> approach in ODF. To me it seems it originated in some behavior of that
> MS-Word text processor.
>
>   Eike
>
>   


-- 
Charles-H. Schulz,
Associé / Associate
Ars Aperta.