RE: Other possible areas to cover under ITS

Hi guys,

Thanks Tim for the clarification.

Can we say then that ITS does not try to cover the localisation properties case (separate file, with information that can be applied uniformly across the entire XML instance file)? And focus only on l10n directives (embedded information in XML instance file)?


/François

>>-----Original Message-----
>>From: Tim Foster [mailto:Tim.Foster@Sun.COM] 
>>Sent: Tuesday, March 01, 2005 1:07 PM
>>To: Richard, Francois
>>Cc: Martin Duerst; Yves Savourel; public-i18n-its@w3.org
>>Subject: RE: Other possible areas to cover under ITS
>>
>>
>>Hey Francois,
>>
>>On Tue, 2005-03-01 at 11:15, Richard, Francois wrote:
>>> Pieces of content that within the same XML file do not necessarily
>>> follow the same rules (syntax, segmentation, ...). And for which in
>>> most cases, dtd or schema have not been defined.
>>
>>Yep, I know that feeling. Very awkward to deal with alright -
>>thankfully, we only have one group sending such stuff to our tools at
>>Sun, but it would be really nice to "re-educate" them (with something
>>other than a baseball bat ;-)
>>
>>> I personally would benefit from being reminded what is the 
>>distinction
>>> between localization directives/tag set vs. localization properties.
>>
>>I think the thing we were trying to describe was :
>>
>>* localisation directive:
>>
>>Some means by which a file itself can declare the sections of
>>localisable content within the content of the file : in our case, we
>>were suggesting namespaces for this purpose.
>>
>>eg. a translatable file "tim.xhtml" would include namespaces to markup
>>the fact that <p> elements contain translatable text, 
>><strong> and <em>
>>are inline elements that shouldn't cause segmentation, <code> 
>>should not
>>be segmented, etc.)
>>
>>
>>
>>* localisation properties:
>>
>>A separate configuration file, per XML type, which describes the
>>localisable content of a given XML input file.
>>
>>eg. "tim.xhtml" would need the special properties file 
>>"xhtml-type.properties"
>>
>>xhtml-type.properties may look something like :
>>
>>translatable-content=p,em,strong
>>inline-tags=em,strong
>>preserve-whitespace=pre
>>do-not-segment=code
>>
>>(of course, you would probably want to write that properties file in
>>XML, I'm just putting it this way for brevity)
>>
>>-- so, if you think about it, for localisation directives, no 
>>extra work
>>should be needed on behalf of the tools writer to extract localisable
>>content from the input file to be translated.
>>
>>For localisation properties, the tools writer needs to have a
>>pre-configured localisation properties file tailored for the 
>>input file
>>type. If one doesn't exist, the tools writer would have to 
>>get access to
>>the xml dtd/schema in order to create one.
>>
>>Hope this helps,
>>
>>	cheers,
>>			tim
>>
>>
>>> >>-----Original Message-----
>>> >>From: Martin Duerst [mailto:duerst@w3.org] 
>>> >>Sent: Friday, February 25, 2005 8:50 AM
>>> >>To: Richard, Francois; public-i18n-its@w3.org
>>> >>Subject: Re: Other possible areas to cover under ITS
>>> >>
>>> >>
>>> >>Hello Francois,
>>> >>
>>> >>Some very interesting ideas. A few comments below.
>>> >>
>>> >>At 23:37 05/02/23, Richard, Francois wrote:
>>> >> >
>>> >> >Hello,
>>> >> >
>>> >> >Here are some areas that are not exactly covered in  
>>> >>>http://people.w3.org/rishida/localizable-dtds/ or could be 
>>> >>added to some  
>>> >>>sections. I am not sure if all of these fall in the scope of 
>>> >>ITS, but here  
>>> >>>is the list I came up with:  
>>> >>>
>>> >> >- Preview information such as XSLT, specific XML editor.
>>> >> >It useful when it is necessary to preview the XML content 
>>> >>in an effort of  
>>> >>>display context info to help in the l10n of the content.
>>> >>
>>> >>I'm not sure I understand this. There is the stylesheet PI 
>>> >>for XSLT (http://www.w3.org/1999/06/REC-xml-stylesheet-19990629/).
>>> >>Would that do the job, or do you mean something else?
>>> >>
>>> >> >- Font information to indicate either that the element 
>>> >>carries a font  
>>> >>>information (to be l10ed) or to indicate which specific font 
>>> >>to use to  
>>> >>>render l10ed content.
>>> >>
>>> >>Why should font information be in the document? Are the 
>>> >>stylesheet languages we have (CSS, XSL-FO) not good enough?
>>> >>
>>> >> >- Substitution rules: It help in define automatic 
>>> >>substitution. For  
>>> >>>instance for unit of measure, URL l10n (http://.../en/US/... 
>>> >> ->  >http://.../fr/CA/...). The list is long and it would be 
>>> >>nice to be able to  
>>> >>>embedded the rules themselves. It could be part of 2.19
>>> >>
>>> >>Should the rules be embedded in the actual documents?
>>> >>I think it might be better to have a pointer to such rules, 
>>> >>external to the document, because such rules are likely the 
>>> >>same for a lot of documents. Also, quite some part of such 
>>> >>rules could be expressed in XSLT (in particular XSLT 2.0).
>>> >>
>>> >> >- Element syntax: Some elements need to follow certain 
>>> >>syntax. I am  
>>> >>>thinking about a coma-delimited list for instance.
>>> >>
>>> >>This is much more general than just localization. XML Schema 
>>> >>has regular expressions (patterns) for this. I don't think we 
>>> >>should do anything more in this area, because there is quite 
>>> >>some contention; some people consider using commas,... as bad 
>>> >>XML design.
>>> >>
>>> >> >- Targeted country: With the limitation of locale, it is 
>>> >>useful to be able  
>>> >>>to specify a country for which the content is targeted. This 
>>> >>might be in  
>>> >>>2.12 already.
>>> >>
>>> >>Is that before the localization, or after? Before, there
>>> >>are potentially very many targets. Afterwards, it may indeed 
>>> >>make sense to have some kind of indication e.g. to say 
>>> >>"measures in this document are in locale X". If we want to do 
>>> >>something in this direction, it is crucial to coordinate with 
>>> >>the I18N Core WG, because they have some work items in this 
>>> >>direction (locale identification,..., in particular for 
>>Web Services).
>>> >>
>>> >> >- Segmentation rules. Some element could follow a specific 
>>> >>segmentation  
>>> >>>that needs to be specified.
>>> >>
>>> >>Again, the question is whether the actual rules should be in 
>>> >>the document, or just a pointer.
>>> >>
>>> >>Regards,    Martin. 
>>> >>
>>> >>
>>-- 
>>Tim Foster - Tools Engineer, Software Globalisation
>>http://sunweb.ireland/~timf http://blogs.sun.com/timf
>>http://www.netsoc.ucd.ie/~timf
>>
>>

Received on Tuesday, 1 March 2005 14:58:10 UTC