#Facebook appears to be broken

I have a sweet spot for the #Myanmar #Wikipedia and when I got the message from Zaw Thet Aung that all Wikipedians are taking a long wiki break, I was saddened but not surprised. Saddened because there is such a need for high quality, neutral point of view encyclopaedic information in Myanmar. Not surprised because it is so hard to write articles in the Myanmar language.

What I hope for is for someone to help us with fonts for the WebFonts functionality, combine this with the existing keyboard mappings we support in Narayam and my belief is that the Myanmar community will be enthused when they check this out at translatewiki.net. So much so, that they will enter a bug in bugzilla to enable both extensions asap for all their projects.

When I "View Post on Facebook", the result is underwhelming. It is broken.

It is not that strange that I only now notice Facebook is broken for me. All my posts refer to my blog posts and I have this automated. There is hardly ever a reason for me to Facebook.
Thanks,
       GerardM

Looking forward to write #agile user stories

A good joke has a kernel of truth. Agile allows for less documentation, maybe even no documentation and a developer does not need to plan beyond the duration of a sprint. When you start with agile it first goes all haywire and yes the writing of code is what delivers functionality.

I will not be writing code, I will be writing about the functionality that is being developed or has been delivered. Such stories will be in English, short and sweet. They may contain screen shots or pictures that amuse and they are intended to have more people find their way in the most multi-lingual software of all; MediaWiki.

Functionality developed with agile will not appear fully formed like Pallas Athena out of the head of Zeus. It will grow more organically. As experience shows users will surely find ways to use the delivered functionality in ways that were not considered.

As we learn what works and why or what does not work and why, we will collect your stories. These stories are in turn converted in agile user stories and may be decomposed in multiple related stories. Such stories end up in the product backlog and will be prioritised and maybe developed.

There is for instance a user story in this example of Wiktionary template hell:

* Japanese: {{t|ja|スクラム|tr=sukuramu|sc=Jpan}}

The  story may be about editing Japanese, it can be about how the Japanese text was entered or how it has to be shown to a reader. We do want to learn from you what this is all about. For this we need you and becoming part of a language support team is a short cut to getting our attention.
Thanks,
        GerardM

What #script for #Konkani

When a language is written in multiple scripts, five scripts to be exactly, writing about each subject five times is not really an option. Even English with only one script is not done writing down the sum of all knowledge.

When it is theoretically possible to transliterate from and to multiple scripts, things start to look up. The trick for Konkani will be how to support all scripts including the Arabic script.

It is normal to drop the vowels when using the Arabic script. This makes transliterating to the Arabic script possible but it is impossible to transliterate to any of the other scripts.

The question is, would it be ok to force Konkani people to include the vowels and is  this enough to make transliteration from the Arabic script possible?
Thanks,
       GerardM

Official languages of #India; we support you

#Wikipedia supports over 270 languages from all over the world. This is much less than the 452 languages listed for India.

India is strategic for the Wikimedia Foundation and consequently its localisation team has been tasked to provide the necessary language support. To make it manageable, we will be concentrating our effort on the official languages of India.

This will be challenging; we want to make sure that everybody can actually enter the characters for the scripts involved and see the results. Some languages are written in multiple scripts, will it be possible to see these results in these scripts?

For all these challenges, the team will do the heavy lifting and create enabling functionality. It will be really hard to find the input methods, the fonts, the conversion tools for each language as well. For this reason we need people to join us in our language support teams. We need people who know if zero is a plural or a singular in their language, we need people who can find us the appropriate and freely licensed fonts, we need people who can help us test our software for their language.

We need you.

By the way, if your language is not one of the official languages of India, the heavy lifting for India does provide you with the tools to do the same things for your language. Helping you to help yourself is something that will always be important to us.
Thanks,
      GerardM

The use of outside #standards

The notion that we are going to filter images maybe articles from our users makes me feel uncomfortable. The amount of bad faith in the discussion makes me feel nauseous; I have stopped following the multiple threads on the subject. The arguments why a single set of arguments should not be used are in my opinion compelling. The arguments why we do not want to set the values that enable the loss of immediate visibility are equally compelling.

Consequently I would like to steal a page out of the language policy; have an external body with sufficient authority set for us us up with the necessary values THEY need to do their job. We in turn can piggy back and enable the values set and allow our readers to select one of the levels provided they feel comfortable with.

So here is the deal; The IEEE LOM is a standard used by many educational organisations to mark electronic information that can be used on demand by students. The information is tagged in many ways including an age level that corresponds with what a teacher consider to be appropriate for a student.

