Re: switch with systemLanguage is broken by standards


i didn't read in detail the differences (if any) in 1.1 and 1.2 
regarding the switch-element. but form my experience working in 
multi-language environments i only can state that switch/systemLanguage 
is totally useless. the main reasons are:
- that systemLanguage may be taken from the operating system OR the user 
agent, i know that this is defined somewhere but in an 
browser/plugin-environment like ASV3 provides, this logic is broken,
- in regions like Europe, Asia, etc. (hence the most important part of 
the word...) a very big part of the users don't have OSs or UAs in their 
preferred language (be it because it is not available, because the don't 
trust some rare language builds or because translation always comes 
months later than the english release). in this very common case, the 
selected language will always be the wrong one.

then the use case in bigger projects (be it with 3 interlinked SVG 
files): load the first, language selection fails or produces a wrong 
result, let the user chose one, link to another file and you can start 
the same silly game again. what's this worth for? it's easier to pass a 
language to the query-string (also if it gets only read clientside).


andre m. winter,
  cartography for internet and multimedia applications
  schiessstand 4/1, a6091 goetzens, tyrol, austria
  tel.: ++43.5234.32732
  email: <>

<>          SVG consulting and development
<>   geo-localized high quality photographs
<>     print and online touristic map solutions

> 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

Received on Friday, 17 November 2006 10:41:56 UTC