Re: [xliff] Re: a case for "finished" as a valid value for state

From
Matthew.Lovatt <>
Date
2003-04-09T16:06:09+00:00
ID
017301c2feb2$77b9bc10$014e2f8f@mlovattie
Thread
Re: [xliff] Re: a case for "finished" as a valid value for state
Title: 

 

1) Bryan is talking about trans-units that are not to be 
translatable - i.e.translate=no

    Should we use a state name that 
reflects this? -  for example: state = 
not_translatable

 

2) whatever state name we agree on, should we say in 
the spec that this is the correct state to use for all non-translatable 
trans-units?

 

Mat

 

----- Original Message ----- 

  
From: 
  John Reid 

  
To:  
  ;  
  ; < ;  ;  

  
Sent: Tuesday, April 08, 2003 5:53 
  PM

  
Subject: [xliff] Re: a case for 
  "finished" as a valid value for state

  

I have no problem with this. However, it might be good to 
  consolidate the two concepts of "finished" and "signed-off" so that 1 state 
  says if work on a trans-unit is completed. I have no other suggestion for 
  this, though.

>>> <> 
  4/8/03 10:48:36 AM >>>

  

  
[I 
  tried again to send this to the list, but it bounced back.  Could one of 
  you please post this on my behalf?  I'll try (again) to fix my email 
  account with OASIS, thanks]

  
----------------------------------------------------------------------------------

  

  
Although "finished" is described as a "workflow state" in the current 
  specification, I propose that "finished" should remain a pre-defined value for 
  state. 

  
In my XLIFF application, the state of "translated" is suitable for targets 
  that have been translated. The state of "signed-off" could indicate a definite 
  reviewed/completion status. But I have targets that are not candidates for 
  translation, and have not been "translated," and are not yet "signed-off," but 
  are indeed "finished."

  
The state of finished is not accurately described by any of the other 
  values in the list, from my point of view.

  
I'm not passionate about this, but I thought I'd pass along my 
thoughts.

  
Thanks,

  
Bryan