- From: Shaun McCance <shaunm@gnome.org>
- Date: Wed, 11 Jul 2012 23:52:09 -0400
- To: public-multilingualweb-lt@w3.org
NB: I know I'm supposed to write the text for the Locale Filter data category, and I thought action 107 was for that, but I now see it's associated to issue 10, which is different. This is the proposal for Locale Filter. ---------------------- = Locale Filter == Definition The Locale Filter data category specifies that a node is only applicable to certain locales, or that it is not applicable to certain locales. This data category can be used for several purposes, including, but not limited to: * Include a legal notice only in locales for certain regions. * Drop editorial notes from all localized output. The Locale Filter data category is only valid on element nodes, and associates with each node a filter type and a locale list. The locale filter type can take the following values: * "all": The element is included in all locales. * "none": The element is included in no locales. * "include": The element is only included in locales in the locale list, or sublocales of locales in the locale list. * "exclude": The element is included in all languages except those in the locale list, or sublocales of locales in the locale list. The locale list is a comma-separated list of locale tags from BCP 47. The list MAY contain whitespace, which MUST be ignored. A sublocale is any locale that can be formed only by adding subtags. If the locale filter type is "all" or "none", a locale list SHOULD NOT be provided. If one is, it MUST be ignored. If the locale filter type is "include" or "exclude", a locale list SHOULD be provided. If one is not, it MUST default to the empty list. == Implementation The Locale Filter data category can be expressed with global rules, or locally on an individual element. The information applies to the textual content of the element, including child elements and attributes. The default is that the locale filter type is "all". If the Locale Filter data category is specified multiple times for an element, the normal precedence rules apply, and the value of the locale list with the highest precedence is applied. The locale list is not a combination of values from multiple rules. GLOBAL: The localeFilterRule element contains the following: * A required selector attribute. It contains an XPath expression which selects the nodes to which this rule applies. * A required localeFilterType attribute with the value "all", "none", "include", or "exclude". * An optional localeFilterList attribute with a comma-separated list of locales. LOCAL: The following local markup is available for the Locale Filter data category: * A localeFilterType attribute with the value "all", "none", "include", or "exclude". * A localFilterList attribute with a comma-separated list of locales. -------------------- NB: The requirements document uses "positive" and "negative" instead of "include" and "exclude". I think "include" and "exclude" suggest the functionality more clearly. I added "all", because that is the default behavior, and I think it's important for a rule to be able to reset things to the default. The requirements document uses a semicolon as a list delimiter rather than a comma. The example given in section 4.3 of BCP 47 uses commas, though it doesn't seem to actually specify it. Commas are also used by the HTTP Accept-Language header. Is there a reason to prefer a semicolon?
Received on Thursday, 12 July 2012 03:52:33 UTC