Dear all,
Please find below yesterday's meeting minutes.
Best,
Lucía
-----------
Attendance: Rodolfo, Yoshito, Lucía.
Administration
R: I move to approve March 3, meeting minutes. https://groups.oasis-open.org/discussion/meeting-minutes-35
Y: I second.
R: Meeting minutes approved.
Technical
Revisit the test suite topic: https://github.com/oasis-tcs/xliff-xliff-22/tree/master/xliff-21/test-suite . Yoshito. New repository?
R: I wrote an answer to the issue you mentioned. The validator is right. https://github.com/oasis-tcs/xliff-xliff-22/issues/47 (Rodolfo explains the issue showing the spec).
Y: what is the purpose of the constraint in notes?
R: It is simple. The ref is pointing to the note in the same unit.
Y: I understand, I still don't get the purpose.
R: I don't know why. I agree with you. But my validator follows what is written now in the spec. We can change it.
Y: I do not see the purpose of this constraint. We might want to change it in the new version.
R: Yes, we can change it. For the test suite the validator is right at the moment.
Y: the whole purpose of a selector is to select, so this constraint goes against this concept.
R: The current examples in the spec are wrong. We can either change them or change the restriction in the new version. Can you open an issue to change this in the new version?
Y: Sure.
R: We need to fix that in the spec.
Y: I think that was the last one.
Y: I will update the example to make it valid and file an issue for the changing this restriction.
New translation memory standard. https://github.com/oasis-tcs/xliff-xliff-22/tree/master/memory R: I do not have any news.
Y: I sent the email about the new repository.
Provenance module. Work on the draft.
L: I have been working on transforming Mathijs proposal into spec wording.
Y: what happens if we have several segments?
R: We might need a ref in the element change. For example:
<unit id="1">
<pvn:provenance>
<pvn:change personName="Anxela Loureiro" toolName="Swordfish" ref="#s=s1">
<pvn:change>
</pvn:provenance>
<segment id="s1">
<source>Your annual tax certificate is now available for download.</source>
<target>O seu certificado anual de impostos está dispoñible para descarga.</target>
</segment>
</unit>
Y: If would be clearer if we had two segments.
L: What happens if there were multiple changes? The target was pretranslated by MT, then posedit, it will start looking like the change tracking module that was demoted.
R: I would not go too far, we just need to record the provenance.
L: I agree, we should leave it as simple as possible.
Y: I am struggling with adding only at the unit level. The TMS are normally working on a segment basis, not unit. The attributes state and substate, substate are user-defined. We cannot put any metadata in segment level.
R: The same for provenance.
Y: It is tricky to know specifically for each segment.
R: The rationale is that they should be at the unit level.
Y: From implementation point of view, it is easier to have it at segment level.
R: I totally understand it. But I am not sure.
Y: In reality if you have a translation workflow, it is not frequent. Translation is applied segment by segment, not by unit.
R: In some cases, working with DITA. Translators can resegment. Translators work on segment level. I have to compact everything, and all that information kept in segments level will be gone.
Y: Some systems might want to have provenance at unit level, but other systems might want to keep it at segment level. It will depend on how their translation workflow works.
R: I agree with you, but I don't have a solution.
R: It looks good what you did, Lucía. I would add the ref attribute that we discussed (similar to the ref in the core).
R: Another idea: what if we also add a ref attribute in the metadata module?
Y: I would agree with that idea, I do not think it does not break any working solution, it just add more control.
R: Can you add a ticker for that?
Y: Sure, I can do that.
L: We should change the name of the existing "reference" because it could lead to confusion.
R: I agree totally.
Y: For the users, it is better to use the common attribute, even if the restrictions are different. It is easier to understand.
L: I still do not fully understand the <value> element that was proposed by Mathijs.
R: It is similar to the change tracking. I do not agree with that as it will be adding a complex structure.
R: I do not like the name "usage", it should be "cost". For now, it is just working progress.
L: I will add a comment on that.
------------------------------
Lucía Morado Vázquez
Researcher and lecturer
University of Geneva
------------------------------