Localization of the IT site by GitHub users and features

Summary

Probably, once any site having an international audience is faced with this - not all users read in English, which means that the audience can be expanded by adding content translations into popular languages.

However, the services of third-party translators cost money. Worse, our content is full of programming and math, so not every translator is suitable.
')
Having estimated the price on a piece of paper, I immediately realized that it does not yet fit into our budget. We began to look for other ways.

I will try to talk about the decision we came to, namely:

• as we cheaply used github angrily for custom translations
• as the specifics of the site interferes with translation
• how realistic is it to get help from users
• how to mark translations for google search engine
• finally, how visible (or not visible) is the effect of the translated content

For details, welcome under the cat!

Preliminary calculations

So, here we have a site with English content. With imperfect English. I can translate into Russian. Colleagues, too. These linguistic abilities of our powerful team are limited.

I started by asking for the cost of professional translators. In the thematic thread on Reddit they called me a minimum of 5 cents per word. And on the ProZ there is even a sign - here the numbers are completely disappointing.

Imagine - we have at least 200 basic texts (in the sense, these are tasks for beginners, students) - not counting wiki articles. The length of texts from 100 to 400 words.

Taking the average length of 200 words and multiplying by 200 tasks we get 40000 words. 5 cents per word is $ 2,000. If translated into 5 languages ​​- 10 thousand. If you count 10 cents - then $ 20,000. If there are more languages, more money is needed.

This is a small amount of money — a million rubles at 2015 prices — for some medium-size business. But our team is just a couple of enthusiasts - and our site is not intended to generate profit. We receive not money from users, but rays of good - and in general we are satisfied with this.

However, the rays of good site can not translate.

There are more questions with this approach:

• How to check the quality of the translator's work - does it correspond to payment? Can I translate Google translate from Spanish, French, Chinese back to English?
• How to know in advance whether these costs are relevant? What if translations will not be in significant demand?
• source and translation format - not every translator will want to work with MarkDown that we actively use.

Users as volunteer translators

Of course, the option is possible - to declare a crowdfunding campaign and collect money from users for translators. However, at this place I naturally came to the idea - wouldn’t it be easier to ask users to translate into their native languages?

Immediately removed one of the problems - of course the site users are familiar with the special terminology. In addition, they have already read these texts, solved these problems, and it is easier for them to express complex phrases clearly.

However, will the participants want to help for free? Indeed, for many, the problem is not even “gratuitousness” —but just someone is bored doing it, someone has no time.

It was to find out. Immediately I will talk about the results - we still have less than 10 thousand more or less active users (not counting those who only look at the site once, etc.) - currently 10 people have participated in the translation. about 0.1% - in any case, it is much better than if no one helped!

But how to organize the translation process technically?

Add the ability to edit content by users? It is not very difficult, but it would be nice to have clever restrictions on rights, preservation of revisions, etc.

Thinking about revisions, we remembered a wonderful resource GitHub (which we constantly use for many other purposes). Now I will tell you how it works as a result.

Storing translations on GitHub

We started with translations into Russian, because we could do it ourselves.

We created a project on GitHub, added daddies to it with the names corresponding to the two-letter language codes (ru, fr, de, es, and so on). Inside the folders we place files with content translations. Just task-1.md, task-2.md.

The site using the githaba API easily tightens the texts directly from there (for GET requests to the API on the githaba, even authorization is not needed). Those. if a person switches to the Spanish version of the task - the site renders it not from the database but directly from the github.

One of the advantages - transfers become OpenSource - which is nice to our volunteers. For example, a student can proudly show a professor - here, I translated IT articles for this site.

Other advantages are in the ways of adding translations. We use two:

• Users who are well aware of Git can clone the repository themselves, add several translation files - and make a pull-request.
• The rest can immediately write on the githaba a translation in the form of a gist, and start a ticket in the project in which to leave a link to this gist - and I can transfer the contents to the file, for example, I myself already.

Of course, we described the detailed process in README.md at the root of the project, so participants usually do not even ask questions.

Of course, translations are not always perfect - but we can fix the broken formatting (by editing the file in the same place on the github) - well, if that is more important - I hope other users will later be able to suggest corrections.

Technical doping of the site

Of course, it took a bit to expand the functionality of the site.

Translated articles have a suffix with the same two-letter language code.

For the pages that the site retrieves from the github made a cache on the server. The truth so far turned off as unnecessary (it is more convenient to edit something without a cache).

According to SEO, they discovered something new for themselves - in the head-part of the pages, links are needed with the hreflang attribute - so that Google doesn’t complain. It was easy to finish - it's easier than to understand exactly how they should look (for each page you need links to all translations including it itself!)

The user who made the translations into Arabic suddenly set us the task of displaying the text from right to left. Coped.

The question that caused us some controversy - should the user immediately show the localized (under his language) version of the page? Well, yes, we can determine the language from the browser - but will the user be necessarily satisfied? So far we have decided to simply highlight the yellow link to the "native" language for him.

Results achieved

This is something that interested from the very beginning. And what if this idea is useless - what if the volunteers do not come to help - and if no one will read the translations?

3 months have passed. We have translations of the first tasks into the following languages: German (DE), Spanish (ES), French (FR), Arabic (AR), Chinese (ZH), Romanian (RO), Russian (RU).

On average, 15 tasks were translated into the language. This is far from 200, but I think this is not bad: after all, translations are relevant for “completely newbies”, of which many solve only 5-10 tasks. Those who pass for a hundred usually know English well.

Google analytics show that page views with translations now make up about 10% of the total number of page views with tasks. Of course, two factors still have an effect here:

Google-Webmaster reports that 2% of clicks came to the translated pages (I thought a little, but then I realized that an average of 7% was translated, if not taking into account the wiki, etc. - so the proportion is adequate).

• the interface of the site itself is not translated, so the basic abilities in English from the user are required - well, recognize the words in the menu, etc.
• the process of engaging users who are relevant translations - of course, also has some inertia.

In general, we really liked this experience - that's why I wanted to share it. Suppose, from a technical point of view, we have chosen a rather primitive way (yes, github, that's all) - but we have not sinned against the important KISS principle - keep it simple, stupid (which I myself love very much).