326375 - Camino only, SVG: systemlanguage is not implemented (switch?)

Status: VERIFIED WONTFIX

(Camino Graveyard :: General, defect)

Description

[jonathan chetwynd]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.1) Gecko/20060207 Camino/1.0rc1+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.1) Gecko/20060207 Camino/1.0rc1+

text should respond to the system language of the user

Reproducible: Always

Steps to Reproduce:
1.visit URI
2.read text
3.

Actual Results:  
in Italian,


Expected Results:  
In English (dependent on system language set)

https://bugzilla.mozilla.org/show_bug.cgi?id=249344

original mozilla bug

apologies it is not clear to me whether this issue relates to failure with switch or system language

Comment 1

[Mark Mentovai]

I see what's going on here.

http://lxr.mozilla.org/mozilla1.8.0/source/layout/base/nsCSSFrameConstructor.cpp#7237

The implementation of systemLanguage picks the first systemLanguage for which a matching entry is present in intl.accept_languages, regardless of the order of languages in intl.accept_languages.  In Camino, intl.accept_languages by default is set to the list of languages from the International system preference pane, and that, in turn, is by default set to contain several languages including en, fr, it, and es.

Firefox builds are localized to a specific language and by default only contain one language (or one language plus a regional variant) in intl.accept_languages.

Cc: tor, who introduced this in bug 216563.

Comment 2

[tor]

CCing scooter, who wrote the code in question that I checked in for bug 216563.

Comment 3

[Mark Mentovai]

Also Hixie, to maybe help shed some light on the specified behavior.

Hixie, as I read the standard, the list of supported languages is treated as unordered, and the first child of a <switch> that has a systemLanguage attribute matching any of the supported languages wins.  SVG 1.1 spec sections 5.8.2, 5.8.5.

If that is in fact the desired spec, then Mozilla's behavior is correct, but overloading intl.accept_languages to be used as the SVG supported-language list is kind of bogus.  intl.accept_languages IS treated as an ordered list and languages are given q-factors when they make it into the HTTP Accept-Language header field.  It seems to me that if intl.accept_languages is to be (ab)used for SVG's purposes, only the languages from intl.accept_languages that would get the highest q-factor should be present in the SVG supported-language list.

Comment 4

[Mark Mentovai]

Jonathan, can you provide a short reduced testcase and attach it to this bug?

Comment 5

[Hixie (not reading bugmail)]

What Camino is doing is correct as far as I can tell. SVG is retarded.

Comment 6

[Mark Mentovai]

We're following the spec but the spec sucks.  Is anyone opposed to the behavior I proposed in comment 3, to only use languages with the highest q-factor for the SVG supported-language list?

Comment 7

[jonathan chetwynd]

RE: #4

Mark

the original mozilla bug had this attachment:
https://bugzilla.mozilla.org/attachment.cgi?id=203770
which should be suitable

Comment 8

[jonathan chetwynd]

[e-mail]

Opera9beta appears to have the same bug, following the spec?

Comment 9

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Can we get an answer from SVG folks/Hixie/etc. on the proposal in comment 6?  

This sounds like it could *possibly* be an easy fix for 1.1

Comment 10

[jonathan chetwynd]

Attachment: reduced test for systemlanguage

minefield uses the OS systemLanguage camino doesn't

Comment 11

[jonathan chetwynd]

#4

sorry for the delay, attachment is very greatly reduced test case.
having difficulty interpreting the other comments.

cheers

Comment 12

[Hixie (not reading bugmail)]

We should follow the spec. That's what the spec is for.

If we start ignoring the specs, or picking and chosing what bits we like, then what's to stop the other browsers from doing the same? In the end we end up with all the browsers doing their own thing, and we might as well not bother with the spec at all.

Comment 13

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

We're following the spec, then.  SVG should stop sucking :P

Comment 14

[jonathan chetwynd]

apologies for re-opening bug.

Mozilla, Amaya, Webkit and ASV all follow the spec and implement systemLanguage in a similar way. The result being that the attachment is in English on my machine.

Please provide better evidence that Camino is following the spec. including a plain English description of how you are following the spec, but differently to the other main user agents

Opera is a special case because they distribute their software in localised versions.

Comment 15

[Samuel Sidler (old account; do not CC)]

Please see Hixie's comment 5. What we're doing is correct and as such we won't change behavior.

Comment 16

[jonathan chetwynd]

#5 appears to be an opinion, and contains no verifiable information.

All the other main UA exhibit a different and more useful behaviour.

I fail to see why a request for more explicit detail from hixie or another is unreasonable.

Comment 17

[Stuart Morgan]

Comment 3 has the actual explanation.  To be very clear about it, section 5.8.2 describes the behavior of the switch statement:
"The 'switch' element evaluates the [...] attributes on its direct child elements *in order*, and then processes and renders the first child for which these attributes evaluate to true."
(emphasis mine)

Camino pulls the list of languages a user accepts from the system preferences, since that is the system location for specifying languages users understand. According to the spec, the first language *as specified by the author* which the client accepts is the one that will win. This means that unlike accept-language, it's not possible for the client to express any language preference among possible languages, which is deeply stupid.

There are only two ways this can work without violating the spec:
1) We assume that the user understands the languages the system says they do
2) We assume the user only understands the first n languages the system says they do (where n=1 if you want to always give them their current language), and reject all other languages, which means that if I have set my system preferences to correctly show that I speak n+1 languages, then SVG content which is only available in my n+1st language will not show up at all.

Neither option is good, but option 1, which is what we do now, seems less bad to me since there is at least the possibility for the user to get semi-reasonable behavior (by making their system prefs reflect the reality of what languages they understand).

