Skip to content →

Lokalise Blog Posts

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 Q1 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.

Rails Internationalization (i18n): The Complete Guide

Ruby on Rails i18n

In this article you are going to learn how to translate your Rails application into multiple languages, work with translations, localize datetime, and switch locales. We are going to see all these aspects in action by creating a sample application and enhancing it step by step. By the end of the article you will have all the necessary knowledge to start implementing these concepts in real projects.

August 2018: Bitbucket, QA widget, TM leverage, etc.

Throughout this summer, you should have felt the increased speed of both the API and web of Lokalise. We’ve refactored and optimized the backend and some of the functions, but also added new features which we list below. Please click on the links which interest you most. Remember, there’s always vote.lokalise.co for you to request features which you might be missing or vote for existing requests you’d like to prioritize.

Screenshot Editor 2.0

Localization workflow: best practices

Introduction

In the localization of any software including websites and web apps, mobile apps, games, IoT and standalone software, there is no continuous, logical document similar to articles and books. Instead, there are hundreds or thousands of words/phrases which by default do not carry implicit context and quite often are simply impossible to translate without knowing some background information. For example, take English words like go, pool, mine, draft — depending on the situation, they have completely different meaning. This is one of the many reasons why a modern product team should consider using a professional translation management system (TMS) instead of translating localization files straightaway or even worse sending Microsoft Excel/Google Docs sheets to translators.