Okapi Teleconference - Thursday Aug-18-2022
Google Meet session:
https://meet.google.com/gjn-ywuw-hei
Fixed Time:
https://www.timeanddate.com/worldclock/fixedtime.html?iso=2022-08-18T15:00:00
8am San-Jose, San-Francisco
9am Salt-Lake City, Boulder
4pm Dublin
5pm Oslo, Berlin, Krakow, Roma, Erquy
Fri 1am Brisbane
Thu/Fri midnight Tokyo
And 4pm on Savage islands
https://www.google.com/search?q=Savage+Islands&tbm=isch
==== PRs:
https://bitbucket.org/okapiframework/okapi/pull-requests/
https://bitbucket.org/okapiframework/longhorn/pull-requests/
https://bitbucket.org/okapiframework/omegat-plugin/pull-requests/
===== Build problems on GitLab
Main project: Mihai fixed the problem:
https://groups.google.com/g/okapi-devel/c/moFcuM0w_Pg
There were a few failures after, related to merges.
But it’s back to running properly:
https://gitlab.com/okapiframework/okapi/-/pipelines
Many thanks Mihai!
Longhorn seems to be a different issue:
Example: https://gitlab.com/okapiframework/longhorn/-/jobs/2370364091
Mihai tried to update the JABX data, but the build still fails.
https://groups.google.com/g/okapi-devel/c/xub4WPK7XwM
===== Longhorn Docker
Translate5 will now take care of maintaining the Docker for Longhorn
See Timo’s email: https://groups.google.com/g/okapi-devel/c/JdUI6b-RCA0
===== Release OK by Aug-30?
https://groups.google.com/g/okapi-devel/c/UG85XFwmPT0
Jim would like to release around by the end of August.
Any input for this?
Is the change log up-to-date?
Last week-end of August is Aug-27/28
(very soon)
===== SWT-related test on MacOS
Building on MacOS fails because some SWT related tests
See https://groups.google.com/g/okapi-devel/c/-sYiFlDttBs
Solution for now is the disable the tests.
===== Other Business:
Next call: Thursday Sep-1
Okapi Teleconference - Thursday Aug-18-2022 - Summary
Present: Jim, Yves, Mihai, Dale,
1 TODO: https://bitbucket.org/okapiframework/omegat-plugin/pull-requests/16
J: We should give commit rights to Alec Shashaty.
.. would allow better PR handling.
No dissent.
ACTION ITEM: Yves or Chase to give rights to Alec.
https://bitbucket.org/okapiframework/omegat-plugin/pull-requests/
No way we can go back to Java 8.
===== Build problems on GitLab
Main project: Mihai fixed the problem:
https://groups.google.com/g/okapi-devel/c/moFcuM0w_Pg
There were a few failures after, related to merges.
But it’s back to running properly:
https://gitlab.com/okapiframework/okapi/-/pipelines
Many thanks Mihai!
Longhorn seems to be a different issue:
Example: https://gitlab.com/okapiframework/longhorn/-/jobs/2370364091
Mihai tried to update the JABX data, but the build still fails.
https://groups.google.com/g/okapi-devel/c/xub4WPK7XwM
===== Longhorn Docker
Translate5 will now take care of maintaining the Docker for Longhorn
See Timo’s email: https://groups.google.com/g/okapi-devel/c/JdUI6b-RCA0
===== Release OK by Aug-30?
https://groups.google.com/g/okapi-devel/c/UG85XFwmPT0
Jim would like to release around by the end of August.
Any input for this?
Is the change log up-to-date?
Last week-end of August is Aug-27/28
(very soon)
J: updated the change log, did pricate tests.
M: I can release, but need to make sure it work fine before.
So plan is to release last week-end of August.
===== SWT-related test on MacOS
Building on MacOS fails because some SWT related tests
See https://groups.google.com/g/okapi-devel/c/-sYiFlDttBs
Solution for now is the disable the tests.
M: we have a few place with main methods for hand-driven tests.
.. no unit test so far.
J: Kind of like Denis’ wish.
M: Don’t know. UI tests are easy to break. Not sure about the benefits.
e.g. screen-shots-based. Very hard to maintain.
M: for the release we can @ignore it.
.. Then maybe we could have a test suite run only from time to time.
.. make things more difficult, especially across platforms.
.. somewhere there is a dependency on BSD, but no official SWT for BSD.
Y: especially worry about multi-platform.
M: this add to the complexity to mainainting things.
Let’s try to address this after the release.
@Chase, @Denis, @Alec: OK with this?
M: instruction file, should be up-to-date
.. info there should be just copy+paste from instructions.
.. can improve on this.
===== Other Business:
----- ICU message format
J: On a branch for now. Move Mihia’s prototype there, took out XLIFF2-specific parts.
.. idea:
First step:
After:
J: annotations are quite complicated.
.. will have a bunch of examples with comparisons
.. Spartan has done some work on this, would like to get that for the examples.
M: Will try to answer any questions you may.
.. match doc for XLIFF2
.. we’ve been doing this for a while now.
.. - annotations support (proto and xliff2 only) - "normalize" the messages - generate missing cases Normalization: `You deleted {count, plural, 1 {# file} other {# files}}!` Should be: `{count, plural, 1 {You deleted # file!} other {You deleted # files!}}`
.. there are some tricky cases, like several #s.
.. normalization is likely ICU-specific, could be in a separate step, but not necessarily.
.. doing generating missing cases should definitely done in other steps.
J: This may work only with the proto-buffer serialization.
.. likely will have no allotated time for more.
.. XLIFF2 may be possible, but not sure.
M: Need to submit the proposal too.
M: Note that there is a MessageFormat v2 that will be even messier, with custom functions.
.. ICU 72 as a proof-of-concept, in September.
.. parsing parts should be OK for Java objects. No parser to re-write.
See https://github.com/unicode-org/message-format-wg/
Specs not final : https://github.com/unicode-org/message-format-wg/tree/develop/spec
And we’ll have a registry for the functions, etc. A bit like BCP-47 registry.
.. not defined yet.
Next call: Thursday Sep-1
-end
Hi!
I would like to clarify the situation a bit.
Mihai, I support your hesitations about the value of testing of the presentation stuff (styling, positioning, look and feel, behaviour). At the same time, if we look at the tests under discussion, we can consider them more as integration ones, when only data related checks are performed... No doubt, there is an alternative approach of manual testing but it looks a way more hard and error prone to me. So, I would rather keep the UI testing opportunity available and try to find out a solution for MacOS. Sure, there is no pressure and we can do this after the release.
Best regards,
Denis
J: We should give commit rights to Alec Shashaty.
.. would allow better PR handling.
No dissent.
ACTION ITEM: Yves or Chase to give rights to Alec.
--
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/CAGRYq4hQshtF8LJdkOxpyW3dpAfEh90Nd7W-ZnnCNS6H%2BaMiHA%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/okapi-devel/CAK69zbmHj%3DkL_7PFQ9Q1mETDAK5f0j-QfOWVgX2D8vYVn2b-VA%40mail.gmail.com.
+1 I would prefer to do the release this weekend. I'm holding my
initial ICU message branch until post release.
To view this discussion on the web visit https://groups.google.com/d/msgid/okapi-devel/CAGRYq4iG83pn5j%2B%3DJX4Y3byS4hwbsyg%2BoN-xBDXsJ96A8GV93Q%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/okapi-devel/4194430f-b12f-16db-6830-eb55ce85224d%40gmail.com.