Re: [Ltru] Language tags and (localization) processes (Re: draft-davis-t-langtag-ext)

["Martin J. Dürst" <[e-mail]>]

Hello Felix,

(I have removed [e-mail], to avoid cross-postings.)

On 2011/07/12 16:23, Felix Sasaki wrote:
> The current draft states
>
> "Language tags, as defined by
> [BCP47<http://tools.ietf.org/html/draft-davis-t-langtag-ext-02#ref-BCP47>],
> are useful for identifying the
>
>     language of content.  There are mechanisms for specifying variant
>     subtags for special purposes.  However, these variants are
>     insufficient for specifying text transformations, including content
>
> that has been transliterated, transcribed, or translated."
>
> I am requesting a clarification from the editors, that includes a liaison
> with the Unicode ULI TC http://uli.unicode.org/ , and a clarification in the
> draft.

The IETF has liaisons, but not for a sentence or two in a single draft. 
The IETF is open, so I suggest that you invite whoever is interested 
from whoever organization to comment here.


> Language tags so far have described *states*: an object is in a language, a
> script etc. The proposed extension extends languages to describe the outcome
> of a *process*: objects have been transformed, with a source object as the
> basis for this process. According to the paragraph above, this
> transformation includes also translation.

I think you have a good point: The above description should be changed 
to speak about the result of the transformation, not the process itself.


> So far formats like TBX, XLIFF or others have been used for aligning source
> and target contents. These formats also use language tags, via xml:lang.
> However, the transformation, i.e. the process information, is not expressed
> via the language tag, but via XML structures (pairs of source and target
> elements).

That's probably the best for these kinds of formats and their applications.

> The language tags are purely for identifying the state of an
> object.

Yes, and some wording changes can make this clear.

Regards,    Martin.