There are multiple benefits to this scheme. It makes our content discoverable in an automated way from within education. Our content is rated for its usability and this provides us with feedback on our content. I am sure that many of our articles will be rated as "too long did not read" or using a vocabulary that is too demanding and consequently get a high age rating as a consequence.

Given that a lot of money is spend on providing quality educational information by many educational entities, they will be more then happy to do the rating. When you combine this with the use of FlaggedRevisions to store the information it seems a good fit for many reasons.

And yes, we can ask for contributions for hosting the data and providing content on a just in time basis.
Thanks,
        GerardM

#Agile training at the #Wikimedia Foundation

The #Localisation team consists of people who are used to each other. We worked together for a long time and now it is a job. With a job come dreary things, things like time management in order to be paid but it makes available time to spend on the real issues that are so dear to our heart.

With more time and with being part of the team of MediaWiki developers all kinds of things change and need to be addressed. As an amateur (ie non paid professional) you choose what you want to be involved in. Siebrand did the project management as well as being the working "first among equals" and in reality he has been herding cats.

The carrot and stick approach worked well; if you code this it will go live soon or if you localise these messages first, your Wikipedia will be more usable. Making sure that the environment was optimal for getting the jobs done has always been part of project management.

Now that we are a team intending to work with best industry practices, it is wonderful that the Wikimedia Foundation knows about best practices and intends to implement them in the various disciplines in the organisation. For software there is agile and we have the good fortune to have two days of training by Hai from ThoughtWorks.

The good news is that as a result of implementing an agile management style, we will have frequent updates of language related software. We will have a lot of communications particularly with the language support teams we are setting up about functionality and requirements (both ways) and we expect that as a result many great languages will get all the readers and editors they deserve.
Thanks,
      GerardM

#Wikimedia #mobile #statistics

The MobileFrontend has replaced the old Ruby software and it is doing well. The amount of traffic it is handling continues to grow and the software is coping well. The development was concentrating on replacing the existing functionality and as it is freed of these shackles, new opportunities arise.

The MobileFrontend has been available for testing for a considerable time at the bottom of all Wiki pages and what did not happen was include this in the mobile statistics. This is sad not only because we did not only learn how much it was used during the test period, it did not start recording the data when it became used for real.

When the data is obviously, utterly wrong, it is a good practice to approximate what the data would have been. While such data is not absolutely right, it does provide workable data. It does provide the information management can rely on.

As it is there may be other data that is still not measured. There are mobile apps that use the API to request data. Do not forget that MobileFrontend does now support Wiktionary, Wikibooks, Wikisource and all the other projects as well...
Thanks,
      GerardM

A #microwave has its purpose

Thanks but no thanks,
       GerardM

Happy Rosh Hashanah and happy Dussehra

Today at dusk it will be Rosh Hashanah (ראש השנה). Amir my colleague is looking for pomegranates, something traditional to eat at this time.

Alolita my colleague told me that the Dussehra (ಮೈಸೂರು ದಸರ) ten day festivities also started today.

As this is the day when the Localisation team is together for the first time, I am happy and I wish you all a joyous day wherever you are, whatever you do.
Thanks,
      GerardM

Presenting Sue's barnstar

Sue, the #Wikimedia Foundation director presents her own barnstar to deserving Wikimedians. Guess what, she speaks English and wants to present her barnstar to people of all projects and all languages who deserve recognition.

As I am in the Office for a week, I have been given the honour to present you "the program" and explain what else Sue gets out of it.

What Sue does is test the software and it works for her best when it is fully localised. She is looking for people she does not know personally and therefore is looking for people from the community to make suggestions to her. Sue likes it best when there is a story attached to the suggestion.
Thanks,
      GerardM

Old documents presented well

A #German #MediaWiki wiki that specialises in old documents beats the Wikimedia Foundation to the punch  and implemented the WebFonts extension.

Santhosh helped with some of the finer details of implementing the Fraktur font, but as you can see using Webfonts for source material is quite powerful.

It also allows us to transliterate the Dead See scrolls and present the text in a Font that is similar to the written original. Once it is transcribed, it becomes easy for linguists and theologians to compare the old with the new.

Transcribing is an activity that is very much anyone can do. Being able to support a text with appropriate fonts is something where we will be able to excell.
Thanks,
      GerardM

Being a newbie ... it sucks

