RE: [xliff] XLIFF 2.0 + ICU messages in Angular

["Yoshito Umaoka" <yoshito_umaoka@us.ibm.com>]

> My comment on the "state"
attribute is based on this extract from the 
> Processing Requirements in section 4.3.1.31
> 
> Writers MUST NOT set the state attribute values to other than the
> default initial if and only if the <segment> element where the
> attribute is set doesn't have the <target> child.
> Attribute "state"
is optional and there is no need to set it if you 
> want to populate <target> with a copy of <source>.

Sorry, it's my mistake. Google search
for XLIFF 2.1 always show draft1 version on top (ouch), and I was looking
at the version. It was added later 2.1 draft, and I confirmed the clause
exists in the final version of XLIFF 2.1 specification.

Slightly different topic. As an implementator
of XLIFF 2 based translation tooling/service, I'm struggling with segment
state management. I don't have any issues with this specific requirement,
but I cannot find best approach to add metadata to segment. For now, my
implementation somewhat uses subState. The processing requirement - Writers
updating the attribute state MUST also update or delete subState - does
not meet our needs. Our tooling defines our own prefix and values for providing
additional information to a segment. One of an example is to indicates
a duplication. When a same segment appeared twice, it may or may not use
same translation. We want to indicate the same segment text is found within
an XLIFF file, so tool processing the content, or editing platform handle
they are related. We want to keep the information during translation process,
but it looks this implementation violates the processing requirement. If
there are any other mechanisms to manage such requirement, it would be
nice, but I cannot find an easy solution. I guess use of subState might
not be aligned to the XLIFF design. Are there any suggestions to handle
such requirement?

-Yoshito