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"
<>
To:
"XLIFF TC"
<>
Date:
10/03/2012 12:24 PM
Subject:
RE: [xliff]
Locked vs translate
Sent by:
<>
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 <>
Date: Wed, October 03, 2012 12:40 pm
To: <>
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:
[mailto:]
On Behalf Of Rodolfo M. Raya
Sent: Wednesday, October 03, 2012 7:40 AM
To:
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
-------- Original Message --------
Subject: [xliff] Locked vs translate
From: Yves Savourel <>
Date: Wed, October 03, 2012 10:21 am
To: <>
Hi all,
Since this topic is being discussed for 2.0.
Here is an example where a tool uses an extension to provide a 'locked'
information.
http://tech.groups.yahoo.com/group/okapitools/message/3285
This specific case could probably be handled with 1.2 approved='yes', but
it illustrates that some users do feel that using translate='no' is not
the proper solution in all cases.
The solution that Fredrik proposed yesterday (translate="yes|no|locked")
may be workable.
For "no": not translatable. For "yes|locked": translatable,
but possibly currently protected. The interest is that it is reversible
without affecting the translate='no' entries.
And you would never have cases like translate='yes'+locked='no'.
Just some thoughts...
cheers,
-yves
---------------------------------------------------------------------
To unsubscribe, e-mail:
For additional commands, e-mail:
---------------------------------------------------------------------
To unsubscribe, e-mail:
For additional commands, e-mail:
---------------------------------------------------------------------
To unsubscribe, e-mail: For additional
commands, e-mail:
