RE: [xliff] Locked vs translate

I agree with Yves; both "locked" and "no" serve different purposes here. I view "locked" as a non-permanent state - it may become unlocked (and change to "yes") at some future stage. Some workflow or editing tools may permit users to unlock these translation units according to their instruction/ discretion; however, "translate=no" should never change.

Automated validation processes may also apply different rules for "locked" or "no" states. If "locked"/"no" target strings have been erroneously translated due to unexpected editing environments, the subsequent action may differ depending on the state (e.g. "no"=revert the string; "locked"=report a warning).

-Kevin.

-----Original Message-----
From:  [mailto:] On Behalf Of Yves Savourel
Sent: Wednesday, October 03, 2012 10:12 AM
To: 'XLIFF TC'
Subject: RE: [xliff] Locked vs translate

> So, for a computer that doesn't understand semantics expressed in 
> English, "locked" and "no" are exactly the same. That's redundant.
> There must be a practical difference between "locked" 
> and "no". Two values with the same meaning (must not
> translate) are a bad idea.

The two values have different meanings:

- no = it is not translatable
- locked = it is translatable but currently locked

The two values may trigger the same action or different ones depending on what the program is doing.

For example:

- If the program is looking at modifying the content: same action -> do not change.

- If the program is creating some word count report: different actions -> entries with 'locked' are counted as translatable but locked, the ones with 'no' is counted as not translatable.

- If the program is performing QA: possibly different actions -> entries with 'locked' are verified, but not the ones with 'no',

I'm sure Fredrik and other have other examples like this.

Cheers,
-yves



---------------------------------------------------------------------
To unsubscribe, e-mail: 
For additional commands, e-mail: