- From: Masaki Itagaki <imasaki@qwest.net>
- Date: Wed, 2 Mar 2005 23:02:21 -0700
- To: public-i18n-its@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 come up so far. Like Masaki I've used the kept the numbers between [] for reference to the old 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 (like spell-checkers, etc.) when processing the documents. I guess this is also used by the localizers, but I'm making a distinction because the informations here 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 elements. [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 one, 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 the source location This is not necessarily for multilingual original documents, but also for XML formats used for translation (XLIFF is one, but I come across other 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 the text. [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 tag set and localization properties are discussed. Cheers, -yves
Received on Thursday, 3 March 2005 06:02:27 UTC