< Return to Calendar

* XLIFF TC Meeting (Conference Call)
Name * XLIFF TC Meeting (Conference Call)
Time Tuesday, 28 April 2020, 11:00am to 12:00pm EDT
(Tuesday, 28 April 2020, 03:00pm to 04:00pm UTC)
Description

New dial-in link at this action item.

https://www.oasis-open.org/apps/org/workgroup/xliff/members/action_item.php?action_item_id=3921

Minutes

 

Agenda

I. Administration

A. Approve meeting minutes
B: Thank you Tom for all your work in the TC.

Attendance: Rodolfo, Tom, Bryan, David F., Lucía

B: I move that the meeting minutes to be accepted: https://lists.oasis-open.org/archives/xliff/202001/msg00002.html

R: I second.

B: Meetings approved.

B: Tom has announced that he will leave the TC. I would to thank him for all the work that he had done. He has been instrumental to have several versions approved. He has served as the secretary and he has done a marvellous job.

B. Meeting availbility in light of COVID-19

B: Next meetings. We will have the next meeting on the third Tuesday of May.

 

II. Where do we go next?
B: [shares his screen to show the feature tracking page]

R: SubSegmentMatching, I propose to eliminate it as it is already on the standard.

Df: What I suggest is marking it as not eliminating it. But to add an example for reference. It would be great to create an example for sugSegment matching 2.2.

R: Regarding incorporation of segmentation rules, I decided to see how to implement it. The rules would apply only to untranslated XLIFF. Including the segmentation rules became useless if the file has target elements.

Df: Technically you can do it, but we recommend not to do it. I though this feature request was about some containers to store what kind of segmentation was used. I agree that it is very difficult to resegment once the target is there. Eventually to give some processing requirements. We should not forbid it, but keep the wording that is very tricky.

R: I can write a module for the segmentation rules, but it is fine to resegment something if it not translated, but once it is translated it is not permitted.

Df: this module would have the same problems that the tracking one. Because if they use core without the module, then it would be useless.

R: You would be doing this if something is missing. Unless you agree that we allow resegmentatation when there is no target.

Df: Steve Loomis they were working on Unicode on segmentation, so this is a requirement coming from there. We really need him for the discussion.

R: As I said, we would need to know how to express the rules.

Df: We have had this discussion on whether to include the rules or to just make reference to them. Chest said that not all methods are expressable as rules. We could have methods to reference to how to make reference to the rules.

The rules might be useful. I will probably initate an email on this topic with Steve.

R: good, fine.

B: Are there other feature tracking? In the last meeting, we had some action items associated to them. Several items were associated with Df who was not here.

Df: The tm profile note, we had some technical discussion with Yves on how to show people to use XLIFF for translation memory.

R: Before LISA disappeared, I was in charge of writing TMX, I still have those notes and I can still do something with them.

Df: Nothing can be done under the name on TMX.

R: I am talking on the notes that I had. We had a format that was almost ready.

Df: The discussion was related to have XLIFF to be use as translation memory in absence of TMX new version.

R: We can use the matching modules. The only problem with that module is that is bilingual by default.

Df: we had some conversations about XLIFF to be multilingual. Ms pushed to have a third language as a reference language. There is an attribute there to specify that it is a reference language. So technically you can add other languages. So the trick is there. Actually it is a very old idea, we could describe how to use translation candidate, but it was not never described in the spec. Yves was also arguing to use core only for the translation memory, I was opposing it.

R: It simplifies the change.

Df: The note becomes more complicated. If you need to explain how to use core only.

R: I think is the only one, because core is bilingual.

Df: It could be an informative appendix or a standalone note explaining how to use the existing module for exchange.

B: I think that a note is less impactful.

Df: Yes, but the industry needs it now, and we could add it as an appendix later in the new version. The note would be faster. I can predict a good momentum for XLIFF 2.2 soon.

B: One of things I worry about, is that we need to make it as strong as possible. I do not know if the note will be enough to satisfy the needs of the community.

Df: another thing the community request is an explanation for migrating from XLIFF 1.2 to 2.0

