RE: [ACTION 107] Locale Filter

Hi Shaun, all,

Thanks for the nice definition.
I have just a few notes:


1- We define 'sublocale' as "A sublocale is any locale that can be formed only by adding subtags.", but we don't use the term anywhere in the text other than in the definition. Maybe we could get rid of the definition? (definition are often controversial).

2- The text "The Locale Filter data category is only valid on element nodes" seems to restrict the selector to point to element nodes. Is there s reason for that? I think we should be able to define a locale filter to attributes as well: the translatable ones may need to be excluded just like an element.

3- A bit later we have "...and associates with each node..." I think it associates only with the selected nodes. Maybe the sentence "The Locale Filter data category is only valid on element nodes, and associates with each node a filter type and a locale list." could probably be something like: "The locale filter data category associates the selected nodes with a filter type and a locale list".

4- (Very minor): I wonder if the paragraph "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." is helpful: It repeats what the section 6.1 says and just adds the bit about not combining rules. Maybe it could be reduced to just states that? Note that we don't warn about combining rules in other data categories like locNote.

5- I agree with "include" and "exclude" rather than "positive" and "negative": it's much better.

6- And now, just for fun: All that same functionality could be defined with a single attribute that has a simple regex expression. You would try to match a given target locale code to the expression: if it matches it's included, if it doesn't it's not. "all" would be ".*", "none" would be "". Such mechanism is used in SRX for example to select which rules to apply to which languages.
I'm not really saying we should go that way, since a regex has its problems too. But it may be worth a thought, because what I'm really getting at is an implementation question: if I see "fr" does it mean "fr-ca" as well?
This may be answered by the use or not of the BCP47 filtering definition. In any case, we probably want something explicit about this.

Cheers,
-yves


-----Original Message-----
From: Shaun McCance [mailto:shaunm@gnome.org] 
Sent: Thursday, July 12, 2012 5:52 AM
To: public-multilingualweb-lt@w3.org
Subject: [ACTION 107] Locale Filter

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 06:02:09 UTC