New Version of In-page Editor, Translate API and More

I’m proud to present a Get Localization June Release. It’s bigger than normally as it incorporates so many new features we’ve been cooking up for you guys. I’ll briefly introduce these features so you can get the idea what to expect. During coming days, we will provide videos and blog posts that cover these features more in detail.

This release is all about website translation. We’ve been extremely good in providing translation tools for mobile/app/client developers in the past but we felt that our offering for web developers was not that good. This is now changing as we introduce In-page Editor 2.0, a remarkable piece of technology that changes how websites are translated.

In-page Editor 2.0

We released our first prototype of In-page Editor last year June 23rd, almost exactly a year ago. We felt that there was huge potential in this technology but time just wasn’t right to go all-in with it. This is now changed, website translation is one of the key issues developers are struggling today and we want to help with that.

Insert code here

Previously our In-page editor was a bookmarklet (and it still is) but now in order to provide best possible user experience for translators we provide widget that helps you to incorporate In-page editor to your own site really easily.

It’s a small translate button in the left side of your website and clicking that allows you to start translating your site. So simple and easy. See for an example our company website and you can actually see how it works! (Some of the texts are using Cufón so they cannot be currently translated, shame on us!)

This is what you get after you click that Translate button. Editing work is happening in the page itself, here’s the screenshot of Wall Street Journal being translated to Finnish:

You can see right-away if the translation is breaking the layout or doesn’t fit to the context. After translation, the material is also available in our traditional editor as you can see from this screenshot:

With Or Without Internationalization Work

This means you can translate all the content, not just the ones that are internationalized by developers. You can upload your traditional localization files as well and translations are automatically placed to correct files while translation happens. If there’s no file available, those translations are placed in file called “Extras” and they can be then dealt with several ways, either adding the strings to original localization files or then accessing them using our new JavaScript API.

Here’s an example of Extras and PO file together:

Extras file contain all those strings that were translated with In-Page editor but were not found from django.po file.

Works with ALL Content Management Systems

You can translate all the content with In-page Editor. It works with WordPress, Sharepoint, Joomla, basically any CMS system in the market.

Get Localization Translate API

Get Localization Translate API is quite similar in architecture than famous Google Translate API. As you may know, Google Translate API is now deprecated and will move to paid model by the end of this year. API being really similar gives you an advantage to migrate easily from Google Translate API to Get Localization. Of course it won’t give you machine translation feature but it will give you an opportunity to translate your site really easily using crowdsourced or professional translators. This will definitely improve the readability and provide better experience for your users.

With Get Localization Translate API, you don’t need to use any i18n framework. You can simply use In-page editor to translate your site and with API, translations are available in similar fashion as using Google Translate API.

API documentation is available in our library:

Try them out, They Are Free!

We would love to hear some feedback, I know this is quite much to digest at once so we will provide videos and more information that will clarify these features in coming days. So please, send us your questions and feedback and we will try to answer them. All the features are live already today so you can try them yourself. You can find the instructions under your project “Settings” tab.  And just a friendly reminder that we reserve the right to limit your bandwidth if you go crazy so if you’re planning to use these with high traffic site, please contact us first to discuss about details.

We will also roll-out these new features to our Lingodesk product family as soon as possible. You can learn more about Lingodesk from our company website.

Software Internationalization for Dummies

I had discussion today in Twitter regarding software i18n (i18n is a short for internationalization, and it means there’s 18 characters between letter ‘i’ and letter ‘n’). I was trying to find some simple, straightforward link that explains what this word monster actually means but I wasn’t able to find it. So here it goes:

Software Internationalization is a process to separate content from code so that it can be localized. Almost all programming languages and environments provide some kind of framework to do this. There is some popular examples like JavaScript that doesn’t provide i18n support out of the box. However, most well known JavaScript libraries such as jQuery do have plugins that provide the support.

As an example, the iPhone i18n framework provide a way to use following “strings” files that are then accessed from the code:

"Hello World" = "Hello World";

When this is translated, file is copied and typically saved under the corresponding language folder, in this example it would be Finnish strings file:

"Hello World" = "Heippa maailma";

Here we can see that “Hello World” is now translated to Finnish. Based on the language you’re using in your iPhone, the correct file is automatically loaded. It means that when in actual application code we use string “Hello World”, it will get automatically replaced with Finnish translation from the Finnish strings file (if your iPhone is in Finnish, of course).

The benefit of this whole process is that we don’t have to change the code when application goes to localization phase. Also in some cases, e.g. in HTML or other declarative languages we don’t have to duplicate the design or behavior to each localization variant as the languages reside in different files.

However, managing these i18n files will get tricky as soon as you have to deal with multiple languages, hundreds of strings and different character sets, file formats and versions. That’s why there’s new breed of software localization platforms that provide version management, editor, collaborative tools and API’s to manage these files more easily. You can learn more from Get Localization and this blog how to simplify the localization process as well.

If you wan’t to learn more? Please read the following blog post, it will give you more insights about the topic: 10 Internationalization tips for developers – I18N checklist

Translation Memory is Dead, Long Live Translation Memory!

I’ve been following this debate about translation memories. Are they dead or not? To me it sounded quite confusing until I understood what people actually meant when they talked about “Translation memory”. If you have followed this blog, you know that our background is in software development. We create a product for software developers to use, “from developers to developers” as we say.

So there are now respected industry veterans telling to the world that “translation memory should be like a version control system for developers!”. I have to say that I love this statement and I agree with it fully. Actually I wrote about that over a year ago in this very same blog in almost exactly same wording.

But I would like to propose one thing: Please stop calling it “Translation memory”. Translation memory is just a feature. It’s a nice feature in the editor along with other nice features but it just doesn’t describe the behaviour of current socially enabled localisation platforms like that actually already contains a version management system. It’s not even the core thing anymore! Call it anything else, I don’t care but just do not call it “Translation memory”.

So in that sense, yes TM alone is definitely dead but technically TM is still a great feature, a little helper that makes translators day a bit easier.

Thank you for considering!

Covering Latest Get Localization Release

We’ve been extremely busy implementing a bunch of new features lately. Or actually they’ve been out already week or so but now it is good time to cover all of them.

Project feed

Project feed is a great new addition to service. Actually we’ve asked ourselves why it hasn’t been here before. It is pretty similar to Facebook news feed but project specific. It means everybody can see easily what is happening in the project. Here’s example what is happening in AppUpdateNotifier project:

Cool huh? It’s an awesome addition and will make managing projects and translations much more fun!


This is a second feature we thought that we are really late with, but better late than never! It is Statistics and we’ve even reserved own tab for them. For example we’ve added list of contributors, you can get them for whole project or just for single language. Here for example we’ve top translators for German from GoogaSync project.

We are now in the works for providing new stats and also improving current offering.


Discussion is now back in Editor as well. We had comments in previous editor but now they are back in our new version as well. Here’s screenshot how it looks:

And much more…

We’ve lots of other smaller improvements in as well. This also means that we are starting to be feature complete in a sense that we can soon finally come out of beta. This will hopefully happen soon. So stay tuned and let us know what you think!