 Hello everybody to the last day of the conference. My name is Ilmarilauha Kangas and I work for the Document Foundation as a mentor and a software janitor. In this talk I look at various technical things about the Document Foundation wiki that I have dealt with in the past couple of years, especially concerning language translation. Our wiki can be found in the web address wiki.documentfoundation.org. At TDF we use the media wiki software which also powers Wikipedia. We offer it as a content management system that is open for anyone to use. If that doesn't sound crazy enough, consider that it's a content management system with a single input field. This single input field certainly simplifies things from the point of view of the database structure, but on the other hand it creates many complications in practical use. In modern content management systems there are many possibilities to provide an experience that doesn't get in the way of the editors. But as there are no content types in media wiki, all kinds of complex things appear alongside the content itself. We can use templating and various forms of markup. One problem arising from this is that the system often cannot help us very much when we make mistakes. It can also be awkward to produce custom layouts or navigation as all the elements are confined to the content box. The work on moving our translations into the system provided by translate extension has been going on for four years. The end is finally in sight as there are only a few dozen relevant articles to take care of. It has been kind of a bittersweet experience. On one hand the management of translations is now coherent. And there is a user interface to support translators. On the other hand the famous single input field got quite a bit messier for everyone due to how the mechanism of the translation system is exposed in the wiki text source. The developers at wiki media are aware of the suboptimal nature of this and would like to come up with a solution that removes the need for editors to deal with all the translation markup. Lucky for us their budget is orders of magnitude above ours. So they are able to take on ambitious research projects like these. When setting up content for translation we generally want to minimize the amount of unnecessary stuff that translators need to handle. This typically happens by carefully including only relevant content inside translate elements. This is also the source of much tedious work. Here you can see how a code block as a whole is not included for translation while code comments are explicitly picked for translation. After painstakingly adding 100 translate elements into a long article and clicking show preview only to find out you made a mistake somewhere can feel like a punch to the gut. Fortunately clicking save changes will actually provide help in locating your mistake. The image shows an error screen that omits some content and allows us to notice that the problem is with the last paragraph shown there. When using templates automatic references to translated versions are achieved by using a magic word suffix. This has the downside that when the template has not yet been translated visitors will see an ugly red link. Fortunately after the next media wiki upgrade we can use the special my language prefix instead and this will show the English version in case of a missing translation. And here is an example of a red template of red template links in a Danish translation of a calc function article. When preparing the calc function articles for translation the amount of repetitive work started to really get on my nerves. The articles often have tables which ideally need their cell content broken up into separate translation entries. So translators don't need to look at distracting pieces of wiki markup. I went ahead and created a Python script to do this automatically. It works against the local text file and also handles numbers so they are not added for translation. And there are lots of numbers you can imagine in those articles. It makes use of the very helpful wiki text parser library. And here is a snippet of the script which is available in the wiki guide for translators. Still the repetitive work can't be escaped. Often I copy wiki articles into a text editor for comfortable editing. Many editors have functionality that allows to speed up the insertion of markup. And here is a snippet in Kate editor to wrap a piece of text inside translate tags. Another way to reduce the burden for translators is to create templates for reoccurring bits of text. Here we see the wiki text source for some templates used in calc function articles. An awkward thing about this is that we need to sprinkle these no include elements all over the place. And this is of course confusing when seen in the translation interface. I'll keep my fingers crossed that there will be a nice solution to this in the future. While writing this presentation I subscribed to a wiki media task called Structured Localization Framework for Templates. Which sounds promising. The visual editor is a feature that we've been itching to try for many years. It's first version required a node.js component but later it was implemented in pure PHP. Making the deployment much simpler. However our use of translate extension blocked us from trying it out. As the manipulation of translatable elements in the visual editor was cumbersome. With the next upgrade we will have another reason to celebrate. As the wiki media code ninjas have brought as a gift. Translation elements are directly editable in the visual editor. In this screenshot we can see that the element tags and markers are indicated in gray. They will later experiment with other ways of representing the elements in the UI. Media wiki supports automated manipulation of pages by using an API. But for simple replace operations it's nice to have a UI. Last year we installed the replace text extension which I have put into good use. It can only be used by administrators. And it has limited support for regular expressions. Funnily I use it also to find stuff. Because the results are better than what you get with the normal search. We should probably look into installing a proper search backend. When working on the developer guide this year we noticed horrible slowness in page load time. It turned out that the code block highlighting library pigments was doing crazy things on the server. Fortunately the maintainers of international scratch wiki for the popular scratch visual programming language had developed an alternative code highlighting extension which uses prism.js. It worked great for us and we sent them improvements for right to left language support. The screenshot shows an example of highlighted Java code. Extensions enrich media wiki. Sometimes they are merely wrappers for JavaScript libraries though. A couple of years ago we discovered that we could get rid of many extensions by creating widgets. This frees up valuable testing time from our infra team whenever there is an update to media wiki. The widget feature is itself provided by an extension. Only administrators can create or edit widgets due to security reasons but anyone can add them into pages. We have widgets for listing issues in Vaxilla and Redmine, embedding next cloud calendars, listing calc functions in a searchable grid which you can see on the screen, embedding video files and YouTube videos. Also during the conference I had some discussions and I realized that we need to implement something to automatically provide the translated calc function names to reduce the burden even more from translators. So that's a nice widget idea there. As mentioned before there are some things in wiki management that always require boring manual work. One way to make things less tedious is using the grease monkey browser extension. It allows executing JavaScript that manipulates web pages. I use it by writing scripts and associating them with a keyboard shortcut. An example of a boring task is marking pages for translation. It cannot be done automatically for dozens of pages because they might contain errors. With a grease monkey script I can press a key to open dozens of pages that have pending changes. And then for each page I press a different key that clicks the correct button saving me from mind-numbingly repetitive scrolling and mouse clicking. And here I can show it in action in a video. Here's me pressing a key and then everything explodes. Now I have dozens of tabs. Now I start pressing another key. You can see I don't have to scroll down and use my mouse. That's always a bonus. So after many years of tinkering I finally feel I have a good understanding on how to keep the wiki operating smoothly. So if you need help in figuring something out in TDF's wiki let me know. I want to thank Niklas Lakström and everyone who has helped me on the Media wiki IRC channel. I look forward to making use of the future innovations the wiki media folks come up with. Yeah that's it and thanks. So any questions? Does Eial have a question? So what are the fractions of the entire wiki that we have that are translated to and to how many on average. If that's some numbers that you have off the top of your head. So do you mean like statistically how many. How many languages is a page currently translated on average. On average. Off the top of my head might be something like five. But of course it's changing all the time. We are getting like 500 calc function articles. So Steve Fanning is doing this insane work of cleaning them up. They are like legacy from some other like guide appendix or whatever. And we are gradually moving them to translation. So that's kind of skewing the average because then you suddenly have hundreds of new pages. So for the calc function articles for example I think the average might be more likely like four or three at the moment. But then we have for example the main page which probably has like 20 translations. And of course with the migration to the new system it's easy to see what got outdated. When you see that the main page might have actually like 50 different languages or whatever. They are like legacy from the old times. And they might have maybe like one paragraph in the language that doesn't make any sense to migrate. But I did quite a lot of work saving time from the translators copying stuff over. Especially the main page and any index page like that is very tedious because it's broken down into bullet points and whatever. That makes me wonder whether when deciding on updating pages or deciding on page structure whether it's a good idea to try to keep like some central pages more static and prefer adding content in sub pages so that the translations don't become outdated more slowly. It's not so much an idea for you more like an idea for people who write contents on the wiki more generally to maybe prefer sub pages because of that consideration. Yeah might be. Is there a step by step guide for authors of wiki pages what they need to do to make their content translatable? Yes we have this multilingual wiki article which was there already many years ago and it was updated when we started using the translate extension. I guess it's found pretty easily on the main index page from some language related section. And it also contains for example this Python script that I use for tables it can be copied from there. And it also advises how to deal with unique content so which kind of path to use for those to make a clear separation of unique local pages. Okay I guess that's it. Thanks.