W3C home > Mailing lists > Public > public-multilingualweb-lt@w3.org > July 2012

RE: Re: [ACTION-160] (related to [ACTION-135] too) Summarize specialRequirements

From: Yves Savourel <ysavourel@enlaso.com>
Date: Mon, 9 Jul 2012 18:55:09 +0200
To: "'Felix Sasaki'" <fsasaki@w3.org>, "'Michael Kruppa'" <Michael.Kruppa@cocomore.com>
Cc: <public-multilingualweb-lt@w3.org>, <fredrik.estreen@lionbridge.com>
Message-ID: <assp.0537ca66a7.assp.0537b33d1f.005801cd5df3$9c9e2b60$d5da8220$@com>
Hi Felix, all,

XLIFF 1.2’s charclass is a typical example where XLIFF made the mistake of defining an attribute without defining a clear set of value (or an open-end set).

There is no way work really work transparently with this property.

See https://lists.oasis-open.org/archives/xliff/200203/msg00014.html for a tentative set of values, and https://lists.oasis-open.org/archives/xliff/200204/msg00019.html . That's more than 10 year ago... 

I'm not sure the CSS-based value idea was a good one. A regex sounds a lot better now. But it never made it to the specification anyway.

So would not worry too much about charclass in 1.2. The intent is certainly a class of chars rather than a regex. Then we can use an ITS attribute for a regex. Since nothing is defined we can't be breaking any interoperability.

We do have to make sure 2.0 is interoperable though.

Pedro, Arle: charclass is a good example of why I don't like 'user-defined' lists and open-ended values :)

cheers,
-ys 


From: Felix Sasaki [mailto:fsasaki@w3.org] 
Sent: Monday, July 09, 2012 6:37 PM
To: Michael Kruppa
Cc: Yves Savourel; public-multilingualweb-lt@w3.org; fredrik.estreen@lionbridge.com
Subject: Re: Re: [ACTION-160] (related to [ACTION-135] too) Summarize specialRequirements

Hi Michael, all,

A question to the XLIFF people in this thread: how do "forbidden characters" related to XLIFF? I see at
http://docs.oasis-open.org/xliff/v1.2/cs02/xliff-core.html#charclass
that there is a charclass attribute saying
"This indicates that a translation is restricted to a subset of characters (i.e. ASCII only, Katakana only, uppercase only, etc.). "
What would we do if there is an XLIFF file with charclass allowing some characters that are forbidden by a "forbidden characters" data category?

Felix
2012/7/9 Michael Kruppa <Michael.Kruppa@cocomore.com>
Hi Felix, 

max-size is relevant to us. But we would also like to support the forbidden chars since this may be relevant when storing translated content and certain characters may also lead to problems when integrating them with html and javascript code generated by the CMS.

So, we hope that we can clarify the forbidden chars topic.

Best

Micha




Von Samsung-Tablet gesendet

Felix Sasaki <fsasaki@w3.org> hat geschrieben:

Hi Michael, 

just a clarification question: do you mean max-size? So far for the other aspects of specialRequirements, we don't have a clear definition, so we may end up "just" with max-size.

Best,

Felix
2012/7/9 Michael Kruppa <Michael.Kruppa@cocomore.com>
Hi all,

I would just like to point out that for us, the specialRequirements meta tag appears to be of high relevance with respect to some of the business cases we have in mind for future usage of ITS. Therefore, we would like to declare our strong support for this meta tag and we will be happy to implement it on the CMS side.

Cheers

Micha

________________________________________
Dr. Michael Kruppa, Senior IT-Consultant
Tel.: +49 69 972 69 189 Fax: +49 69 972 69 204; E-Mail: michael.kruppa@cocomore.com
Cocomore AG, Gutleutstraße 30, D-60329 Frankfurt
Internet: http://www.cocomore.de Facebook: http://www.facebook.com/cocomore Google+: http://plus.cocomore.de
Cocomore ist aktives Mitglied im World Wide Web Consortium (W3C) und im Bundesverband Digitale Wirtschaft (BVDW)
Cocomore is active member of the World Wide Web Consortium (W3C)
Vorstand: Dr. Hans-Ulrich von Freyberg (Vors.), Dr. Jens Fricke, Marc Kutschera, Vors. des Aufsichtsrates: Martin Velasco, Sitz: Frankfurt/Main, Amtsgericht Frankfurt am Main, HRB 51114



-----Ursprüngliche Nachricht-----
Von: Yves Savourel [mailto:ysavourel@enlaso.com]
Gesendet: Montag, 9. Juli 2012 09:58
An: 'Felix Sasaki'
Cc: public-multilingualweb-lt@w3.org; 'Fredrik Estreen'
Betreff: RE: [ACTION-160] (related to [ACTION-135] too) Summarize specialRequirements
Hi Felix, all,

> So I think - if I understand you correctly - what you want to achieve
> is that tools that make use of metadata that is coming from various
> sources (XLIFF, ITS, PO, ..). Currently that metadata is not coming at
> all, or only in priority ways. The aim now is to have one agreed
> metadata definition for max-size, right?
> ...
> ...
> What worries me then is that we aim to create a single piece of
> metadata, which is not part of the big picture. That raises several
> questions / requirements:

Maybe it'll help to go back at the root of this requirement (as far as I understand it):

Sometimes a string to be translated has a limitation on how long it can be. The limitation can be in the storage (fixed length DB field in a CMS for example), or in the display: We are talking about the storage here.

What I think ITS needs to provide is the way to pass that information down the consumer tools so the limitation can be verified at some stage (for example: during the translation, or/and at a QA step after).

That's the "big picture" for me. I'm not sure what you mean by "special purpose length solution". To me the proposal Giuseppe has for maxStorgeSize is rather general.

But maybe I'm missing your point.
-yves






-- 
Felix Sasaki 
DFKI / W3C Fellow





-- 
Felix Sasaki
DFKI / W3C Fellow
Received on Monday, 9 July 2012 16:55:50 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:31:47 UTC