Last modified: 2014-05-29 20:21:53 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 16052 - Support for multilingual SVGs
Support for multilingual SVGs
Status: NEW
Product: MediaWiki
Classification: Unclassified
File management (Other open bugs)
unspecified
All All
: Low enhancement with 3 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
http://commons.wikimedia.org/wiki/Ima...
:
: 14320 15721 (view as bug list)
Depends on: 58663 61649 32987
Blocks:
  Show dependency treegraph
 
Reported: 2008-10-20 17:13 UTC by Hk kng
Modified: 2014-05-29 20:21 UTC (History)
12 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Hk kng 2008-10-20 17:13:37 UTC
SVG images like the one given above can contain language-specific elements like labels via the <switch>-element. librsvg is able to handle them by simply reading the enviroment variable (See function rsvg_eval_switch_attributes in rsvg-cond.c)

This means it is possible to produce language-specific PNGs by invoking like this:
env LANG=<locale> rsvg -w<width> file.svg <width>px-<locale>-file.png
I tried this out at home, and it worked just fine.

Shoudn't it be possible to decide from the language of the page asking for the png which language version is needed and produce them accordingly? Or, to avoid the production of millions of identical images from single-language SVGs, what about a parameter for the Image: tag?

General comment:
For the moment, this is still a niche idea. It is yet not easy to produce SVGs that utilize these features. Inkscape even supresses the tags in its current version: https://bugs.launchpad.net/bugs/269390

But for the future, it would be feasable to introduce a toolserver gadget like http://toolserver.org/~nikola/svgtranslate.php 
Maybe I'll do it myself. It depends on whether I get a thumbs-up here.
Comment 1 Brion Vibber 2008-10-20 17:59:23 UTC
Compare also bug 15721, which seems to ask about a different language message...

Handling the language switch for images in a shared repository would not be as simple, we'd need to add infrastructure to store separate renderings for each language.

See also bug 4688 and bug 14320, which propose different methods for templatizing/filtering for language options.
Comment 2 Guillaume Paumier 2009-12-31 18:26:24 UTC
I'm going to make this the master bug for multilingual support of SVGs; it's better to discuss the implementation in one place.
--> marking bug 14320 as duplicate of this one
--> marking bug 15721 as duplicate of this one
--> leaving bug 4688 alone since it's a possible implementation, but it's also more general.

Btw the bug in Inkscape was fixed in 2008.
Comment 3 Guillaume Paumier 2009-12-31 18:26:42 UTC
*** Bug 15721 has been marked as a duplicate of this bug. ***
Comment 4 Guillaume Paumier 2009-12-31 18:26:52 UTC
*** Bug 14320 has been marked as a duplicate of this bug. ***
Comment 5 Bryan Tong Minh 2011-03-12 20:37:46 UTC
(In reply to comment #1)
> Handling the language switch for images in a shared repository would not be as
> simple, we'd need to add infrastructure to store separate renderings for each
> language.
>
It would be as simple as implementing this switch in parseParamString/makeParamString or am I missing something obvious?
Comment 6 Bawolff (Brian Wolff) 2013-10-21 16:35:15 UTC
So with Jarry's patch, we now support [[File:some svg|lang=de]] - Does that make this bug fixed? If not, what is the scope of this bug?
Comment 7 Andre Klapper 2013-10-21 19:50:56 UTC
*** Bug 55768 has been marked as a duplicate of this bug. ***
Comment 8 Papou 2013-10-21 22:15:59 UTC
It is very sorry to dupe my bug 55768 without even mentioning that it is at least as general as bug 4688 that has been left alone. Bug 55768 should not have been duplicated to bub 16052, but a merge with bug 4688 should have been proposed (supposing that the authors' opinion matters).

Layers are the obvious path to go for this kind or features. As both these two bugs say, the possibilities are endless beyond languages. I even show with a one instruction hack that the answer to "Can this be accomplished with a simple XML transformation?" is formally YES.

Normally, it's a convention of what the name (label) of a layer must "look like" to force its visibility.
To be independent of which editor can produce which tags, the best approach is general, to match any tag with a regex: something like   Image:any.svg|tag=<tag_name_>,<regex>,visible|tag=<tag_name_>,<regex>,visible ...
For example, <regex>="=ru" means that the tag must contain "=ru" anywhere in the value, "=ru$" at the end ...
As a regex is powerful but intimidating, lang=xx could be used as a shortcut for the language convention, translating to the necessary regex.

What is Jarry's patch doing?
Comment 9 Bawolff (Brian Wolff) 2013-10-22 00:28:56 UTC
(In reply to comment #8)
> It is very sorry to dupe my bug 55768 without even mentioning that it is at
> least as general as bug 4688 that has been left alone. Bug 55768 should not
> have been duplicated to bub 16052, but a merge with bug 4688 should have been
> proposed (supposing that the authors' opinion matters).
> 
> Layers are the obvious path to go for this kind or features. As both these
> two
> bugs say, the possibilities are endless beyond languages. I even show with a
> one instruction hack that the answer to "Can this be accomplished with a
> simple
> XML transformation?" is formally YES.
> 
> Normally, it's a convention of what the name (label) of a layer must "look
> like" to force its visibility.
> To be independent of which editor can produce which tags, the best approach
> is
> general, to match any tag with a regex: something like  
> Image:any.svg|tag=<tag_name_>,<regex>,visible|tag=<tag_name_>,<regex>,visible
> ...
> For example, <regex>="=ru" means that the tag must contain "=ru" anywhere in
> the value, "=ru$" at the end ...
> As a regex is powerful but intimidating, lang=xx could be used as a shortcut
> for the language convention, translating to the necessary regex.
> 
> What is Jarry's patch doing?

Jarry's patch is allowing people to use the <switch> statement combined with systemLanguage, to have per language customization of svgs. See http://www.w3.org/TR/SVG/struct.html#SwitchElement (Actually it just passes a language option to rsvg which renders svgs for us)

To be honest, I think your bug makes more sense to dupe to bug 4688 then it does to dupe to this bug. I'll switch it to duping to that bug.

(That said, I think it would be very unlikely to allow users to manipulate svgs using regexes on tag names. That's way more complex then we like user exposed interfaces to be, not to mention hard to guarantee that it would be performant in all situations)
Comment 10 Papou 2013-10-22 19:03:46 UTC

I have commented the switch vs issue in bug 4688.


(In reply to comment #9)
> (That said, I think it would be very unlikely to allow users to manipulate
> svgs
> using regexes on tag names. That's way more complex then we like user exposed
> interfaces to be, not to mention hard to guarantee that it would be
> performant
> in all situations)

This is what I was saying:

> (In reply to comment #8)
> > As a regex is powerful but intimidating, lang=xx could be used as a shortcut
> > for the language convention, translating to the necessary regex.

regex could be used only internally, maybe access still allowed to geeks.

But I'm not sure that sophisticated regex mapping is necessary.
Comment 11 Papou 2014-02-21 01:16:49 UTC
I have written svg-sieve a script that does what bug 4688 suggests, select which layers to display, and by extension, bug 16052, select messages in a particular language. See bug 4688.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links