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] | [Elist Home]

Subject: Re: [xliff] Working on the Specification Updates

Hi Yves, et al,
- My point about section 3.2.2 also relates to #8 where I suggest a resectioning of the elements. There are other named groups than those listed and it doesn't really need to be a separate section (IMO). My #8 point is "I've never liked the order I gave the spec." This is not important but I do think it could be reordered a bit, if you agree.
- I guess the origin attribute would be enumerated with the 'this-file' attribute value. Maybe this isn't such a good idea? Can you think of a way to implement this concept?
- I had suggested the tu-state attribute with values "needs-translation", "needs-review", "needs-resizing", "translation-approved", and "sizing-approved" be added to <trans-unit>. There could be multiple values. I don't like tu-state but I think it was approved.
- The above naming was suggested to distinguish it from the state attribute of the <target>. The 'TM-Suggestion', 'MT Suggestion', 'Rejected-Inaccurate', 'Rejected-Spelling', 'Rejected-Grammar', 'Rejected-Length' values were approved for the state attribute.
- Maybe we should clarify this better in the meeting ... Should <trans-unit> have the state attribute with "translation-approved" and "sizing-approved" values added? Should a different attribute be added to <target> with the suggested values? Would this make more sense?
- How is 'kenavo' pronounced?

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

Powered by eList eXpress LLC