R: I have a migration tool that is already available.

Df: It would be great if you could contribute it to the TC.

R: Sure it is on github, how can we do it?

Df: that is good to include it in the notes. I can send the document library. People can contribute something that is existing.

B: We can close on the modernization of the Schematron. We had a discussion on this topic last meeting.

R: We discovered that it does not support validation. So, it is either fixed or eliminated.

Df: I agree that we need some bug fix for the schematron.

Df: the schematron makes a difference between errors and warnings. I intentionally added some issues as warning and some as errors.

R: If you have a file with errors, the current schematron will not tell you that and they will be considered valid.

Df: what kind of errors?

R:  if the schematron does not catch the errors, it cannot be used for validation.

Df: the schematron is structured so it tracks the state.

R: No, it does not. It was not included.

Df: It would be a warning if there is not target in reviewed and translated. And an error if it is final.

Df: we both agree that the schematron needs some bug fixing.

R: I do not volunteer to work on the schematron.

 

III. Subcommittee and sister TC reports
A. Promotion and Liaison SC

 

Df: The xliff omos tc will meet immediately after. We made some progress on the JLIFF spec.

I would like to talk you about Unicode CLDR TC/MFWG. The message working group, you can join it even if you are not an Unicode member. It is being developed on github. https://github.com/unicode-org/message-format-wg I was the XLIFF representative, I am doing requests to represent our interests. Actually, there is a good appetite to create a matching to XLIFF from this new data model format. There should be a technology agnostic data model. This is currently being discussed. There are a lot developers that want to push features from their framework. There is a big push for message variant that would allow to represent morphological structures. Another thing is to represent placeholders, this is something that Steven suggested to have for XLIFF 2.2. I think that Yves joined the group but I have not met him in the teleconference. There are very interesting discussions happening there.

R: we will have to wait to see the developments there?

Df: I think that it is now the time to engage to make sure that it will be compatible. I am planning to introduce the XLIFF inline elements to the group. There are a lot of people who are not aware of localisation needs and issues.  We should not wait to engage, it is now the time to do it.

IV. New business

B: Thank you tom again.

Df: I might need to ask Tom for some help regarding ISO.

T: Anything I can help with... Best wishes to all. I'll be rooting for the committee's continued success from somewhere in the audience. Cheers.

B: Meeting adjourned.



Agenda

I. Administration

 A. Approve meeting minutes
https://lists.oasis-open.org/archives/xliff/202004/msg00003.html

 B. Meeting availbility in light of COVID-19

II. Where do we go next?
 A. XLIFF 2.X or 3.0 wiki space for new features (Bryan)
 https://wiki.oasis-open.org/xliff/FeatureTracking

 B. Rendering Requirements for XLIFF 2.2 - David
 https://lists.oasis-open.org/archives/xliff/201901/msg00001.html

 C. GALA TAPICC XLIFF Extraction and Merging Best Practice v1.0 Allison
 https://lists.oasis-open.org/archives/xliff/201901/msg00003.html

 D. New comment from Yves
 https://lists.oasis-open.org/archives/xliff-comment/201911/msg00000.html
 Issue #34: Lynx - XLIFF files created with missing subFlowsEnd attribute and found Valid (okapiframework/xliff-toolkit)

 E. Invalid sample files identified by Rodolfo Raya

 F. XLIFF calls, Steven Loomis
 https://lists.oasis-open.org/archives/xliff/201912/msg00000.html

 G. Features, Steven Loomis
 https://lists.oasis-open.org/archives/xliff/201912/msg00001.html

 H. FragID prefix registration, Rodolfo
 https://lists.oasis-open.org/archives/xliff/202002/msg00000.html

III. Subcommittee and sister TC reports
 A. Promotion and Liaison SC
 B. XOMOS - Sister TC

IV. New business



Submitter Bryan Schnabel
GroupOASIS XML Localisation Interchange File Format (XLIFF) TC
Access This event is visible to OASIS XML Localisation Interchange File Format (XLIFF) TC and shared with
  • OASIS Open (General Membership)
  • General Public