Teleconference - Tuesday March-17-2026
yves.s...@gmail.com
Okapi Teleconference - Tuesday March-17-2026
Google Meet session:
https://meet.google.com/gjn-ywuw-hei
Fixed Time:
https://www.timeanddate.com/worldclock/fixedtime.html?iso=2026-03-17T16:00:00
Note: For this call, US is in Daylight Saving Time, but not Europe.
So the call is 1h later than usually for the US.
9am San-Jose, San-Francisco
10am Salt-Lake City, Boulder
4pm Dublin
5pm Oslo, Berlin, Krakow, Roma, Erquy
And 2am Wednesday on Mooloolaba Beach
https://www.google.com/search?udm=2&q=mooloolaba+beach
Happy St-Patrick’s day
=== PRs:
List is here:
https://gitlab.com/okapiframework/Okapi/-/merge_requests
- First draft of revamped PDFFilter, supporting round-trip
https://gitlab.com/okapiframework/Okapi/-/merge_requests/973
=== Deprecation for XLIFF 1.2 extract/merge code
Jim proposed to deprecate XLIFF 1.2 extract/merge code.
See https://groups.google.com/g/okapi-devel/c/8KUS8MrI7oo
A PR was issued : https://gitlab.com/okapiframework/Okapi/-/merge_requests/972
Based on feedback it was closed.
It is still important to know the current limitations of using XLIFF for pivot formats.
Jim posted a new email on that:
See https://groups.google.com/g/okapi-devel/c/RSQoh7sfy4w
=== Filter configuration
Asgeir provided example with AI using https://github.com/asgeirf/okapi-filter-params/blob/main/src/data/filters.json
Result: https://asgeirf.github.io/okapi-filter-params/#/
Discussion continuing here:
https://groups.google.com/g/okapi-devel/c/bRZGtLo3PC0
Project: https://github.com/neokapi/okapi-bridge
=== Tikal and XLIFF differences
User feedback:
New version of Tikal uses enclosing inline codes rather than placeholders
See https://groups.google.com/g/okapi-users/c/HdhujZuN3NE
=== Encoding and Longhorn
Users discussion:
Is it possible to set the targetEncoding in Longhorn (e.g. to UTF-16LE) somehow?
https://groups.google.com/g/okapi-users/c/TlL38JAmTlc
=== Discussion on versioning artifacts
https://groups.google.com/g/okapi-devel/c/jeV_3iK-Bnk
D: For modules, may be Jim could illustrate with an example. But would not change the versioning itself.
=== Any Other Business
Next call: Apr-21-2026
Regrets for that call: Yves
(Also, won’t be able to post the notice the day before).
-end
yves.s...@gmail.com
Okapi Teleconference - Tuesday March-17-2026 - Summary
And 2am Wednesday on Mooloolaba Beach
https://www.google.com/search?udm=2&q=mooloolaba+beach
Happy St-Patrick’s day
Presents: Yves, Marc, Asgeir, Axel
=== PRs:
List is here:
https://gitlab.com/okapiframework/Okapi/-/merge_requests
- First draft of revamped PDFFilter, supporting round-trip
https://gitlab.com/okapiframework/Okapi/-/merge_requests/973
Still being worked on.
=== Deprecation for XLIFF 1.2 extract/merge code
Jim proposed to deprecate XLIFF 1.2 extract/merge code.
See https://groups.google.com/g/okapi-devel/c/8KUS8MrI7oo
A PR was issued : https://gitlab.com/okapiframework/Okapi/-/merge_requests/972
Based on feedback it was closed.
It is still important to know the current limitations of using XLIFF for pivot formats.
Jim posted a new email on that:
See https://groups.google.com/g/okapi-devel/c/RSQoh7sfy4w
=== Filter configuration
Asgeir provided example with AI using https://github.com/asgeirf/okapi-filter-params/blob/main/src/data/filters.json
Result: https://asgeirf.github.io/okapi-filter-params/#/
Discussion continuing here:
https://groups.google.com/g/okapi-devel/c/bRZGtLo3PC0
Project: https://github.com/neokapi/okapi-bridge
Asgeir went briefly over the reason for doing this and how it was done.
=== Tikal and XLIFF differences
User feedback:
New version of Tikal uses enclosing inline codes rather than placeholders
See https://groups.google.com/g/okapi-users/c/HdhujZuN3NE
Action item: Yves to find out why we changed the default.
=== Encoding and Longhorn
Users discussion:
Is it possible to set the targetEncoding in Longhorn (e.g. to UTF-16LE) somehow?
https://groups.google.com/g/okapi-users/c/TlL38JAmTlc
M: the output encoding should be the same as the input (in our case UTF16LE) when using Longhorn.
But it’s defaulting to UTF-8.
Output encoding seems not to be defined by Longhorn.
Y: In TXT fileter it may be the default for output encoding since it covers all target languages.
One change could be to detect the input encoding and if it’s UTF* not to change it, otherwise, keep the current behavior.
M: We’ll try to see if Dennis can implement that.
Additional note from Y after the call:
The TXT files are using the RegexFilter and according to the code, it uses the GenericFilterWriter to generate the output.
And (unlike I thought) that writer uses by default the original input encoding, if no output is given
So there is probably some setting of the output encoding to UTF-8 in Longhorn when the RawDocument is added to the list of files to process.
Some tracing to do there.
Jim Hargrave
Yves, for Tikal and XLIFF inline codes we changed the default because there were some merge issues using the simplified codes. With simplified codes you only have the id's and tag type to match the translation codes. Full codes allow you to match on the original tag - making the match more confident in cases where the id's have changed.
I wouldn't recommend going back to the simplified codes. There are other issues, beyond code matching, with our XLIFF parser with those - I created a ticket but don't remember the exact one.
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 visit https://groups.google.com/d/msgid/okapi-devel/002f01dcb62e%2424350e80%246c9f2b80%24%40gmail.com.
yves.s...@gmail.com
- Yves, for Tikal and XLIFF inline codes we changed the default because there were some merge issues using the simplified codes. With simplified codes you only have the id's and tag type to match the translation codes. Full codes allow you to match on the original tag - making the match more confident in cases where the id's have changed.
I wouldn't recommend going back to the simplified codes. There are other issues, beyond code matching, with our XLIFF parser with those - I created a ticket but don't remember the exact one.
Got it! Thanks for the explanation Jim.
-ys