I have to post messages to #Wikipedias. I am doing this with my Wikimedia Foundation profile and I am not happy. I am treated as if I am stupid. I cannot add new topics to discussion pages, I can not even edit the discussion pages I need.

There is a very easy solution for me; I can ask for global sysop rights as I am "staff" however, that is cheating. It is more fun to start yelling because the restrictions on newbies are so ... off-putting.

What is the point of not allowing to enter new topics ... It is stupid!
What is the point of not allowing to edit a discussion page ... It is stupid!

Guess what I would be doing if I did not make a career out of it? I would walk not to return.
Thanks,
      GerardM

September 26

In Finland today is the official name day for Kuisma, Finn, Gáivvaš and Johannes, Juhani, Juho. Finland is not the only country with name days. The fun thing is that people can say that it is "Kuisma day" and expect you to know that it is September 26. Well that is to say, when you are Finnish.

When your language is different, the name days are different or they may not exist at all. So what to do. How do you deal when you translate a text that includes name days? Or is it just that way? Should name days be considered as an open standard because they contain public facts or can they be proprietary..

When name days are to be part of a standard, it would make sense for them to be part of a standard like the CLDR. On the other hand, there is so much data that is still missing. Does it make sense to add even more to the CLDR?
Thanks,
      GerardM

Going to San Francisco

The #Wikimedia Localisation team will be going. I doubt it is wise for us to wear flowers in our hair as the song suggests.

Localisation and Internationalisation is very much part of any and all software development. For MediaWiki this is established principle; updates to the software go to translatewiki.net on a daily basis and the text of messages is often improved to allow for localisation.

Staying at the Wikimedia Office will allow us to improve our contacts and consequently improve our effectiveness. Yes, we will have "some" fun but without it it is just a job and we are passionate about our mission.

One thing that is REALLY exciting is that we will discuss how and when to bring the WebFonts extension into production. For me this is like a dream come true.
Thanks,
       GerardM

The #Wikimedia deployment window

There are several teams of #MediaWiki developers. The work done by a team is often related and consequently it makes sense to deploy new and amended software together.

Deploying code is an art in its own right. At the Wikimedia Foundation it is very much an art for those people who have advanced skills in software review. When software goes live, it may work in a test environment but at Wikipedia it hits high traffic. This can break code and the persons who deploy are all too aware of this little gotcha.

The Localisation team has its own deployment window and the team is informed about what is planned to release. They can comment, add to it and even remove items from the list. For your amusement, this is this weeks list:

We have planned for the following code to be deployed. I suggest we
only put it in 1.18wmf1, and do not backport it to 1.17wmf1 to reduce
complexity.

http://www.mediawiki.org/wiki/Special:Code/MediaWiki/tag/i18ndeploy

Contains revs (all reviewed - tag can be removed when backported/deployed):
97606 - Narayam bug fix in keybuffer
97609 - Narayam Nepali update
97644 - L10n fix for upload wizard
97793, 97804 - Number grouping updates for many Indic languages
97962, 98006 - More flexible Language::formatTimePeriod()
97982 - WebFonts for Sanskrit (WebFonts is not yet deployed on
Wikimedia, we need to plan for that. How? - backport to 1.18 in any
case)
98023 - Babel i18n bug fix

Thanks,
      GerardM

Babel #localisation is now a priority

All #Wikimedia wikis have the Babel extension enabled. Slowly but surely people are starting to use it and it does already support many many languages.

For the Lezghian language there is a Wikipedia being developed on the Incubator. As a consequence there are Wikimedians who know Lezghian and it does make sense when they can find each other.

When this extension is localised at translatewiki.net, the Lezghian portal and the Babel information on user pages will be looking great. Once the localisations are enabled for Lezghian on the WMF wikis, you can indicate your fluency for this language and other languages as well. When the localisations are a bit off, you can update them at translatewiki.net and, the next day you may be able to notice the difference.
Thanks,
     GerardM

#MediaWiki #RTL support when upgrading to 1.18

Amir is a Wikimedian and a linguist who quickly gained expertise on how to support RTL languages like Arabic and Hebrew. Not only did he add many bugs in bugzilla, he provided us with a lot of fixes as well. His latest project is supporting the upgrade for RTL to release 1.18. This contains RTL fixes by him and by SPQRobin.
Enjoy,
      GerardM