The fault here is ultimately:
- mostly on the SVG spec, for not doing something sensible with language
- perhaps partially on Apple, for shipping a really broad set of system languages listed by default, rather than listing only the primary system language and letting users explicitly add additional languages that they understand.

Comment 18

[jonathan chetwynd]

#17 thanks Stuart,

I'm sure you'll agree

"It's amazing how a simple brief explanation can elucidate such matters."

Could someone other than me can raise this with the SVGWG?

cheers

x:"

Comment 19

[jonathan chetwynd]

taken to SVGWG:

http://lists.w3.org/Archives/Public/www-svg/2006Nov/0025.html

Comment 20

[jonathan chetwynd]

apologies,

but I have memory problems, and as this is now working have changed to fixed!

have asked SVGWG doug to point me to the errata.

Comment 21

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

There were no code changes, so this bug can't have resolution FIXED.  Resetting to the previous resolution.

Comment 22

[jonathan chetwynd]

#21

Smokey, you may be right, however if you try the attachment or URI then read comment0, the description you'll see this bug has been fixed.

I can't tell you why or how this has happened, the fact is that it has.

if you take time to read the other comments it's quite clear that if this bug had not been 'fixed' the first valid systemlanguage should be used, and this isnt the case, the users preference is the one used.
in my case English.

I have every respect for your opinion but please dont change again without further supported argument.

Comment 23

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

If you can't point to a specific Mozilla or Camino code change, a bug cannot be closed as FIXED (per mozilla.org policy).

If it happens to appear to work now, then it can be closed WORKSFORME.

Please do not change the resolution again unless you can point to a specific code change.

Comment 24

[jonathan chetwynd]

fine,

but it didn't work in camino #19 2006/11/16
it did however in mozilla at that time...

I write test cases not code.
I also file bugs, and note when their operation changes

cheers

Comment 25

[Stuart Morgan]

And just to come full circle, returning to WONTFIX. I tested this in both a recent branch nightly and the latest trunk nightly, and both still display the testcase in French (the first language in the testcase that exists in my accept-language), regardless of what language I rank highest in my accept-language headers.

The most likely explanation is that you changed your system languages, or otherwise changed your accept-language headers. I can still reproduce it at will in every current version of Camino, so it's not WFM.

Comment 26

[jonathan chetwynd]

Stuart & Smokey,

my apologies seems I changed my system language preferences at some time and didn't check this thoroughly.
 
back to chasing SVGWG thanks for your patience.

Comment 27

[jonathan chetwynd]

going to sleep, or waking, I relaised where part of the confusion arose.

Opera (OS X) uses the first example provided, ie French in the attachment, ignoring user preferences.
Whilst 
Camino uses the first language in the author's list that is also in their user preferences, or the default.
Whereas
Mozilla and Safari use the first language in the user's preferences that is also in the author's list, or the default.

Comment 28

[Stuart Morgan]

(In reply to comment #27)
> Mozilla and Safari use the first language in the user's preferences that is
> also in the author's list, or the default.

No, they don't. As was already explained here, Firefox by default only sends one language in the accept-language header, and Safari does the same. That means you either get your current language, or the default, period.

I'm un-CC'ing myself from this bug, since I'm tired of the spam. The reason this behavior exists has been very clearly explained. If at some future point the SVG spec changes to allow User Agents to do something more intelligent with language, then a new bug should be filed to do so. There is nothing useful that can be accomplished by continuing to comment in this bug.

Comment 29

[jonathan chetwynd]

Attachment: test with italian

Comment 30

[Doug Schepers]

This does not originate in SVG, but rather in SMIL [1], like the animation features.  It is specified in detail in the SVG spec because SMIL requires a host language.

That said, I talked this over with the SVG WG, and we are willing to issue an errata for SVG 1.1 that addresses this issue; it would be a class-3 errata, because it clarifies the case for UAs which use Accept-Language preference weights.  The new text would be something 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."

This is pending acceptance of the SYMM WG, but I would like your immediate feedback as to whether this would resolve the issue.

[1] http://www.w3.org/TR/REC-smil/#test

Thanks-
-Doug

Comment 31

[Stuart Morgan]

Please move this discussion to one of the Mozilla community development groups/lists. None of the code in question is Camino-specific, and this is a resolved bug, so this really isn't a good place for it.

Comment 33

[jonathan chetwynd]

#30

Doug it's now 2 years later,

please can you comment this bug to indicate if the errata was adopted.

if it was, would it be appropriate to reopen this bug or should another be filed?

regards

Comment 34

[jonathan chetwynd]

in Opera:
Until recently the URI worked as described, 
there is currently a regression crash bug filed for recent snapshots.

in Safari Webkit
nightlies now follow system language preference


ie for each UA, if the user sets french as their preferred language, and the author provides a switch with systemlanguage=french that is the one that will be selected.

Comment 35

[Chris Lawson (gone)]

Jonathan, nothing has changed in the last two years to make comment 31 any less relevant. This is still not an appropriate place to be discussing these issues.

Comment 36

[Mark Mentovai]

[in response to a private e-mail]

Wow.  Three years, huh?  Where has the time gone?

I don't know for sure whether or not the SVG WG adopted the erratum proposed in comment 30, but it would seem that they have not.

If they have not, no further action with respect to Mozilla or Camino is necessary, warranted, or justified.

Once a relevant erratum has been adopted, the proper action with respect to Mozilla is to file a new bug in component "Core" and product "SVG" with severity "enhancement" suggesting that Mozilla implement the guidance offered by the errata.

Feel free to refer back to this bug in any future bug or list posting.  The investigation and analysis of the problem may prove useful.  However, as this bug was related to Camino and we determined that the Mozilla Core handles this for Camino and the Mozilla Core wasn't actually doing anything wrong by faithfully implementing what was specified by the SVG WG, please do not attempt to recycle or repurpose this bug.