Community Tech/SVG translation

This page documents a project currently under development by the Wikimedia Foundation's Community Tech team.
We invite you to join the discussion on the talk page. You may track this project's progress on T201207.

This section aims to list all of the problems that exist with SVG translations on Commons. Not all of these will fall under the scope of this project but we will do our best to resolve as many problems as we can.

3. Creating separate file versions for every translation is problematic[edit]

It is a common practice to create new versions of files when creating translations instead of using the switch statement syntax to add translations to the same file. This leads to the translated files not being updated when the original file is.

If new file versions aren't linked to one another, it becomes hard to discover files and users might end up re-translating them.

4. Files containing multiple translations may not be supported by graphical editors[edit]

It appears that not all graphic editors support switch statements and their systemLanguage attributes to include multiple translations in the same file. This can lead to the translations being thrown away or corrupted when the files are edited in such editors.

There are cases when an SVG has phrases which should not be translated/translatable. An example would be an SVG where an English phrase is being translated into another language as a way of teaching. In that case, the English phrase should not be translatable. Similarly math/chemistry equations and diagrams may contain labels that should not be translatable.

As an example, in Map Tenerife Disaster EN, the names of airlines and runway numbers should not be translated (as is already followed by translators).

This section aims to list all the user workflows around translating SVGs on Commons. If you know of a workflow that's not documented here, tell us about it on the talk page!

A user who is only interested in translating a specific image because they are writing an article in a specific language and would like to translate a relevant language.

This user should be able to click on a link on the file page/input the image URL/have the tool auto-complete the image name when they start typing and be able to start translating.

A user who is a casual translator to a specific language (say Malayalam) and is looking for SVG files not translated to Malayalam, which are either generally available anywhere in the Wikimedia ecosystem, or specifically used on Malayalam wikis.

This user would want to see an interface which allows them to discover images to translate.

A user who finds a translated image but wants to edit the translation

This user would like to go in to the tool and be able to edit previously saved translations for an image.

A user who's interested in maintenance work and seeks to combine separate language version files into single files using switch syntax

This user would like for the tool to be able to provide some automation around finding these files and combining them.

The tool is nearing completion. The beta version of the tool links to commons-beta. You can freely add and upload images there without risking breaking anything. The production version of the tool is under testing right now and you will be able to use it once we are sure it is devoid of major bugs. Please leave feedback on the talk page!

It is now possible to render SVGs in wiki language instead of always rendering them in English. Now you no longer need to specify the lang parameter to render the SVG in the wiki language. If the file is available in the wiki language, it automatically gets displayed in that language. Otherwise it defaults to English. This is especially useful in cases when files are added to pages first and translated later. Once the translation becomes available, the image automatically renders in the wiki language. This holds for switch-translated SVG files, of course.
As an example, you can look this file -

The team discussed the potential ways forward on this project and unanimously voted in favor of building a new ToolForge tool for this project (while pulling relevant code as needed from the svgtranslate codebase). Here are some of the reasons that influenced our decision:

Building an external tool would allow us to move a lot faster and deliver more impact on the project without getting bogged down by a lot of tech-debt work in fixing up outdated code.

Having a standalone codebase would allow volunteer developers to get involved and take over the project once it's complete.

It gives us more flexibility in terms of both the interface and functionality the tool can have.

Translating SVGs isn't a functionality that is specific to our projects. It can be used by anyone for any SVG.

As a tool, we'd be able to design it such that it works well in a mobile interface and allows for our users to make micro-contributions.

The Community Tech team is deciding upon a direction for this project in task T201207 to see what's the best way to deliver the most features to the users while being cognizant of the time constraints this team operates under. If you have opinions on that, let us know either on the talk page or on the phabricator ticket. Thank you.

We are still awaiting a technical investigation for this project. The ticket is in our current sprint and we hope to complete it by the end of March. After the investigation we will be able to decide on project requirements.

The existing tool (https://tools.wmflabs.org/svgtranslate/) currently does not allow for download/upload (and is therefore useless.) There is also an extension. It appears that the biggest problem with the tool is that it depends on the translate extension with custom patches, that are five years old. Just fixing the Tool Labs tool is probably the easiest way forward. Should be easy to work with.