Ruby on Rails I18n: developer - develops, client - fills. The rest will be taken care of by the service.

Managing internationalization in Rails using third-party services

One of my favorite components of Rails is the organization of internationalization and localization using the class I18n and dictionary files (en.yml, ru.yml, etc.). But if you take not a “spherical project in a vacuum,” but a real application with a group of developers and a bunch of branches in the repository, sometimes the head swells to resolve conflicts when combining different branches / versions that somehow arise in the locale files. How to be? It is then that we are reminded by various third-party services with their own gems.

99Translations

The first internationalization management service with which I met was 99Translations , which provided the ability to upload a special locale file 'master.yml' to the server (the file should contain only keys) and there parsed and added the keys to the rest of the installed locales. Further, on the dashboard, information about new keys for which translation is required was displayed. After complete (or partial) filling of dictionaries, they could be picked up from the server and quietly committed to the repository.

Why am I saying past tense? Because this service will sink into oblivion on March 31, 2012 and it is not advisable to use it in real projects. Here it is given solely as an example.
')
Pros:
- Simplicity and clarity of use from the point of view of the program, nothing superfluous.
- 1 key file keeper: no conflicts, firm confidence in the presence of internationalization on the application pages for all locales (read, no 'translation missing' messages), provided that you added it to master.yml.

Minuses:
- You can not simultaneously enter translations through the web interface for multiple locales
- However, an overloaded web interface (it seemed to me a bit redundant, with a heap of unnecessary tabs).

LocaleApp

LocaleApp immediately caught my attention with its “freshness” (still in beta) and Rails-oriented. Looking at the dashboard and spending a bit of time there, I realized that the interface is intuitive, and the ability to fill several locales at the same time makes the life of the translator / client much easier (as a result, it improves the well-being and mood of the developer).

Further more interesting: when an application is launched in development mode, the gem provided by the service automatically requests locales from the server (it does this on every request, which slows down the application to a certain extent) and tracks the missing keys during the rendering process. If they are found, he will ensure that they are added to the dictionaries. Convenient, isn't it? Well, go to the dashboard, you can see how each locale is full and what should be added.

Pros:
- Ability to fill multiple locales at the same time.
- Automatic download of the latest internationalization for each request.
- Automatic addition of missing keys to localization files.
- Nice looking interface.
- Excellent start-up: adding a new locale to the project via the web interface, you get all the standard keys (names of months, days, date and time formats, and more) already translated.
- Free-to-play beta: there is an opportunity to try and understand, and whether we need it.

Minuses:
- Background processes are rather annoying to the developer and slow down the application (but, fortunately, they are easily disabled - see the heme documentation).
- Sometimes requests for missing translations with scope work incorrectly: I18n.t ('key',: scope =>: some_scope) and it automatically adds them to the wrong namespace (the 'key' will be added as a global key). Well, beta is beta. Hope this is fixed.
- Due to the fact that you can upload any dictionary file to the server, long-deleted keys sometimes start to be “resurrected”. Therefore, it is better to do this through a web interface.

PS The main advantage of such services is that all branches and all developers have the same locale files and when combining branches / versions you can concentrate on comparing the program code, and not on the features of the translation into one language or another (although this may seem to someone minus). Just as important
is the fact that you keep translators away from repositories and source codes, well, and they, in turn, are masters of locales.

Update: removed abbreviations.