state attribute

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