Over the last days, I localized GitLab into English and German. To accomplish this, I made use of the Rails L18n API.
Commit ff3166b is a squashed commit of 7b0d606 .. bd514ed in my master branch. It includes all changes in the view as well as YAML files for en + de.
I know, the YAMLs are quite dirty. But in fact, GitLab is a rapidly evolving application. Over the last 10 days, I were really busy merging new commits from gitlabhq:master and adjusting to changes, thus refactoring of YAML structure should be another piece of work or localization would take ages to complete.
After inspecting all the views, I also noticed a inconsistency of labels(either "Save" or "Add a new abc..") and alert dialogs (DELETE). Sometimes only "Are you sure?", sometimes a more concise "Are you sure you want to ....?".
GitLab is a great piece of software and I'd really like to see it being localized into serveral languages. Keep up the good work, you're awesome!
Localized GitLab. Available Languages: en, de.
Remember to activate I18n in config/application.rb
Enables l18n. Default language: en
Thanks for your hard work. But we not going to support i18n, coz this will take much time in the future. Sorry!
FYI:My native language are russian and ukrainian (not english).
@randx @ariejan Thoughts?
I dont want localization.
Remember situation with github. After a try they reverted to english
I understand your concerns. Maintaining several languages might easily end up very time consuming. How about dividing translation efforts into teams (like the Trac project does with Transifex)? One might define some kind of "i18n freeze" about 5 days before a 2.x release so each team has enough time to adjust or similar
If i18n is going to be postponed for, let's say, serveral months, time needed to catch up with i18n will be the same as if it would have been a continuous process within this duration already. Or worse: i18n might be abandoned because translating x months takes far too much time.
Information about the time consumed for this request (might come in handy for this discussion):
It could be some kind of personal preference but I like native interfaces, especially for internal use.
We're using gitlab currently for educational purposes which makes i18n mandatory in our case. It didn't exist, so we made it.
I think making GitLab be i18n-ready would be nice. But I would advise to do it like Rails does: i.e. be i18n-ready but only ship English and make other languages opt-in. Put all the translations into a separate repo so code releases are decoupled from translations.
You could then add a bunch of rake commands to list, install and update i18n-files.
@alexdo kudos :-)
Having i18n would be nice, but it does add a lot of overhead I don't personally want or need.
Also, how do you keep the translations in sync with the project? How's keeping track? How can we guarantee all i18n keys are translated?
If there would be a separate repo with translations and an easy to use script that can verify which translations are complete or not, this just might get pulled in.
@randx it might not have worked for Github, but Gitlab will be used in a different environment. Also, only keeping the english translation up-to-date is easy to do.
[food for though]
" Also, how do you keep the translations in sync with the project? How's keeping track? How can we guarantee all i18n keys are translated? "
What about a fallback to english translation (that one being "up to date") ?
Here's a rather dirty approach to a separate repository: alexdo/gitlab-i18n
The integrity check might also be done as a rake task, a spec, ...
@alexdo I assume you expect an up-to-date gitlab.en.yml for your comparison script to work?
I think it is manageable. The devs only provide guarantees for the English version to be up-to-date.
All other translations would be best effort and would reside in an extra repo. And as @rtripault pointed out, untranslated strings would show up in the fallback language (i.e. English).
@riyad Exactly. One translation has to be kept up-to-date - ideally the english one within gitlabhq/gitlabhq which also acts as a fallback.
Keeping other translations in a separate repository decouples i18n almost completely from the current development process. This would also led grammar and typo fixes to show up as pull requests within the i18n repository, making the gitlabhq one less cluttered and more focused.
Well if we want to do this, we should probably standardize the gitlabhq language file. Cause right now there is a ton of variations to several parts.
As much as I don't see any need for this, mostly because I'm English speaking. And it would add a ton of overhead... It can be managed if there are some sort of dedicated translating team. And each member would be responsible for his/her own language.
But then again, why not just fork the repo and add your own language. then they can just download from your repo. Which is pretty much the same thing, with a lot less overhead.
i18n support takes some extra time. Time is valuable for me. It will be perfect for future if we have full time team. but now -1. @vsizov @ariejan @SaitoWu - lets vote.
No for i18n at this time, unless there is a volunteer to maintain i18n and create/manage translations.
ok - so I close PR for now.
@alexdo thank you for your work
@alexdo already did an awesome work doing the "hard" work. With all the respect for you guys by all your time and effort providing this awesome tool, It can't get too much more work then what we have now.
For many of you, despite the fact that english is not your mother language, it can be low priority to have it localized to your original language, but for others it can be blocker.
I respect your decision for not accepting it right now, but I would like to suggest another approach, considering that @alexdo have the same need I do, we could both take responsibility for the i18n stuff.
So here is the deal: Merge the PR and continue the development without thinking about new i18n stuffs, and we will provide all needed changes to follow up. So you can still coding without worrying about i18n and let the community take care of what they need for.
I'm all up for an approach driven by the wider community. While most developers are probably fluent (or at least proficient) in English, they are not the only ones using Gitlab as a tool. I've got a Germany-based tester (they are the best ;) ) who is not all that fluent and would greatly benefit from an i18n'd version.
Please consider all the effort @alexdo has put into this and open the project to a much wider audience.
If this not slowdown this project +1.
What about managing translations with a tool like http://crowdin.net/ ? You can have a big community for translations, see the achievement of each language, and it's free for open source projects :)
I'm a french freelancer and using gitlab for managing my clients' requests/issues, etc.
Most of them don't speak english and are even a bit repelled or scared by it which means I keep getting "grocery lists type" emails from them… :/
Long story short, I'd love to have a localized version of gitlab, and seeing as I've been translating articles from English to French for some 9 years (and wordpress themes when the need arises), and was part of the (now unfortunately dead) WSP International Liaison Group, I could probably "pitch in" for the French version, provided I'm given sufficient info on what to do :)
I hope this actually gets somewhere, I'm watching the thread anxiously :)
for me, as you guessed.
Looking forward for such an feature. Let others translate, than your work will be not much more.
Don't know how it's in Ruby, but in PHP I can be i18n with moving "echo 'hello world';" to "echo __('hello world');". Just including an small script wich loads the right MO or PO-Files and than you'r on the go.
May this won't work in Ruby, I don't write Ruby-Scripts ^^ Just as an Idea.
My customers are able to communicate in English, but it would be better to give them access to my gitlab in my mother-language (german) so the can read in the wiki, see the issues and milstones, without worrying about their english-knowledge ^^
I am from China. In China, more and more IT companies start to use Git and GitLab is one of the best management tools for them to use. However, without Chinese translation, a lot of developers who are not familiar with English cannot use this tool easily and the company has to consider other tools.
I think nobody don't want to spread their work to more countries, that's why more and more software start to support I18n. GitLab can be better with I18n supported.
Just to annoy the gitlab developers a little bit more, I'm from Brazil and I'd love to have Gitlab in portuguese.
I'm willing to translate it if necessary. The idea of a different repo for i18n with fallback to english was very good in my opinion.
No offence, but I just can’t imagine a software developer that can’t understand English at all. How is that possible? (note: English is not my native language)
I agree that is necessary to understand english in order to become a master programmer. But that is not how we start right? At the age of 17, when entering the university, most people here in Brazil are not familiar with english. Of course, sooner or later they better learn, but with so many things to learn at the same time, would be nice to make it easier for them to use a simple tool as gitlab.
Apart from that, all other systems we use here at the university are in portuguese, it's a bit odd to suddenly shift to english when switching pages.
You assume gitlab will only be used by software developers... I'm watching gitlab progresses because I want to use it to implement a software forge for people ( political projects ) who don't speak english...
An alternative is consider the translation of the interface through a browser extension like this Star Citizen Site Localization, I am willing to participate.
Given the discussions here and in #3309 I think there is a demand for localization and internationalization in GitLab.
I have started translating GitLab from scratch as @alexdo's work was very outdated.
Most of user facing pages are already translated, however there are scenarios that need more attention as I only translated what I could see.
Admin, help pages and dates (possibly other such things) are not yet translated.
I'm willing to maintain translations and shape this work to a pullable state - currently more work is needed.
Contributions and comments are most welcome, you can find the repo here:
I've also added a repo for different locales (currently only Polish) here:
Will you create a new pull request once the english version is finished?
If it's accepted, i'll work on a german translation.
Maybe we can create a project on https://www.transifex.com for the translations.
It's free for open source projects, and the contributors don't have to edit the files directly.
So we'd avoid syntax errors.
I agree that a Transifex project would be a great way of collecting translations.
I'l work on an italian translation as soon as the pull request is accepted.
+1 for Transiflex, I would help to translate to german.
New discussion in: #6455
Localized GitLab. Available Languages: en, de.
Enables l18n. Default language: en