[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: Rodolfo, Yoshito, DavidF, Lucia M. R: We have quorum.
L: I second. R: Meeting minutes approved.
Latest extended specification draft is available at https://github.com/oasis-tcs/xliff-xliff-22/raw/master/xliff-22/xliff-extended-v2.2wd.pdf
Core only draft is available at https://github.com/oasis-tcs/xliff-xliff-22/raw/master/xliff-22/xliff-core-v2.2wd.pdf Rodolfo shows the changes in the examples that were fixed (5.1.5). Y: do you need the id in the segment? R: let me check. Df: you do not need it. R: thank you David. R: For the match I added another example, where matches is pointing to the
segment. It is properly referenced. Those were the most important changes. R: Yoshito, you have pointed some problems in github, I have fixed them. Y: Thank you, I will have a look. R: We have also modified the metadata that you suggested. Y: Will this change the tree structure? R: Yes, after <xliff>, you will have 0 or one <notes>. This will not affect
previous files that did not have <notes> at that level. Y: This tree will also be updated, won’t it? R: Yes. I will make the changes in the schema. David, will you be available
to change the schematron? D: Yes, but are we sure that we wanted to have <notes> at the <xliff> level?
This a radical change. You should not make changes if there are not clear benefits. R: I see the benefits. Y: In our case, we need to duplicate the information in each <file> at the
moment, so this would be beneficial for us. R: I have the same issue. For me it would be beneficial also. The ref attribute
is already in the schema. Y: Do we have a guidance about updating? We are not changing existing features;
we are extending on top of previous versions. Df: when somebody uses a version of the schema of 2.0, it will not pass. The
policy was that the core version would remain the same. We did small schema changes in 2.1. You are proposing major changes now. This is a big structure changed. The root was a wrapper. R: There is not metadata in that wrapper. D: it has source and language. What is the new core? I am really uncomfortable
with making changes with such a skeleton committee. People are not exciting in breaking the standard. R: it is not breaking, it is extending. We need to make changes. Df: I am not opposing to making changes
R: You are talking in theoretical mode. Yoshito is implementing and sees the
needs, me too. In theory it looks good, in practice we see the implementation problems and we propose solutions. Df: when we changed from 1.2 to 2.0, it was based by studies.
R: That was ten years ago, we did not have the use cases. If you are not implementing,
just accept the needs that we have. Df: to what do you want to change? R: from 2.0 to 2.2 Df: we had 2.0 and 2.1, but the core stayed to 2.0. The point is that if you
want to make changes, you need to have a plan. The committee does not have sufficient representation.
R: If you want, we can keep having this conversation. Df: we should just be doing maintenance work. Y: This is a participation problem. More people worked in XLIFF 2.0 in the
past. Why are they not here? Df: when people think that something is done, they leave. Because they do
not expect big changes. Y: The people attending now is because we would like to be included in XLIFF
because we had some implementation problems, the people that want to improve the standard provide input and create a new version of the standard. Df: it is ok to have changes. We should be collecting people’s use cases.
But making major changes, is breaking the core is breaking the promise of not breaking 2.0. R: where is that promise? Df: standards do not make future claims.
R: Where can I find them? Df: If it is not written in the spec, it was communicated in the symposia
to the community. There are two collections of papers. R: Where are those papers, they are not in the web page in the TC, it is not
there. Df: The fact that you can do something, it does not mean that you should do
it. R: We are making changes. It is working. Df: It is not working; you are breaking the standard. Y: I think we communicate this in the mailing list, and previous members have
access to it. Df: People in the roster, do not pay attention to the mailing list.
R: Let me explain you something. I joined this TC because I wanted to share
my input to the TC, I started requesting features more than a year ago. Yoshito also needs also changes and provides his input. Everytime somebody sends an email, I read it and I answer.
Df: The message format will request a module.
R: we have modules without stakeholders behind, like tracked changes. Df. That module was demoted. R: And without stakeholders maintaining it, like ITS. Df: Basically, nothing is being maintaining, because people from the industry
left. R: Are you going to keep the schematron? Df: we should keep it. R: If you can maintain it, we should keep it. But if you cannot, we should
drop it. You have not changed a single file. I have had to learn so many things to make the new spec work with the new template, modified all the requests, etc. Df: I appreciate all your maintenance on the specification but we should not
make changes if we do not have consensus. R: we are a working committee.
Df: I want to make changes that make sense.
R: Don’t you think that they make sense? Df: I think we need to make a wiki and a collection of features. Yours are
random changes. R: we are wasting time on this conversation.
Y: I think we should have a document explaining the change request, and then
we can decide. R: We did that for the ref attribute.
Df: I am following the issue in github, nothing happened there. I read the
minutes when I have the time. R: This means that you did not read the minutes or the emails that were sent
to the mailing list explaining that there will be a ballot on it. Y: On going forward, we should have a clear process to communicate the changes
and then we will discuss to approve them. I am attending other committees; we should have a clear process to do changes. R: Feel free to create a template, and we will use it. L: I agree with Yoshito’s proposal. We have tried to make all the process
transparent, documenting everything on the minutes and sending emails to notify the members that we will make a major change. But if you think that we need a clearer process to do this, please Yoshito help us with that and share in the next meeting a template
and a process that we will discuss and follow. I agree with Rodolfo that we need to move forward and listen to the problem that implementers like Yoshito and Rodolfo are having, and extend the standard. In order to tackle the problem of attendance, I have
already discussed on the previous meeting that I was planning to invite implementers to attend our informative meetings and share with us their needs, this will be also an opportunity for us to share with them our changes and get their feedback. R: The changes are ongoing
III. Subcommittee and sister TC reports DF: We are making progress on JLIFF, we have an issue on how to represent illegal characters from XML in
JSON. This takes me to the discussion on how to improve engagement in both standards, if there is a bigger overlap in the committees. We are solving the same issues. We could improve the attendance combining forces from both committees.
One of the contributors of JLIFF thinks that XML illegal characters should be handled as plain JSON text, but Phil and
I are more aware of the localisation world and want to protect codes like in XLIFF. R: If you are working in json, the tool that uses it should be able to read it. DF: What is the strategy for the translator editor? DF: we are using markup like in XLIFF. The idea is not to expose any code to the translator.
R: I have never seen a tool working with JLIFF. DF: Yes, there was some implementation code from TDC. Joachin created a tool that worked with JLIFF, and
Phil has also some implementation tools. There might be a corporate extractor that would extract XLIFF or JLIFF but not worry about the serialisation.
R: you might have namespaces issues. Df: sure, we are working around those issues. There are prefixes that used underscore.
we are not working on a strategy on how to roundtrip extensions. We are basically at a point where we need to have a JSON schema for JLIFF. There was a feature proposal by Robert that would need to be implemented in both XLIFF and JLIFF. It would be a Boolean,
that would force the readers to force an extension. We would probably make a formal proposal to the TC. We were thinking about a future feature. It is not considered for the current version of XLIFF. That was for the OMOS. As for the MessageFormat Group, there will be a request for a module at some point. Maybe later this year. We are still working on two candidates for the data model. People
are working on reference implementations on parallel. When the data model will be decided, then it will be fast.
R: What are you doing there? Consensus or majority? Df: It is hard, it is not a good idea to go by force.
R: Is consensus required there? Df: It is, it is documented in procedure. There is progress, and the prototypes are getting closer. Y: It is interesting. Simple messaging format is simple, but things like plural, and mapping those things to XLIFF is so complicated. Df: One of the objectives is to make roundtrip. R: Wait until you reach the development and you have tools implementing. Y: Industry is needing a solution now. Df: MessageFormat is 20 years old and is not mappable because it has non localisable issues. Both of the prototypes can make it work. One is more permissive; the other is stricter. Y: I am still doubting.
Df: The format for translation workbench would be XLIFF 2. Tools can handle that. R: I wonder how Trados would handle display of multiple genders and plurals from such XLIFF Df: We should get some guidance about how to render XLIFF. I uploaded a paper about rendering R: I read the paper, as implementer I do not have plans to implement it L: I will add that element for discussion in the next meeting. We have run out of time today. Thank you for the discussion and have a great 2022.
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]