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

 


Help: OASIS Mailing Lists Help | MarkMail Help

xliff message

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


Subject: RE: [xliff] Question about joining/splitting segments


Hi,

> -----Original Message-----
> From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf
> Of Yves Savourel
> Sent: den 24 april 2012 04:40
> To: xliff@lists.oasis-open.org
> Subject: RE: [xliff] Question about joining/splitting segments
> 
> Hi Rodolfo, all,
> 
> >> a) We remove because it is not a match to the new s1 anymore.
> >
> > Can be removed or left there. It's a tool/user choice
> >
> >> b) We keep it attached to the new s1 but we change its
> >> similarity/score attributes to some arbitrary value to indicate the
> >> match is not the same.
> >
> > The tool could recalculate the similarity score. Updating it would be
> > optional.
> 
> It seems to me that we have to have a specified behavior.
> The candidates can always be removed obviously (although the preference
> should be to keep things whenever possible).
> But if the tool keeps the matches then something should indicate that they
> are not matching the content anymore. And because not all tools can re-
> calculate similarity/score maybe something else, a 'scopeChanged' flag of
> some sort?
> 
> Re-segmenting will affect any information attached to the segments, so we
> probably want some generic mechanism that can be applied to all things like
> the candidates (e.g. notes, QA results, etc.)
> 

I would argue that a match that is attached to a specific segment in a unit 
should be moved to the unit level if the segment is split. And get a 
state / flag indicating that it relates to a subset of the unit. The subset need 
not be identified. If two segments are merged, the matches of both get 
merged. And the same flag / state set to indicate they only cover a subset of 
the new segment. I think that mechanism should work fairly well for other 
types of data like notes too. And it should be simple to implement.

The property of 'applies to subset' is used to stop automated tools from 
incorrectly using a match that only cover a subset. And to provide information
to translators that they should note that it is only a partial translation. I could 
also see it triggering sub-segment matching for some more advanced tools.

Regards,
Fredrik Estreen


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