Re: [Ltru] xml:lang syntax

To emphasize part of Mark’s note:

xml:lang is an attribute. If you want to declare languages or have an attribute that is a language list you should use your own and not abuse xml:lang. I wrote an article about this:

http://www.w3.org/International/questions/qa-when-xmllang

Just because xml:lang is available for declaring the language of an element doesn’t mean that it is the ONLY way to use language tags in markup languages.

As for Mark’s assertion:

Ø But it would be less clumsy if xml:lang took a list, or we had xml:langs that did.

I think this would be bad. Lists of language (asserting the language of a span of content) make processing, parsing, validation, and other operations harder. They make it harder for users to tag content, since users have to think of potentially more than one tag. They make it harder to interpret content (since the language tags applied may not go together or even be contradictory). This idea that an item is in “multiple languages” is mostly wrong. If you need a list of languages or have some different application other than declaring the text processing language of an element then you should use your own element or attribute to convey this information.

Addison

Addison Phillips

Globalization Architect -- Lab126

Internationalization is not a feature.

It is an architecture.

From: ltru-bounces at ietf.org [mailto:ltru-bounces at ietf.org] On Behalf Of Mark Davis
Sent: Friday, May 09, 2008 7:46 AM
To: Jukka K. Korpela
Cc: LTRU Working Group
Subject: Re: [Ltru] xml:lang syntax

Because the xml:lang only takes a single language tag, XML does easily mark one section of text as being equally well represented by either of two language tags. That is, it assumes that you know what the language is, and can pinpoint it as having exactly one tag. Reality is a bit messier... And a fallback to mul is useless, since that gives you far less information.

This isn't formally a problem with XML, since you can always design a format that bundles together multiple xml:langs as applying to some text, and you also don't have to use xml:lang to mark text: you can use your own attribute, containing a list. But it would be less clumsy if xml:lang took a list, or we had xml:langs that did.

Mark

On Thu, May 8, 2008 at 10:51 PM, Jukka K. Korpela <jkorpela at cs.tut.fi> wrote:

Doug Ewell wrote:

> A language tag denotes one language.

For suitable values for "one" and "language", yes.

> A protocol may define ways to
> combine multiple language tags into one field, as HTTP has done with
> Accept-Language by separating the tags with semicolons. But that is
> defined by and specific to the protocol.

In the XML context, which is what the discussion is about, there is
normally no need to consider the possibility of referring to several
languages in one xml:lang attribute. The reason is that for
mixed-language content, XML lets (and even encourages, so to say) you to
use nested markup so that you can say exactly, for example, which parts
of the text are in English and which are in French. This may require
additional markup elements for the sole purpose of attaching xml:lang to
some piece of text, but that's nothing odd. For a truly bilingual
element (with almost equal amounts of text in two languages), you just
need to select one language for it and override the language information
in nested elements.

However, XML has no way to specify different languages for different
_attributes_ of an element. If an element's attribute is in language
other than than its content, you can use the workaround of an inner
element, just for specifying the language of content, but this won't
work for attributes in different languages. The problem is real because
nowadays people often put textual data in attributes, as opposite to
(what I see as) the original idea in generalized markup where attributes
seldom contain text in a human language.

Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

_______________________________________________
Ltru mailing list
Ltru at ietf.org
https://www.ietf.org/mailman/listinfo/ltru

--
Mark