SDLXLIFF default properties

3 views
Skip to first unread message

yves.s...@gmail.com

unread,
Sep 14, 2022, 5:49:37 AM9/14/22
to okapi...@googlegroups.com

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

jimbo

unread,
Sep 14, 2022, 12:07:37 PM9/14/22
to okapi...@googlegroups.com, yves.s...@gmail.com

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.

yves.s...@gmail.com

unread,
Sep 14, 2022, 12:22:24 PM9/14/22
to jimbo, okapi...@googlegroups.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

Yves

unread,
Sep 15, 2022, 5:57:33 AM9/15/22
to okapi-devel

OK, more on this.
There are two modes for the properties with SDLXLIFF:

  • “Tc-mode”: Manage them at the TC level (for backward compatibility, useSegsForSdlProps=false, the default)
  • Segment-mode: Manage them at the segment level (new way, option useSegsForSdlProps=true must be set)

I’m concerned here only with the segment-mode.

Currently:

  • We extract the values for locked, conf, origin as read-write properties
  • We extract the values for origin-system, percent and text-match as read-only properties
  • We can change values on the read-write properties if the corresponding attribute exists in the skeleton.
  • We cannot remove one of these attribute if it exists in the skeleton. Instead there is a special “Unspecified” value use in those cases.
  • We cannot add read-write property if it doesn’t exists in the skeleton.

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:

  • Be able to update locked, conf and origin.
  • Be able to add them in the output file even if their attributes are not in the skeleton.
  • Be able to truly remove them (when the segment has no property or its value is null/empty).

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

jimbo

unread,
Sep 15, 2022, 10:25:47 AM9/15/22
to okapi...@googlegroups.com, Yves

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.

jimbo

unread,
Sep 15, 2022, 10:30:22 AM9/15/22
to okapi...@googlegroups.com, Yves

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.

Reply all
Reply to author
Forward
0 new messages