Skip to content →

Lokalise Blog Posts

March 2019: Word/html support, Lokalise translations, TM 2.0, cross-project referencing

The first 2 months of 2019 are bringing you quite a number of novelties and improvements. Most of the below was triggered by requests with the most votes on You know what to do.

Document file support (beta)

We are introducing support for paged documents – literally the ones that are not key-value based. As a result, you can now upload, translate and download DOCX and HTML files without the need to create key entries what you might have been doing before. With this feature, you are able to use the same TM, MT suggestions, role management while translating both localization files and paged documents.

Start by creating a new project and choose the Documents project type in order to be able to upload paged documents. Currently the feature is in beta and is available from the Essential plan. Support for PDF, InDesign and other formats is coming soon.

How to Choose the Right Language Service Provider (LSP) or Translation Agency

Here it is – your business, proudly built from scratch and on the verge of going global. Whether it’s an e-commerce store, an app, or software, you’re ready to set the course for international growth.

But there’s just one small thing – adapting your product, brand, as well as company information to foreign markets. You might think that what works in your home country, will work across borders, or that it’s enough to have an English version of your webpage.

The truth is – that’s all in the past. Thanks to the Internet, even small businesses now have access to the global market which means international customers are now expecting information and services in their native languages.

Here’s where translation agencies or language service providers (LSPs) come into play.

Libraries for Translating JavaScript Apps

In the previous articles we have seen how to perform localization in back-end: specifically, we’ve covered Rails and Phoenix frameworks. Today, however, we are going to talk about libraries for translating JavaScript apps and briefly see them in action. It appears that there are quite a lot of available solutions, so you may ask: “Which one should I use?”. The most obvious (and perhaps the most sane) answer would be: “It depends”. Ideally, you should check each library and then decide which one you prefer.

Therefore, in this article I will give you a general introduction to the following solutions:

  • Globalize
  • I18next
  • jQuery.I18n
  • Polyglot.js

Note that we will be talking about localizing vanilla JS apps, not about some specific client-side framework. Also, we won’t dive deep into each library because the article would become much, much longer. I’ll only give you a gentle introduction to each tool and then we’ll try to compare them and come to some general conclusion.

Shall we start?

Dec 2018: Editor updates, translating offline, chained tasks, and 11 other features

A new set of features, expected or positively-surprising, bam! We are happy to introduce 18 new functionalities in this update. Should you think we are missing any, please be sure to stop by and add your suggestions or vote for suggestions made by others.

Editor: Focus mode

Translators, one more treat for you. We believe that the Focus mode may help you to finish the job sooner. Do not be distracted by all the available bells and whistles when you just need to translate or review. In order to enable the Focus mode, first switch to the bilingual view.

Store Translations Inside Database With Globalize

In one of our previous articles we were talking about the process of internationalizing Rails applications. That article explained all I18n basics, but it was revolving around placing all translations inside YAML files. There is nothing wrong about this approach, but unfortunately it does not always work. Suppose, your website has lots of user-generated content which should be adapted for different languages. Therefore, I propose to store your translations inside database. Why YAML files won’t work in this case?

Through Spreadsheets to the Stars: the Story of TransferGo

We all love stories. Stories of success, in particular. Stories that we can relate to and inspire ourselves with.

Today’s story is about a project that started back in 2012. We are proud to be not just humble spectators of its vigorous growth, but also participators, offering our services as a localization platform. Please meet TransferGo, experts in international payments and cryptocurrencies with more than 800.000 users around the world!

Case study

Founded in 2012, TransferGo is one of the top UK money transfer companies. Since they signed up with Lokalise in January 2018, their localization workflow has undergone substantial changes.

In less than a year, TransferGo:

  • got rid of worksheets
  • created 5 projects in Lokalise with more than 5000 keys for 9 languages
  • came to handle 95% of the translations using the Lokalise marketplace
  • freed up developers’ time and improved the workflow

TransferGo representative Vytautas Šernas speaks about their recent experience with Lokalise emphasizing the challenges they had and reveals how Lokalise helped to overcome them. In about 8 months, they have completely moved from an obsolete Excel-based localization process to a lightweight and convenient solution using the Essential plan.

Branching by using tags and separate projects

Introduction to project branching

Modern software development involves the use of source code repositories. Once there is a repository, there are branches to which developers commit different changes in their code. Usually changes happen on multiple branches at the same time. As a result, the language files or localization files used in software localization may differ from branch to branch as well. This is when you start to think about how to employ branching in your localization processes.

We will be adding Project branching to Lokalise by Q2 2019, mimicking how branching works in source code repositories.

In anticipation of the update there are two possible workarounds, depending on the degree of differences among branches. If differences are big, it makes sense to create a separate project for every branch. On the contrary, with hotfix/feature branches, where the differences are minor, the approach which we recommend is to use tags in order to split keys by branches.

In this article we will focus on how to use tags working with different repo branches.

Localization of Phoenix Applications

In one of the previous tutorials we have discussed how to introduce support for I18n into Rails apps. Today we will continue covering back-end frameworks and talk about localization of Phoenix applications with the help of Gettext. You might not have heard about Phoenix before, so let me say a couple of words about it. This is a server-side MVC framework written in Elixir, which is a functional programming language working on Erlang virtual machine. The framework itself is quite young but still it is very promising thanks to the Erlang’s and Elixir’s features. It is very fast, scalable, and concurrency-oriented which is really important for heavy loaded applications.

Localization: 5 focus points

Going global

So, you’ve decided to go global.

All that is left to do is just localize the interface and then you are all set. At first glance, it might seem that translating a bunch of sentences is something very easy and intuitive. Yet, localization is quite a complex process and it has many challenges.

You might say, hey, this is no rocket science; but sometimes even people having experience in this area are unaware of certain pitfalls. You gain experience by learning from your own mistakes and it may come at a high price. Or, you can take preventive measures. Do a bit of investigation first.

In this article, we shall have a look at several aspects that deserve special attention when localizing your project.