User:Contraexemplo/Outreachy/Outreach strategies

Overview
Most of Wikimedia projects have many years of existence, and MediaWiki, as the software that serves them all, is already 16 years old. And while it is a solid product, with multiple functionalities and uses, its documentation and localization practices need review and reworking as much as it needs more technical translators. In this document, I discuss and explore multiple aspects of MediaWiki while comparing it to other projects and documentation standards and my own experience as a translator in free and open-source projects. Finally, I propose solutions and new strategies to recruit new technical translators.

Definitions

 * Target groups
 * People that share the same interests and/or values and are keen to make contributions to Wikimedia. They could be:


 * 1) People with no involvement with FOSS (as user and/or contributor) and no involvement with translations.
 * 2) People with involvement with FOSS (and/or technical knowledge).
 * 3) People with involvement with translations.


 * Priority languages
 * Languages spoken by the most active communities.


 * User guides
 * Any page under the Help namespace.


 * Appropriate fluency in English
 * Range from intermediate level to native fluency.

Documentation
There are several ways to convey a message, and that's why style guides are an essential tool when writing documentation: they provide guidelines which enforce consistency, setting standards to be followed, and quality references to be seeked. They are the ultimate expression of how the project communicates with people, and are therefore an important part of the brand identity. Consequently, the absence or incompleteness of a project's style guide will have direct influence on how the readers' perspective of it.

MediaWiki’s style guide is far from being perfect, especially as it relies too much on external references without highlighting which practices it considers the best. Unfortunately, this is a problem that is not confined solely to MediaWiki, as it shows up on other documentation like the Translation best practices. Writers end up without good and reliable resources to do their work, leading to difficulty in establishing a target audience and a proper style of writing. And users, especially new users, may face problems to understand new concepts and processes.

My main two references are the Atlassian writing style and Write the Docs. My recommendation would be following their examples, while having in mind documents like wikipedia:Wikipedia:Manual of Style, and coming up with a original style guide for MediaWiki.

Current status
''To access the complete analysis, go to Documentation status

As Help:Contents receives a significant amount of accesses and is mentioned as the reference for those looking for help on MediaWiki, I decided to study it and all the pages mentioned in it as well.

Chinese, Catalan, Brazilian Portuguese, and European, French and Polish are the languages with the highest translation rate on mediawiki.org. However, of these six languages, only two (Chinese and French) are featured in similar positions in the ranking by average views in a month, and only four (Chinese, French, Brazilian Portuguese and Polish) are among the ten most accessed languages. On the other hand, Swedish, Hungarian, Persian, Finnish, Turkish and Arabic are the languages with the lowest translation rates. Swedish and Turkish positions are similar in both rankings. However, surprisingly, the positions of the other languages in the completion ranking and the pageviews ranking differ from lot, especially the Help: Contents page in Arabic, which is the seventh language with the most accesses.

Technical translation
As a person new to the Wikimedia movement, I experienced first hand what is like to be an extremely confused and overwhelmed newcomer as I translated pages like Help:CirrusSearch. It took me days to get used to the Translate extension workflow and weeks to understand the most basic concepts behind it. And as I learned more, I realized that my path to begin contributing with technical translations was extremely erratic and far from ideal.

Confusion about ways of contribution
It took me a while to understand that translating MediaWiki strings and translating MediaWiki documentation are two isolated tasks with their own ways of entry. While you need to have an account on translatewiki.net to do the former, a mediawiki.org account is enough to do the later. It got me thinking that the process to become a translator needs to be easy to follow and to understand. Tools and resources have to be presented briefly but effectively so newcomers are aware of where to find answers to their questions. I believe meta:Meta:Babylon/Translations it’s the most recommended page to present to newcomers, but there should be also initiatives to improve it creating new or complementary forms of introduction and training as instructional videos. That way, we will welcome those who are new to the movement better.

Lack of standardization
The software was completely translated to multiple languages before having its documentation translated as well. MediaWiki itself does have a glossary (also present on Meta as Glossary), but it isn't widely publicized. Extensions also have a problem of standardization, forcing translators to search for relevant strings on translatewiki.net (for instance, as pointed out on Translate extension documentation for Help:Extension:ContentTranslation).

It seems that the community is aware of those problems, as there is a Phabricator task) dedicated to discuss them. A tool like Mozilla's Transvision would ease the work of tech translators. But still, a list of conventions as well as a writing style guide for each languages would help them while that isn't implemented.

Silent community
Most free software communities like Debian's and Mozilla's organized themselves on teams to build translation strategies. They are dedicated teams to this task, reviewing each other's work to assure the translations quality, documenting their practices and electing facilitators to talk to those who want to join. But here and in other Wikimedia projects, it's different: we usually have lone translators who usually aren't dedicated to that task and just happen to perform it once in a while. This creates two main problems: the lack of coordination on translation efforts and the lack of an active, strong community to welcome newcomers.

Initial outreach period
I made an attempt of making a shorter version of the Translate extension  user documentation. It tries to rely less on text and more on images and short videos. There is, of course, room for improvements as I had little time to elaborate the text on it better. But it proved to be a great tool to introduce people who got interested in helping as it is really straight-forward.

Initially, I had planned to do a couple of screencasts like this one explaining the main concepts as quickly as possible. However, the lack of proper audio equipment and a quiet room to record were my main preventing factors, in addition to the lack of experience editing this kind of media.

On administrative level
My main means of communication with universities were email and meetings in person. There are a couple of problems with the former:
 * Institutional emails addresses usually have firewalls that block and report messages from certain email providers. So if you try to contact them from a @gmail.com address, for instance, they probably won't even see it.
 * As it was revealed to me a couple of times in meetings, if your message wasn't reported as spam, they might ignore it or report as spam themselves if they don't recognize the sender.
 * So the best way to contact them avoiding being flagged as spam is having a institutional email address youself and this is a really bad sign. It means that you need someone from inside the university to have a chance of communication.
 * It takes a long time to get your point across and receive a proper response.
 * Communication is usually done person-to-person so this strategy doesn't scale well.

Now, about the latter:
 * It also doesn't scale well as it requires you to pay them a visit.
 * It takes some time until you finally get to schedule an appointment.
 * While a meeting is a good starting point because you get the chance to present the project and its main aspects and it's possible to have good results, you still have to solve some things through email later. And this, again, takes a lot of time.

It's hard to tell if this is only due to the time my attempts were made. As an undergraduate, I experienced both easy and difficult-to-reach administrations. To be sure, it would require more time to be sure if this could be successful.

On student level
My main mean of communication with students was social networks, especially Twitter and Facebook. On the former, I had conversations with students directly. On the latter, I had to ask for students who volunteered to convey the message on Facebook groups for students only. I also contacted coordinators from undergraduation courses like Mechanical Engineering, Computer Engineering, Software Engineering, Computer Science and Information Systems to share flyers and informative emails with undergraduates.

Twitter
Searched for students that could convey the message on Facebook. Sent them promotional materials and a complementary text to share on student groups. Haven't heard much of it, however. As far as my experience tells, those groups are constantly updated with multiple discussions and adversiting, so while it's possible to have some exposure there, it's difficult to achieve retention. In addition to that, organic reach on Facebook is dying. So punctual promotion isn't exactly effective.

I also published this tweet to test things like the relationship between Wikipedia and MediaWiki. Here is the data:

This and the way Wikimedia profiles like Wikipedia interact with their followers tell me that outreach may be more effective on microblogging platforms like Twitter. But again, it's quite difficult to measure how this could influence people to enter the Wikimedia movement without a greater study.