Ciao Brian, > Analysis: > * description is the one that will always need it
Right. > * I think the values for "block" and "category" should be considered > as 'keys' rather than the actual values - they should be translated > by lookup table. I agree. Keys are better and, whenever there's another key, we just need to modify the DTD. > * examples will *sometimes* require translation Are you planning to use just the value of the attribute in the example? Usually an example is made up of just a pair (name of attribute: value). I guess we could use the value, as long as the attribute comes from the element itself. Sometimes we may need a description for the example too; for instance: accept_language: fr description: set the HTTP language to be sent to the server to 'french' What do you think? > This would then put the capability into the XML file. I would need to > figure out how to do characters like é - possibly as é . As to Well ... I dunno. However this characters are not permitted in XML, if I am not wrong. XML supports unicode and doesn't know anything about SGML entities like 'é'; we should use the exact hex representation code (for latin1 code goes from 80 to D7FF). But this is an almost unknown world for me. > * how this might then be used to generate documentation > * how the translated versions will be maintained We could make up translations group. And ... if worse comes to worst, we could just use the english one. I could maintain the italian one. No troubs. > Note that it isn't a big change, but I think we should leave > it for version 2 defaults.xml. Is it a problem for you to enable translations already? Would it change much for you? Thanks a lot Brian, -Gabriele -- Gabriele Bartolini - Web Programmer Comune di Prato - Prato - Tuscany - Italy [EMAIL PROTECTED] | http://www.comune.prato.it > find bin/laden -name osama -exec rm {} ;
signature.asc
Description: PGP signature
