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

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

From: David Lewis <dave.lewis@cs.tcd.ie>
Date: Thu, 03 May 2012 00:59:39 +0100
Message-ID: <4FA1CA6B.80205@cs.tcd.ie>
To: public-multilingualweb-lt@w3.org
Dear all,
I've now implemented this consolidation, replacing localeSpecificContent 
and  droprule with locale-filter:
http://www.w3.org/International/multilingualweb/lt/wiki/Requirements#locale-filter

Shaun, I included your working and added notes about your two concerns 
whcih we need to think about more when we get to the actual meta-data 
definition.

cheers,
Dave


On 29/04/2012 17:53, Shaun McCance wrote:
> 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:
>
> http://lists.w3.org/Archives/Public/public-multilingualweb-lt/2012Apr/0143.html
>
> 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
> "negative"?
>
> What happens when this is declared multiple times? Does each override
> the previous? Is there an attempt to augment or restrict the lists?
>
> --
> Shaun
>
>
>
Received on Thursday, 3 May 2012 00:00:01 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:31:44 UTC