Using svg and wikidata to allow multilingual images
Problem: Many images involve text. In order to preserve the information, formats like SVG allow for elements as such instead of a simple bitmap. This is used in many images in Wikimedia projects, for example maps, infographics, charts... However, each project uses a specific language that may have local forms for a toponyms, or name. That forces to different versions of the same file in commons, such as Commons:File:Central_Erope_1572_es.svg, Commons:File:Central_Erope_1572_HU.svg and Commons:File:Central europe 1572.png.
This works but is suboptimal since:
Reusability is reduced: For example provided, graph editing skills will be needed to use the image in more languages.
Maintenance work is increased: If I find a mistake in the image in es:wiki I can correct it. But I will need to do three different corrections to ensure all wikis are updated. This may be feasible for a small population (let's say local wiki and en:, as main targets) but is not scalable to a portfolio of projects like Wikimedia with hundreds of local projects.
Some alternative options exist like Kartographer but are not widely used.
Who would benefit: translators of content between wikis, people who do commons maintenance work, small wikis that are more reliant on commons and translation tools.
Proposed solution: I wonder if a more interactive SVG can be done where a text could be linked to a Wikidata element. For example in the above-mentioned map, instead of the text "Upper Hungary" I'd like to link to Wikidata Element Q999030. This already include the version for several idioms so a local wiki can retrieve localized names. There is already work in Wikidata for using a related language when no local version exist which provides a fallback.
It will reduce the amount of files in commons, facilitate a multilingual review and update of mistakes, facilitate reuse of images (with synergies with the content translator, since currently there is no integration for image translation), reduce barriers for small wikis.
@SWilson (WMF): I didn't know that tool, thanks. For me it shows the idea is possible. However, the most valuable part, the "emerging" capability related to Wikimedia is still missing. The tool is still focused on a traditional monolingual approach from language A to language B which does not scalate very well with many languages. The tool alone means if I'm from a small/infrarepresented language I will still need to translate, review and reupload thousands of existing files in commons, requiring a huge quantity of manhours just to take advantage of existing images in Commons like this or this. It also means duplicated human work to translate the image but also to provide the same translations in Wikidata for infoboxes (let alone the article, categories, etc). I'm afraid also means by the time many of them are translated, some may already be outdated (I'm thinking of election diagrams) or forked by other reasons. Finally, it also means a weak spot for vandalism, since the new files will require new patrolling and will not benefit of the review and update of existing files (the second example I now link has 26 different versions and potentially should have one per Wikipedia). I think there is potential to further develop the tool to streamline all of this if we could use Wikidata to enhance the translation and if we can have dynamically generated images instead of multiple translated versions of the same svg.--FAR (talk) 18:52, 8 December 2020 (UTC)[reply]
"it also means a weak spot for vandalism" I was wondering about this. I see the utility of your proposal -- it basically amounts to Mark Twain's aphorism [paraphrased] "put all of one's eggs in a single basket and watch that basket" -- but based off how often I see vandalised, incorrect, or nonsensical labels on Wikidata (or would you draw from 'title', 'name', 'official name', 'name in native language' and 'nickname' statements instead of the labels/descriptions?), it would be useful to be able to specify a particular oldid of the entity in question, otherwise many files might 'inherit' the vandalism and it would be hard to track from the filepage or client wikis since the error would be transient and the pertinent history at Wikidata. That could be ameliorated in the tooling of course, but only if such [mis]use cases are kept in mind. Arlo Barnes (talk) 16:24, 9 December 2020 (UTC)[reply]
Support Dr747 (talk) 18:44, 8 December 2020 (UTC)
Strong support--Krzysiek 123456789 (talk) 13:18, 14 December 2020 (UTC)
