xliff message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [xliff] R37: Revised Validations Module proposal
- From: Helena S Chapman <hchapman@us.ibm.com>
- To: "Schurig, Joachim" <Joachim.Schurig@lionbridge.com>
- Date: Thu, 21 Mar 2013 14:44:48 -0400
You summarized correctly of my own recollection
of the discussion.
From:
"Schurig, Joachim"
<Joachim.Schurig@lionbridge.com>
To:
Ryan King <ryanki@microsoft.com>,
Helena S Chapman/San Jose/IBM@IBMUS
Cc:
"xliff@lists.oasis-open.org"
<xliff@lists.oasis-open.org>, Yves Savourel <ysavourel@enlaso.com>
Date:
03/20/2013 07:29 PM
Subject:
RE: [xliff]
R37: Revised Validations Module proposal
Hi Ryan,
while yours was my initial
position as well, I do not think that it was the outcome of the discussion
in the TC. We do have already mention of the normalization approach in
the size restriction module, so it would make sense to include it here,
too, and I think this was the conclusion on the Tuesday call. You could
leave the default to “none” and declare that this would leave it to the
processing agent how to deal with the situation, but if any of “nfd”
or “nfc” values are set it should lead to more specific behavior. Could
this be an acceptable solution to all parties?
Cheers,
Joachim
From: xliff@lists.oasis-open.org
[mailto:xliff@lists.oasis-open.org]
On Behalf Of Ryan King
Sent: Mittwoch, 20. März 2013 17:58
To: Helena S Chapman
Cc: xliff@lists.oasis-open.org; Yves Savourel
Subject: RE: [xliff] R37: Revised Validations Module proposal
Yes, Helena, thanks for checking with me
that. We did discuss it and feel that the processing agent should be responsible
for normalization of text and so we will explicitly state that in the module.
Thanks,
Ryan
Sent from my Windows Phone
From: Helena S Chapman
Sent: 3/20/2013 4:43 AM
To: Ryan King
Cc: xliff@lists.oasis-open.org; Yves Savourel
Subject: RE: [xliff] R37: Revised Validations Module proposal
Did Kevin convey the comments about normalization
to you? How do we expect to deal with that in the spec?
From: Ryan
King <ryanki@microsoft.com>
To: Yves Savourel
<ysavourel@enlaso.com>, "xliff@lists.oasis-open.org" <xliff@lists.oasis-open.org>
Date: 03/20/2013
02:41 AM
Subject: RE:
[xliff] R37: Revised Validations Module proposal
Sent by: <xliff@lists.oasis-open.org>
Hi Yves, all,
We suggest that for mustLoc, we enclose the source and replacement target
values in parenthesis, like so: mustLoc="(World) (Welt)"
If for any reason, a parenthesis is required to be translated, as a brace
for example, we could escape it like so: mustLoc="(\(World\)) ({Welt})"
Since we are generalizing the dblSpace to occurrences, then we could do
something similar there as well: occurrences="(|) (3)"
For example, where 3 pipes need to occur in the target for whatever reason.
Further comments or suggestions welcome.
-----Original Message-----
From: Ryan King
Sent: Tuesday, March 19, 2013 10:59 PM
To: 'Yves Savourel'; xliff@lists.oasis-open.org
Subject: RE: [xliff] R37: Revised Validations Module proposal
Thanks Yves for the feedback. All valid and good comments, which we will
incorporate into the spec. As for the question on the mustLoc separator,
Kevin and I are discussing it and suggest something shortly.
Thanks,
ryan
-----Original Message-----
From: xliff@lists.oasis-open.org
[mailto:xliff@lists.oasis-open.org]
On Behalf Of Yves Savourel
Sent: Tuesday, March 19, 2013 5:01 AM
To: xliff@lists.oasis-open.org
Subject: RE: [xliff] R37: Revised Validations Module proposal
Hi Ryan, all,
Some feedback on the Validation proposal (nothing major, just possible
suggestions):
-- strbegins and strEnds attributes:
Maybe names such as startsWith and endsWith may be a bit more descriptive
of the function?
-- dblSpace:
This seems to be a very specific check. Maybe it can be generalized a bit
without making it very different? For example, instead of dblSpace="3"
we could do occurrence=" |3" (or a better name than 'occurrence').
This would allow to check for more than double spaces.
-- mustLoc:
How do you represent the '|' if it needs to be in the left part of the
value?
-- existsInSource, disabled:
So far I think XLIFF is using yes|no for Boolean rather than true|false.
Maybe we could be consistent?
cheers,
-yves
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that generates
this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]