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.
As a developer/localization manager/someone else handling a labels-based project with POEditor, you will start your software localization process by importing strings from a language file and setting a Default Reference Language.
With POEditor’s localization plugin for WordPress, you can manage your WordPress language files between POEditor and WP, from within your WP dashboard. Download and install the POEditor WordPress translation plugin according to the instructions in the Installation tab. Then follow this step by step guide to set up your localization workflow.
How to manage the WordPress localization workflow
- Step 1: Go to your POEditor account, click on your username in the navigation bar and then go to Account Settings > API Access. Generate an API token and copy it to the POEditor plugin in your WordPress account, where it says POEditor API KEY. A page will be generated, with all the software localization projects in your POEditor account (if you have any) and your local WordPress language files.
- Step 2: Click on Create project in the POEditor plugin to start a new translation project. A corresponding project will be created in your account on the POEditor localization platform.
- Step 3: Add a language in the POEditor plugin to the newly created project, and then link a WordPress language file to it by clicking on Assign file.
- Step 4: Press Export to send the terms from your local WordPress language file (.po or .pot) to your project on the POEditor software localization platform.
To make a localization process faster, there are aspects of it that can be automated. Translation is one of these aspects and even though it has been proven in numerous instances that machine translation cannot compare to human translation, there exists what is called Translation Memory, which combines the human touch with machine power to simplify the translator’s work.
How the POEditor Translation Memory works
Each time a user translates a term, the translation gets stored immediately in the TM database. The TM database stores one translation per user for each term, which gets updated each time the user edits it in the interface. In case different users add different translations for the same term, they all get stored in the Translation Memory database. If there is more than one translation variant for a term in the Translation Memory, the TM will generate a list of suggestion, so the users can select the most appropriate one. The TM will always list the translations according to how many times they were used.
Most of the time, the roles in a software localization workflow are very specialized, divided according to specific activities and tasks. Our experience with the localization industry has revealed that it’s not rare for companies to contact an agency to manage their software localization process. So they outsource it, but does the same apply for the payment for the localization services? Sometimes, even if a company does use an in-house localization team, the payment for the localization tools used in the translation process will still be managed by an Accounting Department. As you can see, the person with strings may not also be the one with the money.
So, to make sure the translation workflow suffers no disruption, we’ve come up with a payment management system that makes life easy for the person in charge of the financial aspect of the localization process.
Lately, some users have been asking for a way to automate the synchronization between the POEditor localization platform and GitHub/Bitbucket repositories. Because we want to make them happy, we found a way to do this – webhooks. These “user-defined HTTP callbacks” can be used to trigger a certain sync in your repos. They can be called from anywhere, and can be maintained, modified and managed by any third-party users.
Preparing the webhook
To make use of a webhook, you first need to create a webhook URL. Find an example for GitHub here, and one for Bitbucket here.
After creating the webhook, you can add it to a GitHub or Bitbucket account so that events in the repos trigger terms (and translations) updates in a POEditor project.
Using webhooks with Bitbucket
To add a webhook to a Bitbucket account, just log on to it, go to Settings → Hooks, and select “POST” from the “Select a hook” dropdown menu. Then click on “Add hook” and introduce the webhook URL in the empty field. Whenever the repository changes, the webhook will be triggered to sync between the assigned language/project on POEditor and the file in the repo.
Using webhooks with Github
Adding a webhook to GitHub is also easy. Go to the account, click on Settings → Webhooks & Services → Add webhook, and add the webhook URL to the “Payload URL” field. Unlike in the case of Bitbucket webhooks, you can pick what kind of event(s) you want to trigger the webhook. It can be just the push event, individual events, or everything (any change in the repo).
So that’s that. The POEditor GitHub integration and Bitbucket integration are now faster than ever, because you have the choice to automatically send the updates in the repos to your localization projects managed on POEditor.
Update July 2015: It is now possible to use webhooks to export terms and translations from your POEditor localization project to your connected GitHub account. Please note that the export option can be triggered from anywhere, except GitHub.
App localization can get tricky at times, and one frequent reason for this is labels. Labels are alphanumeric identifiers and, as useful as they may be inside software, they are impossible to read by translators. They can be found in various file types, among which POEditor supports Windows .resx & .resw, iOS .strings, Java .properties and Gettext .po files. In a language page, terms consisting in labels look like this:
As a “decrypting” solution for this comes the almighty Reference Language feature. A Reference Language helps contributors with their translation work by letting them see, above each original term (which is a label), a term in another language existing in the project.
How to set a (Default) Reference Language for a Localization Project
First of all, after creating the project, a project owner (or an administrator) needs to create a language that corresponds to one that’s already in the user’s software. Then it’s time to import into the project both the terms (labels) and the translations in the created language. The project owner or the administrator can set a Default Reference Language for everyone from Project Settings > Edit Project Details, or they can grant contributors with Read Access to All Languages so they can choose their own Reference Language (which will override de Default Reference Language, if one is set).
As previously mentioned, contributors can set their own Reference Language. Once they have Read Access to All Languages, all they need to do is to click in the language page on the Set Reference Language button in the right-hand Options Menu and pick their preferred language from the project.
In the end, after choosing a Reference Language or a Default Reference Language, language pages will show the terms something like in this picture on the right.
As a final observation, note that you should be careful with the Automatic Translation feature while working on projects containing labels. You will want to make sure that you select as source language anything but the project terms. There you have it! Now that you know about Reference Language, translating apps with POEditor should be as easy as pie!
Today we will show you how easy it is to use POEditor’s tagging system among your localization projects. Tags are a simple solution for organizing terms, and they come in handy both during translation and on export. Some situations in which you would care to make use of tags would be:
- When you want to manage localization projects with similar translations in the same POEditor translation project.
- When translating terms from several platforms within the same project. With tags, you can keep track of each platform’s set of terms so you can export them accordingly when the translations are ready.
- When having different versions of the same terms within a project. Tags will help you follow each version, to translate them selectively and export them as such.
How to set tags in POEditor
There are two ways in which you can tag terms in a localization project:
- On import
While on a project page, go to Import Terms > Advanced Options. After selecting a language file, you can add tags for the terms to be imported. You can add tags to all the terms in the file, to the new terms (which are in the file to be imported and not in the project), or to the obsolete ones (which are in the project but not in the file to be imported).
- During translation
While on a project page, go to View or Add terms and select the terms you want to tag by checking the boxes on their left. In the dropdown menu at the bottom of the page, choose Add Tags to Selection and write the name of the tag in the box next to the menu. You can use an already existing tag or add a new one.
Filtering by tags
Again, two situations:
- During translation
To clearly view all the terms in a certain category on a language page, just select the desired tag from the top left drop-down menu and have your set of terms exclusively displayed.
- On export
While on a language page, click on Export > Advanced Options and select the filters you want to apply for export. The result will be a file containing only the pairs of terms and translations which have been tagged with the selected tag(s).
We have seen tags used in many creative ways by our users, so by no means should you limit yourselves to the examples given in this article. Whether you want to sort your terms by date, platform or anything else, using tags will help you neatly organize your sets of terms for a smooth localization process.
Update February 2015: On import, if you choose to overwrite the translations, you now have available the option of tagging the terms which have had their translations modified.