RE: [xliff] Our review

Hi Jung, David.

I completely agree on the lack of processing requirements regarding re-segmentation. It is a long time open issue. Especially with respect to data defined on the segment level. But there are issues with the PRs on more places. Most can probably be resolved without schema changes. But the segment one I think might need additional constructs at the XML level to make it nice (attribute to disallow re-segmentation). I’m not in favor of disallowing it per se, but given the current status it is better than not doing it.

Here is an abbreviated example of restricting one unit to 20 characters or less. Without caring for normalization, so a minimal case. Select the simple codepoints profile in the slr:profiles element. Put a sizeRestriction on the <unit>.

<xliff>

<file>

<slr:profiles general=”xliff:codepoints” />

…..

….

</unit>

….

Same example but marking one sentence in a unit. I deliberately did not put size restrictions on <segment> or <source> as to not have it interfere with segmentation. Instead it uses <mrk> in the inline content.

<xliff>

<file>

<slr:profiles general=”xliff:codepoints” />

…..

<unit>

<source><mrk slr:sizeRestriction=”20”>My short sentence</mrk></source>

</segment>

</unit>

…

Regards,

Fredrik Estreen

From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Dr. David Filip
Sent: den 12 april 2013 22:21
To: Jung Nicholas Ryoo
Cc: xliff@lists.oasis-open.org
Subject: Re: [xliff] Our review

Thanks, Jung, Victor,

answers inline..

Dr. David Filip

=======================

LRC | CNGL | LT-Web | CSIS

University of Limerick, Ireland

telephone: +353-6120-2781

cellphone: +353-86-0222-158

facsimile: +353-6120-2734

mailto: david.filip@ul.ie

On Fri, Apr 12, 2013 at 3:21 PM, Jung Nicholas Ryoo <jungwoo.ryoo@oracle.com> wrote:

Hi all,

Victor and I reviewed the latest revision of XLIFF specification document. We are happy for most of the development, so we will reply soon with most probably the option 1 or the new 5 if the

two are ever different.

There is a subtle difference.. :-)

1 states roughly: I have no issues with the draft at all

5 states roughly: I might be aware of minor issues here and there, still I think the draft is mature enough to go the next step..

The goal is to identify reasons for possible answers 2-4 to be able to handle dissent on critical matters in a timely manner..

Here are a few questions before that.

1) Section 2.8 Segmentation still has incomplete processing requirements. In fact, the PR for re-segmentation could be sophisticated. I wonder if this has been lost for a while.

I agree this can be complex. I asked Fredrik and Yves for input here a couple of days ago..

I think that it is OK to have a strawman here if someone submits it by Monday, I can implement and print on time for the meeting

Or leave it openly unspecified in the CSPRD, it is a contentious matter where it might be prudent to have broader input..

Still I'd prefer to go for it with a strawman in place, if Jung, Yves, or Fredrik, (or someone I miss) will submit one..

2) Appendix B: Translation Candidate Module:
According to the schema, the value of score related attributes is ranged from 0.0 to 100.0. Will this restrict us from using more detailed precisions (e.g.: 94.98)? Our quality system always produce two decimal places.

I agree with Yves, it is specified as decimal, it should be a matter of a simple schema fix..

3) Section H: Size Restriction Module
It is very difficult to understand this module. Why should this size restriction module look so complicated?

Generally storage restriction hasn't been critical to us. We are more about restricting the number of characters to avoid any issues on GUI.
The number of characters that can be allowed for the same width of GUI can be different per language.

question) Can somebody help me on how to restrict the translation to less than or equal to 20 characters?

I leave this with Fredrik

4) Section H.1.5.2: "sizesare" => "sizes are"

I leave this with Fredrik

Thanks
Jung

xliff message