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

2011/7/13 Mark Davis ☕ <mark@macchiato.com>

>
>
> Mark
> *— Il meglio è l’inimico del bene —*
>
>
> On Wed, Jul 13, 2011 at 00:37, Felix Sasaki <felix.sasaki@fh-potsdam.de>wrote:
>
>> Hello Martin,
>>
>> many thanks for your feedback.
>>
>> 2011/7/13 "Martin J. Dürst" <duerst@it.aoyama.ac.jp>
>>
>>> Hello Felix,
>>>
>>> (I have removed ietf-languages@ietf.org, 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<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.
>>
>>
>>
>> Of course I can point people from the ULI TC to comment on this draft. I
>> was hoping that since this draft is being put forward mainly by a Unicode TC
>> (CLDR), that Mark or others on this list who are members of that TC would
>> engage with the ULI TC to assure coordination of efforts. But I am happy to
>> do that on my own, and you are right that this is not a question of IETF
>> liaisons.
>>
>
> I would be glad to talk to them about this, and will. I don't anticipate
> any problems; structure such as XLIFF is very different, with very different
> goals, than the identification of content.
>

Indeed. FYI, I pinged Uwe Stahlschmidt in the meantime, but will leave this
now to you.

Felix

>
>
>>
>>
>>>
>>>
>>>
>>>  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.
>>
>>
> The very first paragraph indicates that it is results ("has been
> transliterated, etc.") not process. Where there are other parts of the
> document that you think need improvement, please let us know.
>
>    for specifying the source language or script of transformed content,
>    including content that has been transliterated, transcribed, or
>    translated, or in some other way influenced by the source.  It also
>    provides for additional information used for identification.
>
>
>
>>>
>>>
>>>  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.
>>>
>>
>> I agree. Mark or Addison, if you need more detailed / different text than
>> the above, please let me know.
>>
>> Regards,
>>
>> Felix
>>
>>
>>>
>>> Regards,    Martin.
>>>
>>
>>
>> _______________________________________________
>> Ltru mailing list
>> Ltru@ietf.org
>> https://www.ietf.org/mailman/listinfo/ltru
>>
>>
>