Looking at the XLIFF filter, it seems strange that we have this:
// Locked
if ( propLocked != null ) {
d = d.replace(lockedMarker, (propLocked.getValue() != null)
? propLocked.getValue()
: SdlXliffConfLevel.UNSPECIFIED.getConfValue());
}
// Conf
if ( propConf != null ) {
d = d.replace(confMarker, (propConf.getValue() != null)
? propConf.getValue()
: SdlXliffConfLevel.UNSPECIFIED.getConfValue());
}
// Origin
if ( propOrigin != null ) {
d = d.replace(originMarker, (propOrigin.getValue() != null)
? propOrigin.getValue()
: SdlXliffConfLevel.UNSPECIFIED.getConfValue());
}
Why do we use ConfLevel values for the locked and the origin attributes?
For example the value for locked is normally yes or no
Seems a bug no?
And shouldn’t we just not write any property for those cases if the property value is null when coming back for merge?
-ys
Yves looks like you added or modified these lines in 2019 to fix some behavior:
"Initial updates to handle SDL segment-level better (tests do not pass yet)."
Probably deserves a refactor. Chase and his team has worked on
these SDL properties recently as well.
Jim
--
You received this message because you are subscribed to the Google Groups "okapi-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to okapi-devel...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/okapi-devel/003a01d8c81f%244b5ee040%24e21ca0c0%24%40gmail.com.
I’ll work on fixing my apparently unfinished fixes then.
I’d like to be able to add conf and other writeable attribute, currently we can only update them if they are in the initial file.
-ys
OK, more on this.
There are two
modes for the properties with SDLXLIFF:
I’m concerned
here only with the segment-mode.
Currently:
There is
also a way to specify default values for locked, conf and origin in the
parameters: sdlSegLockedValue, sdlSegConfValue and sdlSegOriginValue.
Currently they
do not seem to be used in segment-mode.
I would
like to:
I got that
working, but I’m not quite sure what to do with the default values we can
specify in parameters.
We could
use them in segment-mode, but the okf_xliff-sdl filter parameters has “Translated”
as the default for conf. Which means on re-write we’ll get Translated even if
the target was not.
Maybe they
are not needed if we can remove the attributes?
Any thought
on this?
Jim rightly
pointed out some work related to this on 1.44: https://bitbucket.org/okapiframework/okapi/pull-requests/614
But it
seems to be for the “TC-mode”.
-ys
Yves,
These all sound like great changes!
A few things bother me. Do we really need the TC mode? Isn't the
TC mode just the case with one segment? I assume this is for
sdlxliff TU's that are unsegmented. I wish we could consolidate
this code.
The default values in the Parameters are for systems that aren't very smart when dealing with sdlxliff. For example, we want to make sure that when the translation is merged that the segment properties get updated. "Translated" being the most important. I agree that making a dumb replacement isn't ideal. Could we be smarter during merge and only update the property only if the target is new or updated?
I'm not as sure about the other two parameters: setSdlSegLockedValue and setSdlSegOriginValue. I guess the locked could be useful to setup a document for review (locking to prevent edits?). But maybe we don't need these two parameters? I think I added them years back for completeness or "just in case".
We can discuss more in the meeting.
JIm
--
You received this message because you are subscribed to the Google Groups "okapi-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to okapi-devel...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/okapi-devel/8bb26a12-424d-4ab4-b94c-d1aaaf8eb8ccn%40googlegroups.com.
Ah, maybe the TC mode was implemented before I added annotation
and property support to TextPart/Segment? Would really like to get
rid of this and work directly on the segments.