OASIS XML Localisation Interchange File Format (XLIFF) TC

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.   Regards, Rodolfo -- Rodolfo M. Raya Maxprograms http://www.maxprograms.com    

For what's worth, to me, it reads more
as "hold" the translation for this unit until later than "must
not at this time". In a sense, the program would interpret it as "yes",
"skip", and "no".



From:      
  "Rodolfo M. Raya"
<rmraya@maxprograms.com>
To:      
  "XLIFF TC"
<xliff@lists.oasis-open.org>
Date:      
  10/03/2012 12:24 PM
Subject:    
    RE: [xliff]
Locked vs translate
Sent by:    
    <xliff@lists.oasis-open.org>




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.
 
Regards,
Rodolfo
--
Rodolfo M. Raya
Maxprograms http://www.maxprograms.com
 
 

Original Message --------
Subject: RE: [xliff] Locked vs translate
From: Yves Savourel < ysavourel@enlaso.com >
Date: Wed, October 03, 2012 12:40 pm
To: < xliff@lists.oasis-open.org >

I think it would be more
like this:
 
yes – the content can
be translated (default)
locked – the content
is translatable but currently it MUST remain un-changed
no – the content MUST
NOT be translated
 
Initially, like DavidW,
I was thinking translate and locked are two distinct features that should
be stored in different attributes. The issue of having translate=’no’
with locked=’no’ can be resolved with processing expectation where we
would state that when translate is set to ‘no’ the content must not be
translated regardless the value of locked.
But the more I look at
Fredrik’s idea, the more it seems useable.
Maybe thinking about
the values like this may help:
translate=”no yes-locked
yes-not-locked”
(but I do prefer the
“no locked yes” notation)
 
cheers,
-yves
 
 
 
From: xliff@lists.oasis-open.org
[ mailto:xliff@lists.oasis-open.org ]
On Behalf Of Rodolfo M. Raya
Sent: Wednesday, October 03, 2012 7:40 AM
To: xliff@lists.oasis-open.org
Subject: RE: [xliff] Locked vs translate
 
Hi Yves,
 
Are you suggesting to change the values
for the translate attribute in this way:
 


 yes
 The segment can be translated
(default).

 locked
 The segment MAY be translated
but SHOULD NOT.

 no
 The segment MUST NOT be translated.
 

Regards,
Rodolfo
--
Rodolfo M. Raya
Maxprograms http://www.maxprograms.com
 
 

> 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

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: xliff@lists.oasis-open.org [ mailto:xliff@lists.oasis-open.org ] 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: xliff-unsubscribe@lists.oasis-open.org For additional commands, e-mail: xliff-help@lists.oasis-open.org