W3C home > Mailing lists > Public > public-multilingualweb-lt@w3.org > April 2012

Re: [ACTION-78]Consider consolidation of localeSpecificContent and droprule

From: Shaun McCance <shaunm@gnome.org>
Date: Sun, 29 Apr 2012 12:53:41 -0400
To: public-multilingualweb-lt@w3.org
Message-ID: <1335718421.20969.11.camel@recto>
On Fri, 2012-04-27 at 22:13 +0100, David Lewis wrote:
> > DaveL, Moritz: Could localeSpecificContent be consolidated with
> > dropRule, e.g. specifying the content should be drops for specific
> > locales, for every translation, or for every translation except
> > specified locales?
> > >>Pedro>> Agreed, as long as in “localeSpecificContent” there is a
> > way for saying: not to be translated in any locale. Perhaps for this
> > it also enough Translate: no.

> The objective of localeSpecificContent/dropRule is that it idenitfies
> conent that shouldn't be submitted to the localsiation process at all
> (for all or specific locales). This means, i presume, it should not
> even be included as context. This implies that it should be stripped
> from skeleton file when transformed into XLIFF. 
> In contrast, translate:no retains the element concerned as part of the
> content submitted for localisation, as it may be a meaningful part of
> the content, e.g. a proper name, or useful context, but it is just
> mark not to be translated. Is that everyone's understanding.
> Could we then state the requirement as:
> "Indicate source content elements as only being suitable for
> localisation to specific locales only, for not being suitable for
> localisation to specific locales or for not being suitable for
> localisation at all"

I don't think "suitable for localization" captures the intent. I would
take that to meant the same thing as its:translate, just with control
over languages. Maybe "suitable for inclusion in localization"?

> We might then call it "locale-filter"
> A suggested data model might be
> "locale-filter-type"
> values: "positive", "negative" or "none"
> where value "none" indicates that  the element should not be passed
> for localization under any circumstances
> "positive" means the element MAY ONLY be localised for the locales
> specified in locale-filter-list
> "negative" mean the element MUST NOT be localised for the locales
> specified in the locale-filter-list
> "locale-filter-list"
> value: list of BCP-47 values 

For reference, my outline of the workflow with itstool and how dropRule
fits into it, from the previous thread:


If I understand this correctly, locale-filter-type="none" would be
exactly equivalent to drop="yes". That's easier for me, and better
than the locale="C" hack I'd have had to do (see above email).

I worry that this could be adding complexity without real use cases,
though. I see where "positive" could be useful (e.g. a Swiss legal
notice only in "de-CH;fr-CH;it-CH"), but what's the use case for

What happens when this is declared multiple times? Does each override
the previous? Is there an attempt to augment or restrict the lists?

Received on Sunday, 29 April 2012 16:54:06 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:08:16 UTC