Dear all,
Please find below a summary of today s discussion.
Best,
LucÃa
Attendance :
Rodolfo, LucÃa, Yoshito, Manuel, Bryan. We have quorum.
I. Administration
R: I move to approve 16 August meeting minutes.
https://lists.oasis-open.org/archives/xliff/202208/msg00005.html Y: I second.
R: Meeting minutes approved.
II. Technical work
A.
ISO template.
https://github.com/oasis-tcs/xliff-xliff-22/issues/3 David.
(David is not on the call).
B. Discussed and approved changes in the spec. Rodolfo. You
can download updated versions of the specification from
https://github.com/oasis-tcs/xliff-xliff-22/tree/master/xliff-22 (Rodolfo shares his screen and shows the changes in the spec).
Old XLIFF 2.0/2.1 files
will be still be valid XLIFF 2.2, because the schema is backwards compatible.
C. Test
suite correction. Schematron (update). Confidence vote. See point
I in the 7th June meeting when this was discussed
https://lists.oasis-open.org/archives/xliff/202206/msg00003.html We do not have any feature requirements. So before starting reviewing this draft, we need to know what to
do with the schematron, NVDL and the test suite. My proposal is that we remove them from the spec, leave those files in the github repository so they can still be found and might be updated/changed in the future. But we will remove them from the spec so we
can move on to the reviewing phase.
B : I recall having this
conversation with David on the call and he does not seem to object.
R: I just say that we should keep them in
github.
B: I support the idea of
having a ballot to make a decision on this.
L: I se cond.
Y: Can we keep an informative note mentioning them?
R:
Sure, we can keep the information in the changes section.
Y: Do we keep it in the
appendix as a note?
R:
Appendix C is where the changes are mentioned, and that is where we can include that information.
Y: It sounds good to me.
L: It sounds good to me too.
(The wording of the ballot is agreed
between the members), it will be opened for two weeks, it will be closed after the next official meeting:
https://www.oasis-open.org/apps/org/workgroup/xliff/ballot.php?id=3727 D. New feature requirements?
Y: We wanted to use context references in translation. Resource Data Module. I realise that resource item can be associated with file level. Is it possible to have
them at file level? Semantics is not clear in the spec. We wanted to share some context such as screenshots of UI. We wanted to provide a linkage, defined at the file level. But at some points we want to point at unit level. But sometimes we want to provide
complicate resource to the entire file. For our use case. It is not clear what it means the resource item in a file. Where do we put the resource item in file?
R : you can put it in the
item or reference.
Y: I probably should explain myself
better in an email. In the current spec, both examples are at file level. Does it make sense?
R: we need to check the definition of it. It is fine, it is valid. It is a useless resource.
Y: We have a screenshot giving a context, in this case I just want to attach the screenshot at the file level, but not
everytime we have a unit.
R: I do not think you need to have the reference everywhere. If you put it in the file level, it applies to everything that is below.
Y: The problem is that resource item is valid, what does it mean?
R: I do not know, but I do not think it is wrong to have it.
Y: I might
send an email explaining it better. But anyway, I do not think this will impact the schema. Some clarification would be enough in this case.
R: Yes, if it is just a clarification, it will not have any big impact on the spec. I need
examples, if you have any please send them and I can improve the support.
Y: I will make a proposal on
github.
III. Promotion and Liaison
A.
(News from the module from the Message format working group?)
Y: I am not part of the message format working group.
A technical preview based on their specification will be included on next ICU release in 3 or 4 weeks.