About Helmut

CEO and founder of lingohub

Github love and integration

Posted on April 3, 2013 by Helmut

As a developer you have to love Github (for its simplicity, its flexibility and how it changed the web). That is why Lingohub has provided a Github integration from the beginning. We just released a small update to this integration and we noticed our public documentation doesn’t reflect all the possibilities yet. So here is how you can authenticate through Github and get the most out of connecting your Github repository with Lingohub:

Github integration step I: Authenticate with Github

Right now you can use six different authentication providers to sign up or sign in: Google, Twitter, Facebook, LinkedIn, Xing … and Github. In case you already have a Lingohub account and still want to use your Github account, you can simply connect both. The first authentication redirects you to your Github account and asks if you give Lingohub access to your Github account. Here I want to mention two things: 1. We require read/write access to your repositories and to your account information. Sometimes users ask us why we need access to repositories for authentication. We don’t need or use this information for the sign-in process, but for other integrations like automatic synchronization of resource files, 2. You can always disconnect Lingohub from your Github account, ending the integration.

Github integration step II: Connect project with Github repository

You can connect your Lingohub project to any of your Github repositories. This enables you to automatically synchronize resource files with your code base without the extra manual work. If you haven’t authenticated with Github yet, you will be asked to (see ‘Authenticate with Github’) at this point. Once connected, you can choose your repository and select a specific branch which you want to synchronize with. In order to get the synchronization working you must specify the files Lingohub should watch with a regular expression, all other files will be ignored. From now on, at every change in that branch, Lingohub looks if a resource file changed and when needed synchronizes the translation texts. If you ever want to prompt a manual synchronization, go to imports and click the ‘start synchronization’ button: Our whole Lingohub translation workflow extensively uses Github integration. I encourage you to give it a try and see for yourself how it simplifies the process enormously. How integrating GIT into your localization workflow works in detail, I also outlined in a previous blogpost that I highly recommend, not only if you’re new to this.

Integrating internationalization in a GIT workflow

Posted on March 12, 2013 by Helmut

Several of our customers asked us to support branches (from versioning systems like GIT or SVN) in lingohub. The reasoning behind this is, that i18n resources and their according associations often belong to one or more branches, and then you should be able to merge them (GIT-like) with others. One of my beliefs is that a good product owner must be very skeptical of “feature requests” and instead look for the problems and/or the desired benefits behind such a request. In this case, a faster release cycle including translated text was of the essence – and is in fact also very dear to lingohub’s mission. Once we narrowed that down, we focused on some of the circumstances and on common practices of the current situation determining the agility of your release cycle:

Developers usually text themselves (in English, or their native language, or both).
Text changes during the development of a feature, hence a final version often exists only at the very end of a development cycle.
Different language implementations are seldom tested already during development.
Very often, a review process for the texting and other copywriting (in source and target languages) is not in place.

Based on this feedback, we started working on tool support to allow managing a faster release cycle for your translation. Basically, our main goal is to minimize the time it takes to translate text *without* sacrificing the quality. We already released a couple of features for that purpose: our lingohub CLI client for scripted automation, and lingoChecks for verification – but this is just the start, there will be more announcements in the upcoming weeks. However, this blog post is about a working solution for today. What’s a best practice for integrating internationalization? Let me outline for you how we translate lingohub:

For every feature, we create a feature branch named after the issue ID (we use JIRA, so in our case lwe-xx). Finished features are merged into our master branch (all specs green), from there it takes another merge into the production branch to actually get released. Some leave out the production branch, but this is a typical GIT workflow. However, our i18n branch is special. This is the branch that gets synchronized with lingohub. Every time someone pushes something to the i18n branch, lingohub checks for new or updated texts. Having a specific branch for internationalization allows us to specify the moment when texts are considered finished. This can be during any stage of feature development (specs can be red or the feature is just a mock up). It decouples the development cycle from the translation cycle. For every release (production branch), we then synchronize our resource files by script via lingohub’s REST API: Deployment and retrieval of the texts is one step with one shell command.

Since an image is worth a 1000 words, here is a diagram describing the workflow (without production branch since it is not necessary):

Development in feature branch, merge with i18n branch once the texts are ready.
Automatic synchronization with lingohub (we use lingohub’s Github integration, but you can also use git hooks).
Feature development is finished and merged into master (or any other ‘production’ branch).
Before the release of the feature, the texts are synchronized with lingohub.

This is the workflow we use for translating our texts. Since ‘eating your own dogfood’ is the best way to actually see what’s working and what not, we know the strengths and weaknesses of this approach. What we really like about this workflow is how easy it can be integrated in any software development process. Nevertheless, there are still some steps and issues we think can be improved to help you: better feedback on translation texts, faster translations, communication integration and more checks.

This is just one way to use lingohub. With our API you can use the service as you like. Please check out our developer and API documentation. Don’t hesitate to contact me (helmut@lingohub.com) if you are using other approaches or if you are having questions. We welcome your feedback and work especially close with our customers on identifying other areas where we can make localization an even better experience for you.

