state attribute

[Enda McDonnell <EndaMcD@alchemysoftware.ie>]

Hi All,

 

Attached find a spread sheet that divides the current list of the state attribute values into 3 logical groups.  These groups are explained below.

I have changed the name of some values for consistency (suggestions for addition are marked in blue, suggestions for removal / deprecation are in red)

I am suggesting the addition of one new attribute to simplify the problem of state being used for many different purposes.

 

Group 1 - Translation states

• This group describes the various states that a text / binary item may pass through during the localisation process.
• A target can have only one of these values, they should be mutually exclusive.  Having a single translation status is a strong concept where interoperability is concerned.
• The values are...
  needs-translation, needs translation-textonly, needs-translation-sizeonly,  needs-review, needs review-textonly, needs-review-sizeonly, leveraged, translated, signed-off (this is defined as needing no further work, so hopefully takes in finished)
• As with other attributes, if users have different translation states, they may use the x- mechanism or define their own status attribute in another namespace.

 

 

Group 2 - State-Qualifiers

• I feel that this is a different group, and should be put into a different, new attribute, i.e. state-qualifier.  From the list of values that I found in the list, this group further qualifies a translation status.
• It is possible / likely that a combination of values may apply here - see example below.  These should be space delimited values from our suggested list.
• These are not states that text items pass through during localization, hence they should not be in the state value list.
• These values do not define a translation state, they further qualify the state.  However, foreign processors are less likely to be interested in these values.
• Current values are...
  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
• As with other attributes, if users have different translation states, they may use the x- mechanism or define their own status attribute in another namespace.

 

Group 3 - Workflow

• I feel that this group is better suited in the phase element and should not be considered as status information for individual trans-units.

 

 

 

Example

An item that has a translation status of signed-off could have state-qualifiers of leveraged-tm and id-match.

It is easy to get a summary of the translation status by reading the state attribute value.  For processors that are interested in more detail, reading the state-qualifier value yields more information.  In this case, we can see that the translation is a good match because it was found with an id match by a leverage process.

 

 

In the spreadsheet I have also included a list of what I feel may not be needed anymore from the list.

 

This doc is for discussion, try to voice all opinions now, so we can tailor the doc for a vote next Tuesday.

 

 

Cheers,
Enda

 

---

Alchemy Software Development Ltd. Block 2 Harcourt Business Centre Harcourt Street Dublin 2 Ireland Tel : (353)-1-708 2817 Fax : (353)-1-708 2801 Web :www.AlchemySoftware.ie

 

 

State.xls