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

Hi Christian,

agree with your proposal except one bit, see below.

Lieske, Christian wrote:
> 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").
>   

my impression is that literate programming schemes like ODD are rarely 
used in XML world, and that people who read "XML i18n BP" are unlikely 
to be aware of such techniques. So I would reposition the sentence about 
ODD, e.g.

"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 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.In XSDs, you should use 
"xsd:documentation". The mechanisms provided by ODD, a basis for 
generating schemas and documentation out of one source document, help to 
ensure that code and accompanying prose do not get out of sync)."

Note also that ODD has a different status than XML Schema / DTD / RELAX 
NG: ODD is not a schema language, but a meta language for describing 
schemas and documentation, from which various schema language specific 
representations can be generated.

Cheers,

Felix

> 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 14:09:17 UTC