Administrators can thoroughly customize every MediaWiki based wiki by editing CSS and JS files, such as MediaWiki:Common.css, MediaWiki:Common.js, MediaWiki:Vector.css etc. These customizations are usually requested by the editors community and fall into two general categories. The first category are changes to the design of the site, such as setting a different background image, a festive logo, a different font or a different color for the revision comparison (diff). The other category works around bugs until they are solved in the core code.

Customizations may need to be updated by the local site admins specially after the deployment of a new version or MediaWiki or of a customized extension. Sometimes old customizations that worked around bugs just quietly stop working after the bug is resolved. They don't affect the site much, but they fill up Common.css with now useless code that makes maintenance much harder, so it is best to remove them. Sometimes changes in the software break the customizations and the site appears broken to the users - in this case they MUST be removed or updated.

MediaWiki 1.18 was rolled out to several wikis a few days ago. Among them was mediawiki.org, the website about the software itself. MediaWiki 1.18 has many updates for the handling right-to-left (RTL) text, especially on pages where it is mixed with left-to-right text. Before the upgrade mediawiki.org had several customizations to fix the display of RTL text in the tabs on the top of the page. After the upgrade this text appeared badly until they were removed.

 All the other Wikimedia wikis will be upgraded next. If you are an administrator in any Wikimedia wiki, you should look at these customization files as soon as possible and also at the release notes of MediaWiki 1.18. Understand the purpose of the existing customizations and be prepared to remove the ones that aren't needed anymore immediately after the upgrade. A general rule of thumb is to take an especially good look at lines that have "rtl", "ltr", "right", "left" and "bidi" in them.

If you need more help understanding these files, contact Amir Aharoni preferably on IRC.
--  Amir

Q&A with the #MediaWiki #bugmeister

As more developers are working on the MediaWiki software, keeping a grip on the outstanding issues becomes more then a day job. Mark Hershberger has as its task to manage the needs of the community and does this in a hands-on fashion by bringing focus to the bugs reported in Bugzilla.

He has been doing it for a while now and this interview may give you an idea why having a bugmeister is a great idea.
Enjoy,
      GerardM

Can you explain what a bugmeister does
The main idea of a bugmeister, is clear from the posted job opening. This basically says that the bugmeister acts to bring the community's issues to the attention of WMF Project Managers and Developers. In addition to making sure the community's needs are heard, I've also worked recently to get the developers from the community involved in WMF activities. For example, I'll be hosting a fund-raising-focused triage in a few weeks where community input is wanted.

There seems to be more work then can be done by one bugmeister, is it true that by focusing on what needs the most tender love and care, you pick from the low hanging fruit ?
There are a lot of bugs in Bugzilla (over 6000 open issues right now) so I admit that bug-solving is driven somewhat by the squeaky wheel since those are the issues the community has shown the most interest in.  I do want to chew through those other bugs but I think that focusing on the new bugs and most-often referenced old bugs will get a lot of these bugs handled.

WMF is very much into agile development, is a bug triage something that you do at the beginning or at the end of a sprint

Good question.  I'm not sure I have an answer, but let me try.

Part of the purpose of triage -- at least how we're using it at the WMF -- is to understand problem reports and how to solve them and, after that, to assign them to a team or a person to work on.

So, as far as I understand sprints, triage would happen at the beginning.

Identifying and assessing the new bugs is what I understand you do. How does this fit into the process of fixing bugs
This varies with how high a priority the bug gets. For a quick overview of the time-line of my involvement time-line see the documentation on MediaWiki.org.

For example, bugs that are "highest" priority get very close attention. "high" priority bugs less so, and so on.

Every week there are more new bugs then there are bugs that are marked as fixed, how significant is this?

First, the weekly bug report isn't completely accurate -- it has some bugs.  For example, I noticed recently that it had reported 594 bugs created in one week when a query shows only 122 were created that week.

Second, it is normal for projects with open bug reporting tools to have more bugs created in a given period than closed.  I'm having trouble finding the report at the moment, but I recall seeing Mozilla Firefox had more bugs opened in a year then closed.

There is a perceived lack of people working on the review of software, can you comment
Over the past year Rob Lanphier has worked to get more people reviewing the code since, yes, we had too few people doing code review. We're in a lot better position now, but we still do not have the resources to review every bit of code that is in subversion.  I'd rather make the code repository and code distribution available to anyone who wants to extend MediaWiki, since this is better than telling people "We can't review your code, so it isn't welcome!"

