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

[ESW Wiki] Update of "its0509SpecScoping" by YvesSavourel

From: <w3t-archive+esw-wiki@w3.org>
Date: Wed, 12 Oct 2005 03:40:35 -0000
To: w3t-archive+esw-wiki@w3.org
Message-ID: <20051012034035.1723.80072@localhost.localdomain>
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "ESW Wiki" for change notification.

The following page has been changed by YvesSavourel:
http://esw.w3.org/topic/its0509SpecScoping


------------------------------------------------------------------------------
  The 'translate="yes|no"' approach assumes that we are looking at a single data category. The 'translateYes&translateNo approach assumes that we are looking at two different data categories. 
  
  '''[[FS''' I would say that it is one data category which is filled with two data sets (at least) - the two boolean values. Consider e.g. locinfo as a data category: it also might need a default (the locinfo you want to give for the whole document), but this could be overriden in the same way you described for the translation case. So in the case of lofinco, the data set would be a string value, which cannot be integrated into a single or several data categories. The same is true for all kinds of data categories: xml:lang, bidi (example: bidi default, default overriden for an attribute and differently for an element.).  Another point: how would you set back the default (see Martin's comment) back of translatability of you have translateYes and translateNo? with @translate, you could say translate="default". Again, the same is true for xml:lang, bidi etc. I think our solution for scope should not be narrowed to the translatability topic, but be applicable for all the other cases. But I don't know an answer to this requirement yet. To be able to move forward, I would propose: Let's have translateYes and translateNo in the working draft, and see if we get feedback from the rest of the world about a more general solution.''']]'''
+ 
+ '''[[YS-Start[''' translate="yes|no|'empty'" + scope="xpath" solves all cases except when two attributes need to have different overrides. On the other hand translateYes/translateNo seems (to me) a very strange way to define metadata and brings its own set of issue (like setting back to empty, etc.) I would be of the opinion to use translate+scope in the WD.
+ 
+ By the way, now that think about it, one could also use translate+scope for different attributes:
+ 
+ {{{<parent-of-e translate="yes" translateScope="e@a">
+  <e translate="no" translateScope="." a="Review">456</e>
+ </parent-of-e>}}}
+ 
+ so translate+scope can solve all cases :)
+ 
+ ''']End-YS]]'''
  
  To me the approach which is based on two data categories seems more natural. It reminds me of XSD, where we have separate data categories for defaults (namely 'elementFormDefault' and 'attributeFormDefault'. It also reminds me of my own drawers: one where I put things which I need to do, and one where I put things which I do not need to do (aside: that drawer is my recycle bin :-))
  
Received on Wednesday, 12 October 2005 13:25:21 UTC

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