OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xliff message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Meeting minutes


Dear all,

 

Please find below a summary of today’s discussion.

 

 

Attendance: DavidF, Rodolfo, Yoshito, Lucía, Bryan.

I. Administration
A. Approve 20th October meeting minutes.
https://lists.oasis-open.org/archives/xliff/202110/msg00006.html

L: I second.

R : Meeting minutes approved.

R: Last meeting only Bryan and I were present in the meeting.

Df: I had some conflict meetings in the previous meetings. It should get better from now on.


II. Technical work
A. New tool for merging specification components.
https://lists.oasis-open.org/archives/xliff/202111/msg00001.html

R: There are many small files and we need to combine them in order to create the final document. I used a java program several years ago, but I lost the source code. I rewrote the program, the tools are now in GitHub with the catalogue and the merger, the writer that puts everything in one file. I had some problems with the stylesheets to produce pdf.

Df: I confirm that I had some problems with generating the pdf. I propose that we contact the docboook committee.

R: the problem is with the oasis stylesheets.

Df: The pdf was working until 2017.

R: Yes, the stylesheets changed.

R: The spec that we have in the server has another look and feel. (Rodolfo shows the new colours, logo, etc). With this stylesheet the pdf does not work. Using oXygen I can produce the HTML. There is a tool that can be used to produce the pdf.

Df: you can ask for permission.

R: The other thing is the licence for the code of the tool.

Df: I think we can ask Chet. If you are fine with the licence. If you want to produce it with a difference license, you can produce it in your own server. I have used the same code, do I have the permission?

R: Yes. (Rodolfo shows the different code he produced)

Df: I will wait until you include the licence.

R: Merge is quite easy, it reads all the links and produces one xml. As easy as that.

Df: .sh works in mac and linux, and .bat in windows. I will be editing them.

R: You can use them in other TCs if you want.

Df: I will have to replace the old ones.      

R: I have been trying to find some details here. For example, the ref from mt:match into notes. And I realise we have something important. Should we have links to attributes and elements?

Df: is it an issue of the merger? If you go to the 2.1 version, they are all resolved. They are there. This is what I found out. These links do not survive.

R: Ok, now that we have the code, we can modify it. I can change the code. All links are breaking the stylesheets.

Df: In 4.5, what else can you do?

R: the stylesheets are not working with that. I will fix that. “Optional” are uppercase.

Df: it is done by the style.

R: this is the stylesheet from OASIS and it does not do it.

Df: so maybe it is a modification that we did in 2.1. They are in an element glossterm. Another member wrote the style to change it.

R: the stylesheet from OASIS is not detecting them.

Df: in the 2.1 repository you will find this.

R: but I am using the OASIS stylesheets.

Df: this should be uppercase according to the standard that OASIS supports.

R: It is in lowercase, but in italics. I will write something on the merger that will do it automatically.

R: the stylesheet is not handling the <olink>. I will have to look at them. Another think I was thinking, there are some places where we will have to modify the style. For example, in the elements we do not have a place to include a note.

Df: we sometimes have notes or warnings.

R: I am not meaning a note, but props.

Df: the name element descriptions are supposed to be simple. I think if you want to add the props I think the best thing is better to add them as notes.

R: They have a note symbol now. This is the new stylesheet from OASIS. This stylesheet kills <olinks>.

Df: I see.

R: they took the stylesheets from oXygen, they did a customisation from docbook.  http://docs.oasis-open.org/templates/ It has changed in 2019.

Df: I did a modification for another committee, I changed the order of some elements.

R: You are saying that we will have to use notes for comments or props. This is something that we discussed with Yoshito some time ago (the ref attribute in “match”). In this case, I would like to include a note here.

Df: That sounds like an informative text that would go in a note.

R: We do not have an example for matches that apply to a fragment. It is a feature that you can use in XLIFF but we do not have it here.

Df: Another that you can use is an example.

R: If you are translating a glossary, you would have the whole term in a segment. We do not have the example, the ref can point to a mrk or a segment.

Y: I agree. There is a case, match will be helpful for the source content of a segment

R: you will match the source with the source in your memory.

Y: you will need a clarification for that, because you can have source and target.

DF: in candidates module, there is clarification, it uses a different data model than alt-trans. You can distinguish between the similarity of sources.

Y: If you point to the entire segment, we need a clarification. Because it can contain the source and target.

R: In that case, you do not need to modify the source. You do not need to enclose source content in <mrk>.

Df: it really identifies the whole segment. You can use attributes that are related to source or target. But you are operating in the whole segment.

Y: For me it is not clear if it is the whole segment.

Df: you can see matchquality, matchsuitability.

R: yes, matchsuitability.

Df: and you also have “similarity”, they have 0 to 100 values.

Y: this is not talking about source and target, but not source and target in the segment.

Df: When you are using in a CAT tool, you would be wanting to compare source.

Y: Can you show the example of the candidates.

R: We are matching “he is my friend” with “he is my friend”. If you apply the id in the segment.

Df: I want to explain why this is an example for mrk. Segmentation is not protected by default. That is why segment ids are optional.

R: it depends on the cat tool.  I saw exactly that case in a file from a client yesterday.

Df: the default is to be “canResegment”, because we expect the corporate extractor to do proper segmentation

R: In the file from my client, they used the canResegment=“no”, because otherwise they cannot put the translated text in place. In this case they provided segments ids.

Df: I would make a hint when you want to use segment id, you should protect segmentation.

R: Yes.

Df: Some of these things are in the guide that I wrote with Ianus. It is in our repository.

--

I responded to the issue that you had in the validator.

R: Your comment does not solve the main problem we found out with Yoshito. If you do not register, you cannot use fragid. For anything else is optional.

Df: Why do not we help them register the prefixes? We can discuss it next meeting

R : Have you made any changes to the test suite?

Df: I have not had the time to this. I will try to make the changes by the end of the year.


III. Subcommittee and sister TC reports
A. Promotion and Liaison SC
- MessageFormat (XLIFF 2 module).
https://docs.google.com/document/d/1D702OBAzT-Crb9XXUiZYJnFO9Yq5duRy4Zc3Br6JwRU/edit David F.

Df: I have a brief update. There is a roadmap in 2022, they plan to have the XLIFF mapping in the second quarter and after that a new module will be proposed. We might also get people joining the TC.

L: that is really good news. Thank you David.

 

R: It would be good to have a webinar to talk about XLIFF.

 

B. XOMOS - Sister TC
It is getting some momentum. Phil Ritchie has taken over, that gives me more time to edit. The spec is shaping up. He structures stuff. Robert and I we are more dedicated to the actual editing.

R: You are basing your work on 2.1.

DF: jliff covers both 2.0 and 2.1 as variants. It contains spec and schema for both. The major write up will be the roundtrip

 

 

 

Lucía Morado Vázquez

Bureau 6336 (Uni Mail) 

Département de traitement informatique multilingue

Faculté de traduction et d'interprétation

Université de Genève

logo-FTI80-ok-email

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]