As an example of how code review has gotten better, Rob Lanphier and I have been doing a lot of work on getting code reviewed faster and code marked FIXME fixed faster as we ramp up to a 1.18 deployment. This is a big pain point since we want to make more frequent releases of MediaWiki and become, as you pointed out, more agile.  And we don't want to release un-reviewed code.

I think, though, that if you look at the way FIXMEs have been resolved, or how new revisions have been reviewed, that you'll see some very good trends. In the past few weeks we've really been driving unreviewed code down pretty hard.  I'm confident that we can continue to keep unreviewed code low.

Code not written by WMF employees is certainly reviewed -- especially if it is going to be deployed on the site or released as part of MediaWiki. Since we only have limited resources, we cannot review all code in our Subversion repository.

For example, we host Semantic MediaWiki and extensions, but this code is not used on any Wikimedia website and is not distributed as part of MediaWiki, so, in order to make sure that the code we do release reviewed, we have to ignore Semantic MediaWiki for the most part.

An example of MediaWiki code that is not used on the cluster, but that is reviewed is the new Installer for MediaWiki or code that supports databases other than MySQL (such as PostgreSQL).  But, when it comes to Database code we're somewhat limited in our ability since we're so focused on MySQL, so we are looking to recruit volunteer reviewers who use and are familiar with the other databases that MediaWiki can use to help review this code.

Siebrand indicated that the presence of people from many disciplines was why the recent i18n bug triage was so successful. How does this mix with the small teams typical of agile?

Triages are more successful when more people are involved, true. Since a basic part of the Bug Triage, at least in the way I've been running them, is open community involvement -- I hold the triages on IRC and everyone is invited -- I don't think we're limited by small teams.

What is the measure of your success; is it in the volume of work done on bugs or is it in a changed way or working of the developing community or is it a mix of things

I think it is still too early to answer that question definitively. I'm actually working with a researcher to find out what sort of metrics we can find in the bug database to draw good conclusions about community involvement, # of bugs solved, and the like.

A function like a bugmeister seems far removed from the community editing on the projects, do you and how do you keep informed on what happens in the projects

I work with different community members to enable editing on the projects. Extending the functionality of a project like we did with the Google News Site Maps (GNSM) extension on wikinews is a big part of that.

This coming Wednesday, I am having a WikiBooks-focused triage with some people from that community that I met in the Collection extension triage. During this time we'll be able to find out how we can help their project succeed more.

What is your favourite MediaWiki project, what is the most challenging project
I admit a soft spot for WikiSource, but this is mostly because I think we could use it to provide a community-driven replacement for ReCaptcha. Google is using ReCaptcha to help the New York Times scan in old newspapers, but, as far as I can tell, they aren't making the result publicly available. I think we can do better.

Thanks,
Mark.

The difference #Urdu makes

When you learn to write, it matters where you learn this skill. You may learn to write in a different script, and the characters may look different from what is considered to be the standard. The examples to the right show fonts that are usable for the Urdu language. Some reflect how Urdu is written manually. for instance in the Nastaleeq style.

Of the examples to the right, the one at the bottom comes with some versions of Microsoft Windows, the others are developed with Urdu in mind by the Center for Research in Urdu Language Processing. As Urdu uses its own set of characters of the Arabic script, it is no wonder that Urdu has its own keyboard mapping as well. This is available from the same organisation..

Urdu is a good example that when you support languages, you cannot take too much for granted. It also indicates that as we develop software intended to support languages we will need people knowledgeable about their language. People who are willing to test the software we develop for all languages.

These same people may help us provide, amend and verify the information that exists in standards like the CLDR for their language. We need to build teams of people willing to support their language. This will not only help us get the best out of MediaWiki, it can have a much bigger impact when we do this well.
Thanks,
     GerardM

#Wikia, developing #MediaWiki is a community effort

Many organisations rely on MediaWiki and even though the Wikimedia Foundation provides a great product, it does not always provide exactly what is needed. Wikia is one organisation that has a track record of adding its own functionality on top of MediaWiki.

Wikia introduced functionality that is of a more general interest, and consequently Wikia and the WMF are working more and more together. As the Wikia software is localised at translatewiki.net, the functionality of the Translate extension and its reporting are important. It is important for Wikia to know how well the localisation for its software is doing.

To make things happen, Wikia produced specifications and wrote code that provides translatewiki with real time statistics. As the Translate extension is very much under development, the Wikia code had to be back-ported by Niklas into the live code. This would have been less of a job when the Wikia developers had used the WMF subversion.

It is wonderful to see how collaboration makes everybody a winner.
Thanks,
       GerardM