- From: David Lewis <dave.lewis@cs.tcd.ie>
- Date: Thu, 03 May 2012 00:59:39 +0100
- 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