One main point of difference for our translation and localization management system is that the user interface is uncluttered. Along the years, we’ve been stubborn to keep our UI easy to use for everyone, especially newbies. This meant making obvious only the most essential tools for translation and localization management, while keeping other powerful, more specialized tools on the discrete side.
Here we list a few of our top features that you may or may not be using in your localization project. If you’re not using them, we encourage you to give them a go. We’ve heard they make a great difference.
We built the Tagging System to help you keep strings grouped in your localization project.
Since we don’t store the files you use on import, but parse them to get the language data and store that only in our database, it’s important to know which strings came from where, in case you’re working with multiple source files.
Tags work perfectly for this case when you use them on import. But you can use them as custom filters too, and also mark your terms with tags in the interface, after import.
The best thing about tags? They are supported by the API and by the integrations with GitHub, Bitbucket, GitLab and Azure DevOps.
At POEditor, we offer plenty of ways to keep yourself updated about the status of your localization projects. Polling the API over and over, however, is not always the most efficient way to go around this.
Using Callbacks is a “don’t call us, we’ll call you” kind of process.
Basically, what Callbacks do is fire a request to an endpoint specified by you every time an event is triggered. Events include: language is completely translated, language is completely proofread and so on.
Now, with this information you can get the gears going. If you use a code hosting service integration, you will probably want to push the updated language file to your repository. You can easily do that from the UI by selecting the language and clicking on the Export option. OR you can do this automatically by calling a webhook.
From time to time, someone sets their (mobile) app to read language files directly from the POEditor API.
Subsequently, for every language update made in POEditor, even for the smallest typo or text change, an update is pushed to their app. At a first glance, it’s a great idea. Users will always have the latest language version. It becomes unnecessary to deploy new versions of the code/binary/app every time a new translation is added or changed. Also, errors are corrected quickly and spread instantly to the user base.
As attractive as the benefits of reading language files from an API may appear, there are issues with this approach. Some of them might even kill your app or you users’ experience with it.
Some of the pitfalls of loading language files to your mobile app from an API are:
POEditor users have multiple options for translating their software strings. They can bring their own translators, crowdsource translations using public projects, use machine translation engines, or even opt for third party human translation services. The latter feature is provided in partnership with well-reputed human translation platforms in the industry.
Until recently, as a POEditor user, you had to access each localization project to order human translations for it. And you had to repeat this process for each language. Because our users made us aware they wish to accelerate this part of their workflow, we’ve made some small changes.
What’s new with the human translation order process
In essence, you can now place orders for any project in the same page, and can order as many translations as you want, at the same time.
We can trace the idea of Machine Translation back to the 17th century, in the work of René Descartes. But it’s the 1970s which saw Machine Translation used for its actual purpose, initially in institutions like the European Commission, and later at big corporations. The advent of the Internet sped up the evolution of MT significantly and resulted in advanced technologies like today’s Statistical Machine Translation.
In software localization, we can use Machine Translation (or Automatic Translation) in a number of processes.
The online localization platform POEditor is free to use to translate software projects collaboratively in the following circumstances:
With Free Accounts
If you register to the POEditor, you get an account with a Free plan by default. The free account can accomodate software localization projects summing up to 1000 strings, which is usually enough to translate a small app or a WordPress theme into a few languages.
Also, you can use your free account to contribute without any limitation to localization projects owned by other users. The strings you translate for others are counted against their account.
Free plans, like all the other POEditor plans, can host an unlimited number of projects, languages and contributors. But, unlike accounts with paid plans, free accounts don’t come with a Translation Memory feature. Continue reading →
At POEditor, everyone in your localization team can find tools to increase productivity and simplify their part of the job. Below, I present some main features our localization management platform offers to improve automation.
Whether you’re translating something with a few strings, like a theme or an app, or dealing with something with a zillion strings, like a big website, there’s one thing that will always come in handy to the localization manager: statistics.
Statistics can be helpful for many things, among which evaluating the general translation progress of the software localization project and calculating fees for translators.
The POEditor localization management platform comes with two categories of stats: for project owners and administrators, and for contributors.
What stats pages look like
At the top of every Statistics page, some general information about the localization project is available, such as the project name, the amount of terms in it, and the total of words and characters these terms sum up. Some users can see more information in this area, as a result of their role in the localization project and the Stats page they are on. Continue reading →
The History module is one of the features that makes translating software strings with the POEditor localization management platform a safe and easy process. What the History module does is store translations that are one hour old in a database, so that they can later be recovered individually (with the History link), or in bulk, for a particular language (using the Recover from history feature). Below we will describe how the History module works.
Consulting previous translation versions for individual terms
In any Languge page, you can find History links next to each previously translated string (remember – the translations must’ve been one hour old to be recorded). If you click on one of these links, you will see all the translations that have been made in that language for the corresponding term, as well as who made the translation and when. Continue reading →
If you want to translate an app that uses language files such as .strings, .xliff, .resx, .xml or .properties with the software localization management platform POEditor, it’s very likely your localization process will be a little different than if you were using any of the other supported language files. This is because these language files contain labels.