Machine Translation

[Felix Sasaki]

2009/9/11 Doug Ewell <doug at ewellic.org>

> Felix Sasaki <felix dot sasaki at fh dash potsdam dot de> wrote:
>
> >> The problem with this is that it applies to XLIFF (XML Localization
> >> Interchange File Format) only. A language tag extension, in contrast,
> >> can be used anywhere language tags can already be used.
> >
> > Yes, but in XLIFF it is a common to store such information in a
> > separate field, that is not as part of a language identifier (which
> > are used as well in XLIFF, via xml:lang). Having a language identifier
> > with similar information would create confusion.
>
> The same argument was made against script subtags during the development
> of RFC 4646.
>


There is a difference in the case of XLIFF. If the extension subtag is just
similar, but not identical to MT related information in other technologies
like XLIFF, you will end up with a mess of *values*. This is IMO different
from the script subtag case: Here you have the same values, but different
*occurences* (e.g. a script field in XSL-FO and an language tag in XSL-FO).
Difficult to handle, but still much easier than a different set of values.


>
> > I did not propose the table as an input for variant subtags. I rather
> > think that people who mostly need the use case discussed in this
> > thread (the localization industry) lalready have the means the need -
> > they just do not rely on language tags for the purpose of identifying
> > machine translated content.
>
> In fact, the thread started with someone saying they did not have a
> means to identify machine-translated content, and were looking to
> language tags to fill the void.
>


True indeed. But there seemed to be some unawareness of existing mechanisms
to indicate "content X was created via MT", and the suitability for the
needs expressed in this thread.

Felix
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/ietf-languages/attachments/20090911/8a8dbbf5/attachment.htm