- From: Marcos Caceres <marcosc@opera.com>
- Date: Thu, 19 Mar 2009 16:30:11 +0100
- To: Jere.Kapyaho@nokia.com
- Cc: Mark.Priestley@vodafone.com, public-webapps@w3.org
On Thu, Mar 19, 2009 at 4:22 PM, <Jere.Kapyaho@nokia.com> wrote: > I still think that more than one config document is the most confusing > aspect of this. Having just one (mandatory) config document, with the > localized parts tagged with xml:lang attributes would be the simplest. > However, as I understand it, the separate config files were recommended by > the W3C I18N group. > > If this decision would be reversed, then anything in the config document > that could (as per the schema) have an xml:lang attribute would by > definition be localizable/localized. Others (like id, version etc.) would > not be. That would also free the implementation from collecting all the > various config documents, just to create and store an intersection of the > elements. If you have two values for the same element, then who wins? The > most specific (from the config in the localized folder), or the least > specific (the default/fallback one from the root)? > > Proposal (feel free to ignore, due to pressure to be feature complete): make > the config file mandatory, but allow it only in the root, then allow > multiple elements with unique xml:lang attributes for those elements that > are localizable. > True, that would solve this whole mess. Even thought the XML i18n guidelines say it's bad practice, Addison Phillip of the i18n WG suggested we do this in the LC feedback. I emailed them about a month ago asking them if that is the right way to go, but never got a response. So I say we go with Jere's proposal here. -- Marcos Caceres http://datadriven.com.au
Received on Thursday, 19 March 2009 15:30:51 UTC