OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xliff-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: Feedback from OpenTM2 XLIFF interoperability enhancements


One more issue.  Another problem I faced is, how to interpret the states a trans-unit may be in.  The two relevant attributes are, the translate attribute of a trans-unit, and the state attribute of the target.

The trans-unit translate attribute "indicates whether or not the text referred to should be translated", but daesn't say why.  So I don't know whether the translator should even see the trans-unit, or whether the translator can override the "should" and translate the trans-unit anyway (as may be allowed on locked or formatting segments in some tools).

The target state attribute has values that are rather vaguely defined.  For example, GlobalSight puts targets populated with an exact (but not in-context exact) TM hit in the "translated" state.  Is this correct, since a human translation was not done?  How should GlobalSight signify this fact?  What should the workbench do by default with "translated" targets?  Skip them because they're translated, or include them because they might still need a translator to check them?

GlobalSight also puts targets populated with a fuzzy TM hit in the "needs-review-translation" state.  That doesn't seem right since it implies that only review is needed.  Probably "new" would be better.  Or perhaps GlobalSight should not put a target in the trans-unit at all, and rely on alt-trans for TM hits.  What is the different between a target with state "new", and no target?

Andrew


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]