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

RE: ITS requirements categorization

From: Masaki Itagaki <imasaki@qwest.net>
Date: Wed, 2 Mar 2005 23:02:21 -0700
To: public-i18n-its@w3.org
Message-ID: <E1D6jPn-0003bk-QY@frink.w3.org>

Breaking down into data information and rendering information makes it
clearer. Here are a few comments:

[2.4] Provision of a SPAN-like element

I still thing this is a sort of "element version" of annotation vs.
"attribute version" (or [2.5] Note to localisers). If you need to put
remarks on any part of XML document for I18N/L10N, use either <SAPN>-like
elements or "note to localisers" attributes -- this is how I interpreted
these two requirements. Maybe I need more clarification on them. 

[2.12] Describing other cultural aspects of the content  
We should discuss further on this since this could be a critical
requirement. But when I read the description of this requirement, the first
example that popped up my mind was "translation styles." For example, in
Italian, they use a formal writing style for, say, user guides, while they
use more informal style for on-line help contents. In Japanese, we could use
two different styles for user guides - a formal style (so-called "Da/Dearu
tone") and a polite style (so-called "Desu/Masu tone"). Depending on these
styles, the same source content could be translated in two different ways
(meaning that it could lead to two different target content units). So, from
this point, this requirement could be under "Information for the data".
Again, we'll need to clarify this item, though.

Masaki Itagaki

-----Original Message-----
From: public-i18n-its-request@w3.org [mailto:public-i18n-its-request@w3.org]
On Behalf Of Yves Savourel
Sent: Wednesday, March 02, 2005 10:43 AM
To: public-i18n-its@w3.org
Subject: RE: ITS requirements categorization

Hi all,

Here is a try of how I would categorize the different requirements we have
up so far.
Like Masaki I've used the kept the numbers between [] for reference to the
document. I've also added a few things.

== Localization annotations
Things that are additional information for the localizers.

[2.5] Note to localisers

== Information about the data
Things that could be used by the translation or other text-oriented tools
spell-checkers, etc.) when processing the documents. I guess this is also
by the localizers, but I'm making a distinction because the informations
are more geared toward things the tools need.

[2.17] Allowed characters

[2.18] Term identification

[2.19] Inline and subflow elements

[2.20] Word breaking
Note to have in the description for this: This is limited to inline

[2.21] White space handling
(May be in "Information for rendering" too?)

[2.2+2.3] Identification of text to translate
I would merge [2.3] (Direct identification of content that should not be
translated) and [2.3] (Indirect identification of content that should not be
translated) into one requirement because it seems that the it's the same
but with different 

[Addition] Identification of text to word-count
(From Tim's early comments).

[Addition] Identification of text to segment
(From Tim's early comments).

[Addition (maybe?)] Location of the translation
In some documents the translation may have to go to a place different from
source location This is not necessarily for multilingual original documents,
also for XML formats used for translation (XLIFF is one, but I come across
as well). It maybe a 'property' level thing only though: I can't imagine an
example where we would do this in a document instance.

[2.15] Indication of container size

== Information for rendering
Things that should be used directly by the user agents to render properly

[2.23] Markup to support international script features

[2.11] Declaring the language of the content

[2.22] Unicode characters vs. markup

[2.10] Character encoding declarations

== Best Practices
Things that are choices made by the DTD/Schema developers in the
architecture of
their XML formats.

[2.6] Attributes and translatable text

[2.14] References to UI messages in documentation

[2.9] Unique identifiers

[2.13] Citations

[2.7] Emphasis & document conventions

[2.16] Infinite naming scheme (avoiding it)

== Not sure
Things that don't seem to fit in any other categories.

[2.8] Tags with linguistically-dependent scope

[2.24] Support for localisable resource data 

[2.12] Describing other cultural aspects of the content

[2.4] Provision of a SPAN-like element
It seems to be a different type of requirement: Something to do with the
different types of implementations we could have. That could be in a part we
set and localization properties are discussed.

Received on Thursday, 3 March 2005 06:02:27 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:43:04 UTC