Introducing “Export settings” for resource files

Posted on February 18, 2013 by Helmut

Programming holds a lot of pitfalls, character encodings and handling time are just two examples. Many of them exist only because of historical reasons, but still have to be handled today. Dealing with many different frameworks and programming languages means dealing with different requirements as well. At lingohub we always prefer a standard solution, but we know that sometimes you do not have a choice. In your projects, one step of your work process is actually exporting the resource files of your translation languages when done. Here is where encoding becomes important again. For example, the predefined standard encoding for properties files is ISO-8859-1, however, some frameworks require UTF-8 for properties files. As a developer you do not have much of a choice in such a situation, so we decided to give you the best of both worlds. We use good standard settings for exporting resource files, but give you the option to change it the way you like:

Blank content handling

Decide what lingohub should do when the content of a phrase is empty. The three options are:

Skip the phrases with the blank content.
Keep the phrase with the blank content in the export.
Use the source language content instead of the blank content.

Encoding

Currently lingohub supports four different export encodings:

UTF-8
UTF-16LE
ISO8859-1
ISO8859-1 with character escaping

Just to be clear, this only affects export settings and not import. The imported files encoding will be automatically determined by the lingohub system.

All these settings are created based on our customer feedback. If you require other options as well, don’t hesitate to contact us.

Meet lingohub in Berlin

Posted on February 4, 2013 by Helmut

Brandenburg Gate by Daniel Foster (http://www.flickr.com/photos/danielfoster/) CC-BY-SA 2.0 (attribution share-alike)

Photo credit: Brandenburg Gate by Daniel Foster CC-BY-SA 2.0 (attribution share-alike)

Berlin is a buzzing start-up capital these days (read “Ich bin ein Berliner” on TheNextWeb or this overview of the Startup Ecosystem in Berlin), and since Sebastian is our team member working from Berlin, and the Berlin International Film Festival is about to start soon, lingohub decided to work from the German capital for an entire week and get a sense of what Berlin innovators are up to.

If you’re in Berlin, this is your chance to meet us. Whether you’re interested in lingohub in general, or the localization business and trends, or you’re in fact a translator, or an app developer, or investor – it’s coffee time! Let us know if you’re around the week of February 11-15, and we’ll meet up.

We’ll also be at the betahaus’ BetaBreakfast on Thursday the 14th (link to event page), if you’re there, say hello. If you know of any cool events you think we should attend that week, we’re looking forward to hearing from you as well. Send us an email or hit us up on the social networks.

Introducing “lingoChecks”

Posted on January 18, 2013 by Helmut

We all know that translating is a challenging job. It is hard to maintain context of the translations, you have to consider design aspects (e.g. length of the translation in dialog boxes), finding the right tone can be tricky, and taking care of technical aspects (e.g. placeholders) can be a tedious task at times.

At lingohub we are constantly thinking about how we can make the (working) life of a translator easier. lingoChecks is a feature that every translator will love. With lingoChecks we are improving our editor to display the “health” of a translation to the translator. Essential information can now be passed on to be displayed in the editing environment, increasing the degree of context a translator has to his or her disposal when working on a job.

Currently we support the following types of “checks”, as we call them, that a project owner can define:

min/max: These checks are pretty simple, they verify the number of characters of a translation. It is possible to define absolute numbers (e.g. min: 45), absolute offset (e.g. min: -5) and percentage offset (e.g. min: %5). Such checks are especially useful on Mobile Devices where the space is often limited. A translator will then know, for example, that a certain translation text should not exceed a certain length, otherwise it will not look pretty on the finished product.
placeholder: Many translations contain so called “placeholders”. These, as the name suggests, are replaced with dynamic content at runtime (of the app or website). A simple example would be: “Hello %{username}”. In this case username could be replaced with First Name, e.g. Claudia, and would result in “Hello Claudia”. The corresponding German translation would be: “Hallo %{username}” The problem here is, that placeholders have a different syntax depending on the file format and they must be exactly the same as in the source language. With lingoChecks we ensure that all placeholders are valid and occur in all languages. This decreases the occurrence of post-translation bugs and increases both quality as well as consistency.
terms: This check is about special terms you always want to be the same across all languages, and they work as exceptions. An example would be the name/term “lingohub”. This term should be all lower case and should be used in all languages (and not translated) identically. You can define such terms and make sure that the translators know that these terms should be exactly as defined. In most cases those are names, fixed expressions or slogans that need to remain the same.

lingoChecks can be enabled on a project level to set default, but can be overridden on a translation level. As a project owner you will find the settings under project settings and under the translation detail view.
The only lingoCheck that is enabled per default is the placeholder, others have to be manually activated.

Lingohub

Software localization for developers & translators, best practice for mobile app translation

Author Archives: Helmut