- From: Marcos Caceres <marcosc@opera.com>
- Date: Fri, 9 Oct 2009 13:33:13 +0200
- To: public-webapps <public-webapps@w3.org>
During implementation, we found unnecessary complexity/redundancy with the combination of icon + xml:lang + folder based localization. The problem is that icons are specified as a list of icons, with different media types, of which the AU selects the one that is most suitable. Adding folder-based localization to that makes the list two-dimensional, which is easy to handle. We just use the same path lookup as for any other resource, i.e once we have decided that we want the SVG version, we just pick the appropriate icon from the most relevant localized path. If we add xml:lang to that, we get a three-dimensional list, from which we need to find not only the best media type, we need to find the best language declaration, and then see if it is available in a localized folder. So, if I have these this icon defined: <icon src="bork.svg" xml:lang="sv"> And these files: locales/en/bork.svg bork.svg icon.svg icon.ico Language list set to "en,sv" I would end up with picking "locales/en/bork.svg" instead of "default.svg" as the xml:lang pass would select the bork.svg as being the localized one (whereas the others are unlocalized), while the folder-based lookup would pick the one in locales/en as the "en" locale is preferred. For simplicity, keeping a two-dimensional lookup of media type × locales folder makes the implementation easiest and yields the least surprises. Proposed changes to spec: 1. The icon element would not support xml:lang. So: [[ Localizable via xml:lang: Yes, multiple repetitions of the same xml:lang value are allowed. ]] Becomes: [[ Localizable via xml:lang: No. Relies on folder-based localization. ]] 2. the concept of "elements are grouped by language" gets removed from the Element-Based Localization section. 3. In Step 7, step 7 gets dropped. -- Marcos Caceres http://datadriven.com.au
Received on Friday, 9 October 2009 11:34:05 UTC