Introducing Lit 1.0: a reworked i18n Ruby gem that will make your web app's translation a lot easier. Watch the video for details!
i18n - a short recap
If you want your app to reach as many people as possible, you should be already familiar with the term internationalization. If not, internationalization (dubbed i18n, as there are 18 characters between the first and the last letter) is the process of translating your Rails application from default English into a custom language.
Internationalization consists of extracting bits (strings, dates and currencies) out of a Rails application and providing proper translations and formats to them. This second process is called localization and is shortened to l10n. If you are interested in the matters of internationalization, read our brief introduction to it.
Internationalization and localization in Rails apps are usually done using i18n library. But app copy is often written by non-technicals. That's when our solution, called
lit comes in handy.
Lit - a custom library for Rails app internationalization
Lit (Lost In Translation) is a Ruby gem that installs a web interface for Rails app internationalization, which we open sourced on GitHub back in 2014. It enables the user to translate Rails web apps into custom foreign languages and edit copy on their own. A pretty useful tool for non-technicals who want to change a word here and there without bothering the development team.
The convenient web panel in your Rails app, installed by
lit, allows authorized users to edit your website's translations, localizable data such as date formats or copy text without the need to deploy YAML translation files along with the application's source code. Instead, the app's main database is used for storing translations, usually supported by Redis as cache.
A WYSIWYG editor, useful for editing copy content, and an API for synchronizing
lit with other servers are also included.
lit is a necessary feature in those applications whose display language is different than default English. It enables us to build an application based on the content we understand and which can be later translated by our customers into their respective languages.
Customer feedback for lit
Since we had contributed the
lit gem to GitHub, it scored over 26k downloads. As of 2019, Prograils use Lit as a feature of most web applications we have developed over the years.
Five years of using Lit has been enough for us, our customers and the GitHub community to spot the areas for improvement. We had listed them, worked hard and are now proud to present you the new, much better web interface for app translations. Read on to learn how we managed to move on from
lit v.0.3. to
Watch the ultimate guide to Lit v. 1.0 gem and its new functionalities:
Automatic cloud translation with Yandex or Google Translate
Automatic cloud translation is one of new lit's highlights. However, this is obviously best suitable for tentative translation or translating short and simple pieces of text, as we all know the limitations of automatic translation.
lit 1.0 you can quickly translate a piece of text using a built-in Google Cloud Translate or Yandex Translate feature.
All you need to do is:
- spot the localization key of the fragment you want to translate,
- scroll down the "Translate using Yandex" menu,
- choose the language from which you want to translate,
- or just click "auto" to make lit automatically recognize the original language,
- click "update" to save the translation.
Deleted and visited again
Ruby on Rails tends to generate more localization keys that are actually displayed by an application. When a particular key is not or has never been in use, we can simply delete it from Lit. With one provision, though.
Until now, the deleted translation was permanently removed from the database. In Lit v.1.0, we have the deleted and visited again tab.
Whenever a deleted key is called by the console, it can be seen after clicking this particular tab, from which it can be easily restored, if needed.
The "completed" status
In lit v.1.0, translations can be marked as completed in two ways:
- you can do it manually, by clicking the dedicated checkbox,
- just edit the text and the translation will be saved automatically.
When all the translations for the particular localization key are completed, they are no longer visible in the not translated section.
Import and export to .csv
With Lit v.1.0, the content from the engine can be exported to .csv files and vice versa. If you need a backup copy of your application's content, you can now save it to your cloud or hard drive. On the other hand, if you outsource a content writer and don't want to grant them access to Lit for whatever reason, you can import the text from the .csv file.
The .csv file you download from lit will contain the localization key's ID and the translations in respective languages.
As of now, this functionality is available only from the terminal as a Rake task, but we are considering its inclusion into Lit's interface.
Lit 1.0 also contains a number of bug fixes, including:
- translation saving during transactions that are eventually rolled back,
- eliminating the bug which led to deleting translations after cleaning up Redis while the app was working,
- a unique index for one of the tables, preventing duplication of translations.
Lit 1.0 lets you translate short portions of text in your Rails application automatically using Yandex Translate or Google Cloud Translate. You can also manage the localization keys by deleting those unused by an app and restore them whenever you need, thanks to the "deleted and visited again" tab. Moreover, you can automatically set the translation status as completed besides the manual option. Lit also enables you to export the localization keys and translations to .csv files and import them to the engine.
We aim for the best experience during its use, however the need for some additional improvements may arise. Have questions or feedback? Write a comment. We will answer to every one of them!
For more details, see readme at lit's official GitHub repository.
A huge thank you goes out to Michał Buszkiewicz for invaluable help during the creation of this article.