Re: switch with systemLanguage is b.roken by standards


oops my error, misreading specs... the language can be obtuse at  
times due to the extreme reductionist approach, which does have it's  
appeal, especially to fundamentalists.


Jonathan Chetwynd

On 17 Nov 2006, at 00:35, Doug Schepers wrote:

Hi, Jonathan-

It's not a bad thought, but I personally don't feel comfortable with  
that.  A properly-authored document will include a fallback, and the  
'switch' element allows for that.  If a fallback isn't provided,  
there may be a reason; for instance, there may only be text warnings  
for languages that the author wants to alert to features in the  
interface, and which shouldn't appear if the language is not found.   
For example, I might want to pop up a disclaimer to users of "en-gb"  
that all terms are in "en-us" (or something); I wouldn't want that to  
appear to "en-us" readers.  There may also be issues where certain  
content is only legally applicable to speakers of a certain language,  
for example.

I know this gets into issues of who should have more control, the  
author or the reader, but if we went that way on this issue, there  
would be no option to prevent content appearing inappropriately, so  
much of the value of the 'switch' element would be lost.

As an aside, note that systemLanguage doesn't only apply to text  
content, but to any rendered content.  So, as an author, I might wish  
to provide text for those language I know, and a symbol for all  
others. 'switch' allows for that.


Jonathan Chetwynd wrote:
> Doug,
> should we explicitly state the case where the author provides a  
> fallback language for switch, in case of no match, also be honoured?
> ie would most users  prefer some content rather than none, which  
> they can than at least paste into babelfish, ask a colleague, copy  
> and paste.....
> cheers
> Jonathan Chetwynd
> On 16 Nov 2006, at 18:19, Doug Schepers wrote:
> Hi, Jonathan-
> I think I agree with you and Stuart Morgan [1] that a negotiated  
> choice with Accept-Language [2] would be better.
> I don't know exactly how we can change it for SVG Tiny 1.2, but I  
> suggest that at the minimum we can issue an errata (maybe even for  
> SVG 1.0), if the rest of the SVG WG agrees.  I'll bring it up in an  
> upcoming telcon soon.
> For 'switch', I will propose text like, "The 'switch' element  
> evaluates the requiredFeatures, requiredExtensions, and  
> systemLanguage attributes on its direct child elements.  The order  
> of evaluation for systemLanguage shall be the order of of  
> preference expressed in HTTP/1.1 Accept-Language if defined.  The  
> order of evaluation for systemLanguage where the language  
> preference is not defined and for requiredFeatures and  
> requiredExtensions shall be the document order.  The first most  
> appropriate child for which these attributes evaluate to true shall  
> be processed and rendered.  All others will be bypassed and  
> therefore not rendered. If the child element is a container element  
> such as a 'g', then the entire subtree is either processed/rendered  
> or bypassed/not rendered."
> (Maybe with an example, for clarity).  If the general premise is  
> accepted by the WG, I will work up similar language for section  
> 5.8.5 (The systemLanguage attribute).
> I can think of 2 arguments against this:
> 1) It may take too much processing for SVG Tiny UAs (I doubt this,  
> but will ask implementors);
> 2) It removes control from the author, who may have listed the  
> different options in order for a reason.  They may only supply  
> fallback "translation" text like, "Please read this document in a  
> browser that understands Arabic" or something (bad practice, but  
> possible).  They may be very comfortable writing in Japanese, and  
> so go into more detail in the first entry, with a more terse  
> translation in English out of necessity.
> That said, I still prefer the language negotiation.
> Note that the UA is not prevented from creating a workaround for  
> this, such as allowing the author to pick one language as the  
> exclusive Accept-Language string on the fly.  A kluge, but it  
> wouldn't break the spec.  Actually, I've wished before that we  
> could allow the UA to give the list of options to the user to let  
> them decide... maybe this could be a new feature for 'switch' in an  
> upcoming version.
> Does this work for you?
> [1]
> [2]
> Regards-
> -Doug
> Research and Standards Engineer
> 6th Sense Analytics
> mobile: 919.824.5482
> Jonathan Chetwynd wrote:
>> Camino developers have suggested that the current definitions used  
>> for 'switch' and 'systemLanguage'
>> mean that it's not possible for the client to express any language  
>> preference.
>> The result is that the user should have no control over the  
>> language displayed, as the first language in the authors switch  
>> statement which is accepted by the client will be used.
>> It is evident this will only very rarely be the users language of  
>> choice.
>> a test case is here:
>> My machine is set to accept the three languages, french, spanish,  
>> german, but I will only get french, whatever my preference, unless  
>> I edit the accepted language list.
>> a longer description of the issue is here:
>> #3 & #17 in particular
>> regards
>> Jonathan Chetwynd
>> it seems to me they may be equally true of the SVG1.2 definitions:
>> <?xml version="1.0" encoding="utf-8" standalone="no"?>
>> <svg xmlns=""  xmlns:xlink="http:// 
>>" width="100%" height="100%">
>>     <g id='symbol1Text'>
>>                 <switch >
>>                     <text x="20" y="20" systemLanguage="fr" >ploc</ 
>> text>
>>                     <text x="20" y="20" systemLanguage="es" >la  
>> mancha</text>
>>                     <text x="20" y="20" systemLanguage="de"  
>> >splat</text>
>>                     <text x="20" y="20" >splat</text>
>>                 </switch>
>>     </g>
>>   </svg>

Received on Friday, 17 November 2006 07:59:46 UTC