Every two weeks a development sprint is finished. Every two weeks we evaluate what we achieved, what went well and what went wrong. Many of the stories of sprint 10 can be found in Mingle (user:guest, password:guest). There you see the stories that were accepted or postponed.

The stories that ended happily are all over the place.

• The Ahirani language, a language of India that uses the Devanagari script in the same way as Marathi, is now supported for web fonts and input methods.
• When a translation administrator encourages or discourages the translation of a text, this will now be logged. This helps translators prioritize their activities.
• WebFonts now uses the MicroType Express font compression technology. This makes sending fonts to your browser go much faster.
• A translator can inform how he wants to be contacted and how often he can be contacted. In true agile fashion, the software that will make use of this will be written in a future sprint
• Some texts only need to be translated in selected languages because they will reach a specific public or because it will be used in software that supports a limited number of languages. New functionality enables a translation administrator to select these languages.
• We did a lot of code review; it gets done as it is part of our plan

A few stories did not end on a high note:

• Configuring one translation memory for all the wikis where the WMF needs translation took much longer. The idea was to build it first on Labs. This idea has now been shelved and it will be configured directly in production.
• A lot of work has gone in EasyTimeline. This was to make its functionality usable in other scripts and languages that are written from right to left. It works after a fashion and many issues have been resolved. Sadly the devil is in the details. Ploticus is a dependency for EasyTimeline and it has a bugs in creating  SVG output. There is no plan to fix this bug in Ploticus ourselves, but we are trying to find developers who can. Until then, we cannot have progress on this feature. Please let us know if you are interesting this issue for us.

Thanks,
Gerard Meijssen
Internationalization / Localization outreach consultant

after the slush, the flush

When new code does not find its way into production for quite some time, it tends to pile up. It is like with snow and when the time comes when it starts to thaw, it starts with a trickle, the trickles become a stream and all the streams rush down the mountain.

For the WMF Localisation team we worked on our documentation, our help system and our tests. We went to conferences in Belgium and India. And we worked on many small iterative improvements. We rolled out webfonts to more wikis. Input methods were improved and deployed as per requests. We have had our translation memory working on translatewiki.net for ages and now it is configured for use on the WMF wikis who use the Translate extension. Actually, we did experiment first with a new algorithm and we did configure one of the labs systems as a host for the memory of all the fine work we did and do.

Over time a lot of work went into things like plural rules. As the number of languages increase and as we support not only PHP but now also JavaScript, we are optimising our code and we are checking it again. We frequently find that a re-factoring is in order. It makes the code more elegant and easier to maintain. With added documentation and tests we ensure that we know it will work well.

Another fine project waiting to get to the stage where it will flow into our codebase is an updated Easy Timeline. The functionality has always been broken when used in many of  the “other” languages, languages written in a different direction, a different script.  The updated Easy Timeline has been given a revamp; it uses SVG to create the image and you can test it at translatewiki sandbox. Amir welcomes bug reports and LOVES to hear your comments

As you know, we use mingle for our project management (user guest, password guest). In it we have stories that explain the functionality that we are going to develop. Story 532 is one such:

As a potential translator, I want to be able to tell translation administrators in a structured way that I am interested in translating to one or more languages and at the same time provide them with some data about me and preferences on how and how often I would like to be contacted, so that translation administrators can more effectively and efficiently target translators.

Together with the acceptance criteria a narrative like this enables the developer to develop and the finished product to be accepted by our product manager. A story comes with tasks and once you have read the stories and the tasks you have a clue of what goes into getting you new functionality.

The conferences were great, we learn a lot from meeting so many wonderful people. Many tests are deployed and they run regularly. The documentation, including user documentation is written and we love you to translate many of them in your language. We feel really pumped up to get cracking and provide you with more functionality in the next sprint.

Thanks,
Gerard Meijssen
Internationalization / Localization outreach consultant

When there is a code freeze or a slush, the potential for what is to be delivered is curtailed. It is official; you will not deliver new code, you will work towards consolidation of the new MediaWiki release.

One of the objectives for this and the next release is that the time between releases will decrease. Even though the Localization team works in two week sprints, it can help with getting the release out of the door. The first thing to do is help even more with code review, the other thing is make sure that its code will be optimised for easy coding, testing and use.

When you check out mingle, (user guest, password guest), you will find that the developers of our team are learning about the various testing tools. They are even updating the developer documentation to make it easier to understand how to set up new automated tests.

When you are testing, it is necessary that code provides information about its execution. This realization means that the code needs to be refactored in order to allow for testing. Documentation is another part of the puzzle that helps stabilise code; you will find a prodigious amount of documentation that is scheduled for this sprint.

All this translates in quite a minimal deployment for the first week. Its highlights are:

Translate:

• Better error checking and handling in Special:Translate
• Translatable page id prefix changed from page| to page-
• Don’t reuse messages from core

WebFonts:

• Fixed download of Vemana Telugu font
• Added font for Ahirani (ahr)

Narayam: Some fixes to Assamese transliteration rules

Core: the cropping of text in level 1 headers is fixed for Indic languages

Thanks,
Gerard Meijssen
Internationalization / Localization outreach consultant

With a new sprint, new functionality for MediaWiki is identified to be deployed in two weeks time. There is room for dealing with issues to do with Narayam and WebFonts. Many of the new activities have to do with documentation, translation and feedback.

The sprint backlog in Mingle (user: guest password: guest)

What we hope for is that the feedback functionality that is now part of MediaWiki can be used to ask for feedback of MediaWiki features. It is obvious that the Wikimedia Localisation team cannot support all the 300+ languages that have their projects or exist in the incubator. What we can do is process the information we get from our language support teams. Figuring out how to do this is one of the goals for this sprint.

The use of Narayam and WebFonts will be helped a lot with documentation; “where to find that character on this keyboard mapping” or “what does an international keyboard look like” are questions looking for an answer. Determining how to document and what to translate is not all that obvious. With keyboard maps and fonts distributed as part of MediaWiki documenting on “the” wiki does not scale to other Wikimedia wikis and, MediaWiki wikis outside the Wikimedia Foundation are as much in need of documentation. When people start using MediaWiki because of such language support features we accomplish real support for a language.

For this sprint, these questions are looking for an answer and in the mean time the Translate extension will gain these new features:

• Documents that need translation can be grouped together; for instance all the Fundraiser messages or Wikimedia reports
• Documents can be marked as no longer needing translation
• Changes to the state of documents and translations will be logged and the log will be available for viewing
• Depending on the state of a document or a translation, attention can be drawn when there is a need for activity

User documentation needs translation and hopefully many of the algorithms used for the localisation of MediaWiki at translatewiki.net will equally apply for user documentation. Life will become a lot easier for all those people who administer MediaWiki and have only a basic understanding of English. We hope to deliver this in one of our future sprints.

Thanks,
Gerard Meijssen
Internationalization / Localization outreach consultant