Properly support the <switch> element and the "systemLanguage" attribute

Bug #1249423 reported by Patrick Storz
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Inkscape
Confirmed
Undecided
Unassigned

Bug Description

Inkscape should properly support the <switch> element and the "systemLanguage" attribute. Since <switch> already works - if I did not get it wrong - this is probably about implementing a selection based on "systemLanguage" attribute.

Currently all nodes containing the "systemLanguage" attribute are not shown at all. At least a evaluation based on the language set in Inkscape preferences should be done, though. Since were talking about an SVG editor an additional possibility to easily switch between languages would be even more appropriate.

Attached is a testcase which illustrates the <switch> element and the "systemLanguage" attribute.

Relevant section in the SVG 1.1 specification:
http://www.w3.org/TR/SVG11/struct.html#ConditionalProcessingSystemLanguageAttribute

Tags: svg win32
Revision history for this message
su_v (suv-lp) wrote :

> Attached is a testcase (…)

Missing.

Changed in inkscape:
status: New → Incomplete
tags: added: svg
description: updated
Revision history for this message
Patrick Storz (ede123) wrote :
su_v (suv-lp)
Changed in inkscape:
status: Incomplete → New
Revision history for this message
su_v (suv-lp) wrote :

> Currently all nodes containing the "systemLanguage" attribute are not shown at all.

Not reproduced with Inkscape 0.48.4 and current trunk (r12786) on OS X 10.7.5:
- Inkscape 0.48.4 renders it as expected (and as e.g. Firefox 25.0 and Chromium 33.0.1705.0 (234154))
- Inkscape trunk (r12786) additionally renders 'other' on top of the correct language-dependent switch element (which AFAICT is not correct).

System locale is 'en_US.UTF-8', additionally tested with 'de_DE.UTF-8':
$ LANG=de_DE.UTF-8 inkscape testcase.svg

Revision history for this message
Patrick Storz (ede123) wrote :

Thanks for your answer. It seems to be Windows-dependent Problem then: Inkscape doesn't properly detect the system locale.
I just tested setting system locale explicitly (by running Inkscape from console after using "set LANG=de_DE.UTF-8" to set the environment variable) which gives me the exact same behavior you describe (both in 0.48.4 and 0.49r12742).
When *not* explicitly setting the environment variable the behavior is as described in the bug description and only "other" is shown.

For the record: I'm running Windows 7 x64 Prof. with German localization.

Revision history for this message
jazzynico (jazzynico) wrote :

Reproduced on Windows XP, Inkscape trunk revision 12795.
Not reproduced with Crunchbang Waldorf (a Debian stable based distro.), same revision.

~suv> Inkscape trunk (r12786) additionally renders 'other' on top of the correct language-dependent switch element (which AFAICT is not correct).

Not reproduced here. Tested with English and French locales.

Changed in inkscape:
status: New → Confirmed
Revision history for this message
su_v (suv-lp) wrote :

On 2013-11-12 10:57 +0100, jazzynico wrote:
> ~suv> Inkscape trunk (r12786) additionally renders 'other' on top of
> the correct language-dependent switch element (which AFAICT is not
> correct).
>
> Not reproduced here. Tested with English and French locales.

See bug #1249862 - it was fixed in r12794.

Revision history for this message
jazzynico (jazzynico) wrote :

~suv> Inkscape trunk (r12786) additionally renders 'other' on top of the correct language-dependent switch element (which AFAICT is not correct).

Reproduced on Windows XP, by adding a language code tested with fr, de and en) in the document language (Document properties>Metadata).

su_v (suv-lp)
tags: added: win32
Revision history for this message
jazzynico (jazzynico) wrote :

Workaround to remove the "Other" text when incorrect, add an empty systemLanguage to the text3278 element:

<text id="text3278" systemLanguage="">other</text>

According to the SVG specs:
"The ‘switch’ element evaluates the ‘requiredFeatures’, ‘requiredExtensions’ and ‘systemLanguage’ attributes on its direct child elements in order, and then processes and renders the first child for which these attributes evaluate to true. All others will be bypassed and therefore not rendered."

But apparently, on OS-X and Windows, the last text element is evaluated separately when it doesn't contains the systemLanguage attribute.

Revision history for this message
su_v (suv-lp) wrote :

> But apparently, on OS-X and Windows, (…)

In my tests on OS X, this was due to a general regression in trunk (not OS-specific), which was fixed in r12794. The file renders correctly here with r12795 (no workarounds needed).

Revision history for this message
jazzynico (jazzynico) wrote :

> this was due to a general regression in trunk

Confirmed. I didn't test with the correct Windows version...

Revision history for this message
jazzynico (jazzynico) wrote :

It seems that retrieving the user's default language is particularly painful on Windows and we would have to rely on GetUserDefaultUILanguage (Gimp uses it here: https://git.gnome.org/browse/gimp/tree/app/language.c?h=gimp-2-8).
Unfortunately I can't find an easier way (a function returning the equivalent of a LANG variable) to fix the issue.

If it helps, I can add a partial fix that would allow the switch code to work when the language UI is set from the Inkscape preferences (thanks to the LANGUAGE variable), but it doesn't work if it is set to System default.

Revision history for this message
jazzynico (jazzynico) wrote :

Partial patch (works when the UI language is set in the Inskcape preferences).

Revision history for this message
su_v (suv-lp) wrote :

@JazzyNico - looks as if the patch was already committed in r12809 (probably not intentional?).

Revision history for this message
jazzynico (jazzynico) wrote :

@~suv - It wasn't intentional, I just didn't spot it in my 'bzr status' test. Fortunately I wasn't working on something bigger. On the other hand, it would have been easier to notice ;)
There's no risk it breaks something, thus I suggest we keep it in the trunk.

Revision history for this message
Patrick Storz (ede123) wrote :

Thanks for the patch JazzyNico, I concur with you. The patch is an improvement over the situation we had before and I don't think it breaks anything.

One question though: Inkscape seems to be able to detect the system language already to set the UI language accordingly. Why don't we use the same mechanism here so one does not have to explicitly set a language in preferences?

Revision history for this message
Amelia Bellamy-Royds (ameliabr) wrote :

Based on my testing in Inkscape 0.91 stable in Windows, <switch> and systemLanguage work correctly when the user has explicitly set a UI language, but still do not work if the language is set to "use system default". In that case, all the language tests fail even if the system language is something that should match.

For reference, the language switching code is in conditions.cpp, which uses SPDocument.getLanguage() (document.cpp) to find the user's preferred language.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.