Skip to content →

Lokalise Blog Posts

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.

May 2018: Screenshot filter, GitLab, DeepL and more

Do you want more from Lokalise? We’ve heard you, check below. Would you like to give your voice for anything that’s missing? Now you can add your feature asks and let others vote on our roadmap page. If not, as always, chat with us in the live in-web support.

Screenshot filter

Major upgrade to the screenshots feature! Now you can add tags to the screenshots to organize them into logical groups. Then you’ll be able to use the Screenshot filter button in the editor, in order to include only the keys linked to the selected screenshot groups. We’ve also added bulk actions to the Screenshots page.

March 2018: GitHub, proofreading and more

There are new features and improved existing functionality. Spend a couple of minutes scrolling through the text and get an idea of what is new in Lokalise.

GitHub two-way integration

For you, GitHub users, a new feature that lets you pull files from one or more of your GitHub repositories and create pull requests from Lokalise. You can find it among available integrations in their usual place, Project settings > Integrations. Learn more.