Meeting minutes

Dear all,

Please find below a summary of yesterday’s discussion.

Attendance: Yoshito, David, Lucia

A. Proposal for changes template/protocol. Discuss and vote on new Yoshito’s new proposal. https://lists.oasis-open.org/archives/xliff/202202/msg00005.html see also https://github.com/oasis-tcs/xliff-xliff-22/tree/master/.github/ISSUE_TEMPLATE

L: Yoshito created the new four templates, Rodolfo accepted the pull request and he also included the labels that Yoshito indicated.

D. I saw the new templates. Everything looks fine.

Y: At this moment I have four templates, and each template creates a label. So we can filter all the issues with these labels.

L: Yoshito also mentioned deleting the predefined ones. I do not have a strong opinion on this.

Df: erratum and bug are kind of overlapping. I do not think we have to delete them, only bug maybe.

L: Did we use labels before?

Df: we did not use github. We used jira before.

L: As this item has been reviewed and discussed in previous meetings and in the mailing list, I propose to close it unless Yoshito wants to add something else.

Y: we had eight issues in the rep. We can assign the labels.

Df: we can do it now. (David shares his screen and we start discussing the labels that could be included in each issue):

Issue 1. New labels: “Erratum”. “Fixed”.

Issue 2. New labels: “Erratum”. “Fixed”.

Issue 10. New labels: “Erratum”. “Fixed”.

Issue 11. Label (template) “bug” and “Fixed”. We can keep this bug category, in this case it would be appropriate.

Issue 12. We had an interpretation discussion for this issue. Labels “core-proposal” and “invalid” (no problem to fix)

Y: I think is ok. We might need a label like type with core or task, we might need to include a label “fixed”.

Df: You are right, we can add a fixed label. I can revisit it.

Y: for simple erratum, when they are fixed, I think this is ok.

Issue 3. Label-> “Task”.

Migrate ISO format code repo.

Df: I would reopen it. It will come this year in review period.

L: Would lead that action?

Df: Yes. I was in communication with the guy who did the script. I can look into it again. We need the ISO version (Df shows the old svn repository in OASIS)

Y: can we send them in the same tree structure?

Df: we can do it in svn, but nobody wanted to work on svn. It requires a different client. It was fairly technical, there were some communications to create a script to convert

Open issues:

Issue 4. Label: “core proposal”.

Issue 9. Label: “extended proposal” and “enhacement”.

Df: It is assigned to me. I will provide explanatory prose.

B. Future work on the specification. The continuation of the discussion from last meeting https://lists.oasis-open.org/archives/xliff/202202/msg00004.html

L: I have included this item to follow up the discussion that he had at the end of last meeting. I see two different approaches. Df opposes to change the core. I do not see why this should be the case if we get the feedback from implementers telling us that there are aspects that need to be changed to make it improve the work of the implementers.

Y: I think that schema should be changed if necessary.

Df: I agree, “if necessary”.

Y: Another core change we discussed is to add notes in the metadata, I think that this is necessary.

Df: we had a request for xliff level notes in 2.1, it was brought by Steven Loomis. He agreed that they could work around it. Of course decisions can be changed overtime.

Df: Lot of thought was put into the core design. It took us like a year to have the core structure. The committee was larger. I am not opposing changes in core. In the case of Rodolfo’s change (issue 4) it is proposing a way of doing something that can be done with existing mechanisms. I proposed two solutions in the issue discussion.

Y: from the implementation point of view, what you propose is very painful.

Df: (David shows the spec on the screen and the “comment annotation”).

Y: If tools generate a segment. When we want to add a note to a particular a segment, putting that marker in the body, you need to modify the inline tag to add that annotation. Why cannot put it in the <segment>?

Df: it is two times conditional. So many things can break.

Y: if the segment is changed, the notes can be dropped.

Df: the notes are in the structure level.

Y: from the implementers mindset, the core specification does not provide a simple way of doing it.

Df: it does not provide it because it wants to be robust.

L: We will continue this discussion next meeting, as we do not have any time left in this meeting. Thank you for your time.

xliff message