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: http://www.getlocalization.com/library/api/get-localization-translate-api/

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

Simple Python command-line client for Get Localization

GLToolkit is very trivial command-line client that gives you opportunity to download/upload localization files from command-line. This is especially useful when you integrate e.g. uploading of master strings with your build/SCM commit process. This means that you’ve always up-to-date master strings in Get Localization server.

Installation

Download installation file from Google Code

Additionally you can checkout gltoolkit project from Google Code with this command:

hg clone https://gltoolkit.googlecode.com/hg/ gltoolkit

Usage

Upload your project master strings:

pygl.py upload localizationfile.po project-name master [component-name] --username=gluser --password=glpass

Upload specific language files:

pygl.py upload localizationfile_fr.po project-name fr [component-name] --username=gluser --password=glpass
(replace fr with any IANA code)


Download language files:
pygl.py get project-name fr --username=gluser --password=glpass
(replace fr with any IANA code)

Dynamic Localization in JavaScript

Update: Get Localization for Websites is a dynamic JavaScript library / service that keeps your website translated. 

Eli Grey released week ago a great library for localizing JavaScript code. Today, we want to support this great library by providing support for it.

Check out the demo. It is same demo as in Eli’s site but with one change (in addition to the language selection) that we provide a compatible JavaScript file that works with l10n.js so basically this is enough:

http://www.getlocalization.com/api/js/localizations/?product=L10NDemo

This allows translators and developers to manage translations in the Get Localization service. L10NDemo is a public project so you can freely participate in translating it into your language in the Get Localization editor.

Get Localization is free for OSS developers and we also have premium plans offering additional features for professional software development projects. We are also open for feedback so let us hear from you.

Our API documentation is now available

One of our products GoogaSync is a tool for synchronizing Symbian phone with Google Calendar. It’s a commercial application and revenue model is license based, $22.90 per license. We have now used Get Localization and the project has gathered quite a lot of interests. There is now translation work going on in over 20 languages.

With GoogaSync we are using dynamically our API’s directly from the client application. Instead of building language variations into the application, we let users to select and download the language from Get Localization servers. This basically brings lot of benefits for us and for our users. We don’t even think about translations or which languages we have available when we sign our code and release the newest version. That is huge time saver as we don’t have to fiddle with translations in every release. Users will get always most current translation from our server. Second point is that users who are translating application for you, can test the translation right away in real application context.

Our API implementation for Symbian is available in our GLToolkit project at Google Code: http://code.google.com/p/gltoolkit/. It contains a simple dialog based UI and new localization system that allows real-time translations. Using that should be fairly simple through CLocEnv interface. I’ll blog how to use it later.

API documentation itself can be found from following URL: http://support.getlocalization.com/entries/136183-api/