W3C home > Mailing lists > Public > public-i18n-its@w3.org > January to March 2005

Re: Indicator of container size

From: Martin Duerst <duerst@w3.org>
Date: Mon, 07 Mar 2005 01:10:34 +0900
Message-Id: <6.0.0.20.2.20050307010045.08b61a20@localhost>
To: "Yves Savourel" <ysavourel@translate.com>, <public-i18n-its@w3.org>

At 12:42 05/03/06, Yves Savourel wrote:
 >
 >Hi everyone,
 >
 >Here is the first rought draft of the requirement for "Indicator of
 >container size".
 >
 >
 >==================================================
 >Description:
 >
 >Where fixed sizes are used for containers or objects (such as tables, table
 >cells, frames, buffers, screens, images, etc.) a
 >standard method should be used for indicating the dimensions of the
 >container so that localization tools can automatically recognize
 >them.

Are these restrictions on a single item, or are they the same
on all items of the same type (e.g. all <menu> items,...)?
(My guess is that there are several cases.)

Are the restrictions the same for all languages? I can immagine
that while one tries to keep it that way, sometimes certain
markets may just absolutely require higher resolution. What
would be the way to handle that.


 >Background:
 >
 >This helps the localizers to ensure that the content will fit as text
 >expands in translation or if graphics need to be adapted.
 >
 >This can also be used by localization tools to verify size restriction
 >related to the implementation of the application where the
 >content is used. For instance, to check that a translation does not
 >overflow a buffer, or a display area.
 >
 >For example, the content of the following <string> element must accommodate
 >the length restriction imposed by the small display
 >panel where it is used:
 >
 ><!-- LED display has only 16 characters -->
 ><string id="123">Printing...</string>
 >
 >
 >Notes:
 >
 >XSD (XML Schema Part 2: Datatypes Second Edition) provides a mechanism to
 >define "Constraining Facets"
 >(http://www.w3.org/TR/xmlschema-2/#rf-facets) that may provide some
 >solution for this requirement.
 >
 >Sometimes the size constraint may need to be expressed in a unit different
 >from the unit used in the document. For example, The
 >maximum length of a string may need to be expressed in byte or pixels
 >instead of character.

I think the term "display cell" may often be helpful in this context.
We might be able to refer to the Unicode TR about (East Asian) width,
at least for some cases of this (sorry, currently offline).

 >This might lead to the possible
 >requirement of being able to specify additional information (e.g. encoding,
 >font, etc.) along with the size constraint. [Do we want
 >to go there???]

I don't want to go there, but I guess we might have to go there :-(.

 >==================================================
 >
 >For each requirement section, the idea is to discuss its content, its
 >wording, to add, trim, edit, and get to the point where we
 >have a consensus. So, fire away...

Yes, please. But please remember that we should avoid to polish
the requirements to final perfection before starting any work
on actual tags. If we think we have a good idea of what we need,
we should leave it at that and if necessary come back later to
tweak the requirements based on actual 'implementation' experience.


Regards,    Martin. 
Received on Sunday, 6 March 2005 16:40:51 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:12:44 GMT