Topic on Talk:Content translation

Tracked in Phabricator
Task T178995

Will it be possible to provide the Content translation feature in Wikiversity as well. It would be great to test that. Especially translating capacity building material provided as Open Educational Resource by one United Nations member state in Wikiversity can be translated much easier in other languages (e.g. from English into Spanish), so that other communities can benefit from the support. Wikiversity as an educational resource would benefit from that feature even if is still beta. Thank you for considering this option in the MediaWiki community of developers --Bert Niehaus (discuss • contribs) 13:15, 19 October 2017 (UTC)

I think the team certainly appreciates your request. This said, a similar one made one year ago got this reply, and I dunno that nothing has changed since.

No worries, thank you for your reply. I think it might be possible to create that as WebApp by using an HTML5 approach, that creates no burden for the MediaWiki programmers on the maintainance, e.g. by the following workflow:

• Create a GitHub repository e.g. for Project named 'Translator4MediaWiki'
• the docs/ folder of the HTML5 resource can be published on a Webserver (see e.g.
  • Wikipedia2Wikiversity on Github-Webserver and
  • [Wikipedia2Wikiversity Repository with published docs/ folder as web resources for previous URL]
• this will create an independent MediaWiki tool that will not stress neither the Wikiversity nor Wikivoyage infrastructure

The workflow for users including the technical approach behind will be pretty simple:

1. Copy the Wiki Source into a HTML5 textarea (maybe later use the MediaWiki-API to access the current sources of the MediaWiki article)
2. User selects input language and output language by HTML-select - then presses a button for translate.
3. Javascript takes the input from the textarea_input.value and splits the long text into fragments, containing header, plain text, math, references,.... (by using regular expression)
4. Depending on the type of fragement the fragments are submitted to a translate engine API by an Ajax-Call (e.g. references remain untranslated)
5. Join the translate and untranslated fragments by an Array.join() and store the string in the output textarea
6. The user might want to work on a translation a bit longer and therefore the content of the input and output textarea can be stored in the browser's LocalStorage. When a user revisits the 'Translator4MediaWiki' website on GitHub then the individual page content in the textarea are restored from the LocalStorage of the user's webbrowser on any revisits of the webpage 'Translator4MediaWiki' on Github. Every user works on his individual translation content without creating any traffic on a servers on Wikiversity or Wikivoyage maintained by programmers of MediaWiki and the Wiki foundation.

Forking and sharing this concept could also help to solve the problem with WikiBook creator, Instead of rendering the PDF on the server a first could step could be to collect a JSON file to the user in the API, and the client in the browsers generates a LaTeX, HTML, ... content of the Book. This will reduce the burdon for the servers of the WikiFoundation tremendously because the conversion WikiSource-Latex-PDF is extremely costly in terms of server load. HTML5 project idea with MediaWiki API calls could help also for that WikiBook Creator.

I don't know if that makes sense to you, but is also just an idea to let the community development much easier to participate in MediaWiki tools. I think obstacles starting to share small HTML5 tools that help the community to develop and add new content might be an option to think about.

Tools of this type could be ImageMap created for MediaWiki (see Wikiversity ImageMap and ImageMap Creator

Putting a link to your comment in Phabricator for devs to see it is all I could do. Thank you! (If you are interested in contributing directly to MediaWiki or know someone who could, please see New Developers/How to become a MediaWiki hacker.)