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: Xliff TC Teleconference Meeting - 15th April 2003

Xliff TC Teleconference Meeting - 15th April 2003


1. - Roll Call

Present - Tony, John, Bryan, Enda, Gerard, Cristian, Matt, Shigamichi, Mirek, Milan, Reinhard
Apologies - Yves, Mark, Peter, Doug


2. Last week's minutesJohn moved to accept the minutes, and Reinhard seconded. The minutes were accepted.


3. State Attribute

Enda explained his document/proposal. This basically outlines 3 issues for the TC

    a. Add Finished to the state attribute list?
    b. Split the state attribute value list into two lists, state and state-qualifier?
    c. Move the workflow items to phase.?

Much discussion ensued, the following is the outcome..



It has been decided to add 'final' to the list of state values.

Also, other values have been amended; here is a list of the basic translation states that were decided upon.

new (new item added since last release)
needs-translation (only the text needs translation)
needs-l10n (both text and non-textual information* needs localisation)
needs-adaption (only non-textual information needs adaptation)
needs-review-translation (only the text needs review)
needs-review-l10n (both text and non-textual information needs review)
needs-review-adaption (only non-textual information needs review)
leveraged (indicates a change was made by an automated process
translated (indicates )
signed-off (inidcates that changes are reviewed and approved)
final (indicates the terminating state**)

It is expected that a segment pass through these, or a subset of these states during localisation.

* Non-textual information refers to information such as co-ordinates, font information, mirroring, etc.
** Signed off may also be used as a terminating state


b. With regard to the other possible states, i.e.

exact-match, fuzzy-match, id-match, leveraged-glossary, leveraged-inherited, leveraged-mt, leveraged-repository, leveraged-tm, rejected-grammer, rejected-inaccurate, rejected-length, rejected-spelling, suggestion, mt-suggestion, tm-suggestion

The outstanding question is whether to leave these in the state attribute or to add a new qualifier attribute for this information.

The main item for consideration is that with the basic list of states (listed in point a), the values are mutually exclusive, a target will have only one of these values. With the second group (listed in point b), there is the need to have combinations of values - Eg. leveraged-tm, and rejected-length

In order to get the full TC's opinion on whether to group everything into one attribute (state), or split into two (state and state-qualifer), Tony will compile a ballot on this issue and forward it to the list.



In the interests of releasing 1.1 in a timely fashion, Christian agreed to pull back his suggested workflow values from the state attribute. It was decided that this is a large area and should not be rushed in at this stage.

So, some outstanding issues to be considered in the future are...

not translatable - this is a possible value of the state attribute which suggests items should never be touched
language specific instruction (eg. not translatable for Greek, or Locked for Russian)
workflow we need to examine how we would handle some aspects of workflow.



As it was getting late at this point, it was decided not to conitinue with the other items on teh agenda at this time. Christian move to adjourn, Enda seconded and the meeting was adjourned.


Best regards,


Alchemy Software Development Ltd.
Block 2 Harcourt Business Centre
Harcourt Street
Dublin 2

Tel : (353)-1-708 2817
Fax : (353)-1-708 2801
Web :www.AlchemySoftware.ie





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