RE: Input to BP4 http://www.w3.org/International/its/techniques/its-techniques.html#DevTrans

Hi Christian, all,

I think the creation of a rules file with translateRule is the most important point of this BP.

Wouldn't we be deluting too much the main point by have text about the best ways to document the schema?

>From a localizer viewpoint I wouldn't care much wether an XML Schema is documented or not, or even if there is a schema or not, as
long as I get XML files with a corresponding rules file, correctly done.

As Christian noted, this aspect is something we will see each time we have a "create a rules file and use the xyzRule ITS element to
etc...". Maybe it should be along the section where General Techniques: how to best integrate ITS rules with your schema
documentation. ?

For the note about how best to write Xpath expression, it seems it should go in the section about that (General Techniques)

For the part about the defaults etc. I think that ceratinly could go somewhere near the top, before the example. But then we need
something for the "Why Do This" part.


Cheers,
-yves



 

-----Original Message-----
From: public-i18n-its-request@w3.org [mailto:public-i18n-its-request@w3.org] On Behalf Of Lieske, Christian
Sent: Friday, June 08, 2007 3:49 AM
To: public-i18n-its@w3.org
Subject: Input to BP4 http://www.w3.org/International/its/techniques/its-techniques.html#DevTrans

Hi all,

I had several comments for "Best Practice 4: Indicate the translatability of elements and attributes". Rather than sending the
comments, I have worked on alternative wording for the prose (ie. all text except for the one in the
examples) of BP 4.

Overall rationale:

- The original text heavily focuses on ITS rules. From my understanding, however, the general thing we first want to say is
"document your code", only afterwards we recommanded ITS rules as the most convenient and important way of doing this.

- The fact that attributes should not be used to hold translatable content, might become more prominent in the proposed alternative
wording.

Cheers,
Christian
===

Best Practice 4: Indicate translatability 

Document which elements and attributes may contain translatable content.

Note: It is not recommanded to have translatable attributes (see BP 3).

How to do this

In order to ensure that your DTD or schema is in sync with its documentation, you may want to consider a literate programming
approach.
This approach, which is for example realized in ODD, helps to ensure that code and accompanying prose do not get out of sync. Please
check your environment and schema language to see what is possible (in DTDs you may want to use ordinaly XML comments, whereas in
XSDs, you should use "xsd:documentation").

It is recommended to document by means of the ITS data category "translatability" rather than something like unrestricted prose. To
be specific, you should provide an ITS rules document where you use "its:translateRule" elements to indicate which elements and
attributes have non-translatable content. ITS rules communicate effectively and in a formal way the information that is needed. 

When creating the ITS rules for translatability you may keep in mind that ITS defines the following defaults:

- elements: translatable
- attributes: not translatable

Thus, your ITS rules would only need to capture the cases where the defaults do not apply (such as an "alt" attribute containing a
text for an "img"
element.

Note: If some the content of an element is flagged with xml:lang="zxx", where zxx indicates a content that is not in a language, the
corresponding element is a good candidate as being mentioned in an "its:translateRule".

Note: Please consider your overall environment to decided whether single more complex XPath expressions such as

	 <its:translateRule selector="x|y|z/x/foo" translate="no"/>

	should be prefered over multiple, simpler XPath expressions such as 

	 <its:translateRule selector="x" translate="no"/>
	 <its:translateRule selector="y" translate="no"/>
	 <its:translateRule selector="z/x/foo" translate="no"/>

      Things to consider may for example be readability or processing efficiency.

Christian Lieske
MultiLingual Technology Solutions (MLT)
SAP Language Services (SLS)
SAP Globalization Services
SAP AG
Dietmar-Hopp-Allee 16
D-69190 Walldorf
Germany
T   +49 (62 27) 7 - 6 13 03
F   +49 (62 27) 7 – 2 54 18
christian.lieske@sap.com <blocked::mailto:christian.lieske@sap.com>
http://www.sap.com <blocked::http://www.sap.com/> 

Sitz der Gesellschaft/Registered Office: Walldorf, Germany

Vorstand/SAP Executive Board: Henning Kagermann (Sprecher/CEO), Léo Apotheker (stellvertretender Sprecher/Deputy CEO), Werner
Brandt, Claus Heinrich, Gerhard Oswald, Peter Zencke

Vorsitzender des Aufsichtsrats/Chairperson of the SAP Supervisory Board:
Hasso Plattner 

Registergericht/Commercial Register Mannheim No HRB 350269

 

Diese E-Mail kann Betriebs- oder Geschäftsgeheimnisse oder sonstige vertrauliche Informationen enthalten. Sollten Sie diese E-Mail
irrtümlich erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts, eine Vervielfältigung oder Weitergabe der E-Mail ausdrücklich
untersagt.

Bitte benachrichtigen Sie uns und vernichten Sie die empfangene E-Mail.
Vielen Dank.

 

This e-mail may contain trade secrets or privileged, undisclosed, or otherwise confidential information. If you have received this
e-mail in error, you are hereby notified that any review, copying, or distribution of it is strictly prohibited. Please inform us
immediately and destroy the original transmittal. Thank you for your cooperation.

Received on Monday, 11 June 2007 19:04:13 UTC