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: Yoshito, Rodolfo, Lucía

Regrets: David, Bryan.

 

I. Administration 
R: I move to approve 15
th March meeting minutes. https://lists.oasis-open.org/archives/xliff/202203/msg00003.html and 5th April meeting minutes (informative meeting). https://lists.oasis-open.org/archives/xliff/202204/msg00003.html 

Y:  I second 

R: Meeting minutes approved. 

 

 
II. Technical work  

A. Use of fs:fs/fs:subFs in <note> element. Yoshito. See the original question: https://lists.oasis-open.org/archives/xliff/202204/msg00004.html and the discussion on the mailing list https://lists.oasis-open.org/archives/xliff/202204/maillist.html  

Y: there is a problem in the spec on that point. Why does an element allow to have this style module? Probably the author thought it was a good idea, but it is premature. 

R: yes, I agree. 

Y: this is a minor issue. 

R: can you create an issue in github? So this issues is documented. 

Y: I will try to do it. 

 

 

B. Processing requirements for state attribute. Yoshito. See the original question: https://lists.oasis-open.org/archives/xliff/202204/msg00006.html  and the discussion on the mailing list https://lists.oasis-open.org/archives/xliff/202204/maillist.html  

(Rodolfo shows a file that is not valid to make an example of what Yoshito had explained in his email)  

R: I would remove the default value for the attribute. This would solve the issue 

L: Can we have a look at the translate attribute? It looks like a similar case. 

R: (Rodolfo checks it on the schema) It is similar, but it does not have the default. In state, the current default value is “initial”. 

L: can you check in 1.2? 

R: In that case it was by default yes. 

R: We need to make a change otherwise the files will be invalid all the time. My opinion is to remove the default value, that will mean change the spec and the schema. 

Y: I think these issues, the semantics of initial is not clear to me from the beginning. If the value is initial, it should not have target. We have two tools processing xliff. We have a system storing segments, and adding suggestions from other systems, if we already need that some segments that should not be translated, in that case we can make it final, and that would be see as invalid. We know that that segment is not translatable.  

R: The translate attribute is in unit not in segment. I have seen that there is one paragraph where there is one segment that should not be translated, and you cannot define it now. 

Y: what we do is having the segment with final value, but the segment is empty.  

R: I understand. And I need users a method where they can choose that they do not want to translate a section. 

R: what happens if we add a value? For example, “untranslatable”? 

Y: we could have a mrk element with translate. 

R: Yes, but you would have to change the unit. 

R: what do you think about adding “unstranslatable”? 

Y: that is one way of solving it. In processing requirements, if we get rid of the first statement, which is in conflict with the default value. If we get rid of that sentence, we might not need to change the schema. 

R: The _expression_ “if and only if” is confusing, it is in other sections of the spec. We need to fix this issue. 

Y: the definition should be more clear. Initial should be more clear, what does it mean? 

R: you might want to have a locked segment. 

Y: we use “final” for that. 

L: In 1.2 there were 12 default values for the state attribute, that was an issue for implementers. To solve that problem, it was decided to reduce to a simpler list of default values, and still allow other values through the substate attribute if some tool implementers need them in their processes. 

R: we need to start by removing “default” from the schema, so the files can be valid. 

Y: what if we get rid of the first statement of the processing requirements? Your example is invalid because of the processing requirements. At least it resolves a conflict. 

R: It is not enough. The “initial” here is a semantic problem. (Rodolfo shows how oxygen shows how “state with the value initial” is shown in the properties). If we do not have a default value in the schema, we do not have the problem anymore and not semantic problem. 

Y: Yes, that is true. 

R: Removing the default value, this file is valid. We should also remove the requirement that “final” means that there is a target. If it is final means “do no touch”. What is the meaning of initial? 

L: can we have a look at the 1.2 spec? state was in target. 

R: there was not “initial”. 

R: In the previous version, you could have “approved” at the unit level, and mark something.  

(Rodolfo shows an example with a unit, where one segment is not translatable, but the only thing I can do is to mark it as “final”, in that case it would be stored in the translation unit, and I do not want that) 

Y: This is interesting. You could use a substate so you could control that but it will not be interchangeable. Everybody is having the same problems, if would be nice to have a common vocabulary. 

R: I would put “translate” as an optional attribute in segment. 

Y: things get complicated as segmentation happen. Was this discussed when it was moved to 2.0? 

R: David said that it was in unit level, because segmentation can change.  

R: Can you create a “translate” issue in github? 
Y: I think there are two different issues, one is the state attribute, to get rid of the state value and clarify the processing instructions. And the other one is the translate attribute so it can be included in the segment level.  

R: In 1.2 the state value was “undefined”, there was not a default value. 

 

 

C. Ballot results (Issue 4). https://github.com/oasis-tcs/xliff-xliff-22/issues/4 Rodolfo 

R: as the ballot passed, we can close this issue. 

L: I agree, we need to document it in github. 

R: Yes, I will add the link to the official ballot and document it. 

Y: I agree to close it. 

 

 

L: Meeting adjourned. 

 



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