[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Modified: XLIFF TC Meeting
|
Event Title: XLIFF TC Meeting Date: Tuesday, 28 April 2020, 11:00am to 12:00pm EDT 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 This meeting counts towards voter eligibility. Agenda I. Administration A. Approve meeting minutes B. Meeting availbility in light of COVID-19 II. Where do we go next? B. Rendering Requirements for XLIFF 2.2 - David C. GALA TAPICC XLIFF Extraction and Merging Best Practice v1.0 Allison D. New comment from Yves E. Invalid sample files identified by Rodolfo Raya F. XLIFF calls, Steven Loomis G. Features, Steven Loomis H. FragID prefix registration, Rodolfo III. Subcommittee and sister TC reports IV. New business Minutes
Agenda I. Administration A. Approve meeting minutes 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? 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 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. Owner: Bryan Schnabel Group: OASIS XML Localisation Interchange File Format (XLIFF) TC Sharing: This event is shared with the OASIS Open (General Membership), and General Public groups. Public Event Link |
Attachment:
ical_50415.ics
Description: application/ics
BEGIN:VCALENDAR CALSCALE:GREGORIAN METHOD:REQUEST VERSION:2.0 PRODID:-//Kavi Corporation//NONSGML Kavi Groups//EN X-MS-OLK-FORCEINSPECTOROPEN:TRUE BEGIN:VTIMEZONE TZID:America/New_York BEGIN:STANDARD DTSTART:20001029T020000 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10;UNTIL=20061029T060000Z TZNAME:EST TZOFFSETFROM:-0400 TZOFFSETTO:-0500 END:STANDARD BEGIN:STANDARD DTSTART:20071104T020000 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=11 TZNAME:EST TZOFFSETFROM:-0400 TZOFFSETTO:-0500 END:STANDARD BEGIN:DAYLIGHT DTSTART:20000402T020000 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4;UNTIL=20060402T070000Z TZNAME:EDT TZOFFSETFROM:-0500 TZOFFSETTO:-0400 END:DAYLIGHT BEGIN:DAYLIGHT DTSTART:20070311T020000 RRULE:FREQ=YEARLY;BYDAY=2SU;BYMONTH=3 TZNAME:EDT TZOFFSETFROM:-0500 TZOFFSETTO:-0400 END:DAYLIGHT END:VTIMEZONE BEGIN:VEVENT STATUS:CONFIRMED TRANSP:OPAQUE DTSTAMP:20200526T031205Z DTSTART;VALUE=DATE-TIME;TZID=America/New_York:20200428T110000 DTEND;VALUE=DATE-TIME;TZID=America/New_York:20200428T120000 SEQUENCE:3 SUMMARY:XLIFF TC Meeting LAST-MODIFIED:20200526T031205Z ORGANIZER:workgroup_mailer@lists.oasis-open.org ATTENDEE;CUTYPE=GROUP:MAILTO:xliff@lists.oasis-open.org DESCRIPTION:New dial-in link at this action item.\n\nhttps://www.oasis-o pen.org/apps/org/workgroup/xliff/members/action_item.php?act ion_item_id=3921\n\nAgenda: I. Administration\n\n A. Approve meeting minutes\nhttps://lists.oasis-open.org/archives/xlif f/202004/msg00003.html\n\n B. Meeting availbility in light o f COVID-19\n\nII. Where do we go next?\n A. XLIFF 2.X or 3.0 wiki space for new features (Bryan)\n https://wiki.oasis-op en.org/xliff/FeatureTracking\n\n B. Rendering Requirements f or XLIFF 2.2 - David\n https://lists.oasis-open.org/archives /xliff/201901/msg00001.html\n\n C. GALA TAPICC XLIFF Extract ion and Merging Best Practice v1.0 Allison\n https://lists.o asis-open.org/archives/xliff/201901/msg00003.html\n\n D. New comment from Yves\n https://lists.oasis-open.org/archives/x liff-comment/201911/msg00000.html\n Issue #34: Lynx - XLIFF files created with missing subFlowsEnd attribute and found V alid (okapiframework/xliff-toolkit)\n\n E. Invalid sample fi les identified by Rodolfo Raya\n\n F. XLIFF calls\, Steven L oomis\n https://lists.oasis-open.org/archives/xliff/201912/m sg00000.html\n\n G. Features\, Steven Loomis\n https://lists .oasis-open.org/archives/xliff/201912/msg00001.html\n\n H. F ragID prefix registration\, Rodolfo\n https://lists.oasis-op en.org/archives/xliff/202002/msg00000.html\n\nIII. Subcommit tee and sister TC reports\n A. Promotion and Liaison SC\n B. XOMOS - Sister TC\n\nIV. New business\nGroup: OASIS XML Loc alisation Interchange File Format (XLIFF) TC\nCreator: Bryan Schnabel URL:https://www.oasis-open.org/apps/org/workgroup/xliff/event.php?event_id=50415 UID:https://www.oasis-open.org/apps/org/workgroup/xliff/event.php?event_id=50415 BEGIN:VALARM ACTION:DISPLAY DESCRIPTION:REMINDER TRIGGER;RELATED=START:-PT00H15M00S END:VALARM END:VEVENT END:VCALENDAR
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]