How to use Webhooks to automate the sync with GitHub/Bitbucket

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.

POEditor autumn harvest

The month of October is nearing its end, and by looking and the amount of updates we have gathered during it, we can proudly say that our dev team’s hard work has been quite fruitful.

Because we don’t want to bore you with very technical stuff, we will limit this communication to presenting the most obvious changes to improve your localization workflow.

Control exports to GitHub

You will notice that in the Github projects page, you now have the following options to filter your exports: all, translated/untranslated, fuzzy/not fuzzy, automatic/not automatic, proofread/not proofread. Once one of these settings is chosen, it is saved and applied for all the Github projects. In the case of multiple files, you will also notice that you are now able to tell where you are with the export, because a progress bar will be visible while the export to Github takes place.

Mass toggle of fuzzy or proofread translations

For an easier time managing translations, the mass toggle option was a must. You can now perform the action of mass toggling fuzzy translations or mass toggling proofread translations by accessing the dropwdown list at the bottom of any language page and clicking “Go”.

Recover translations from History

We have to give a big hand to those of you who suggested this feature, because it will be a blessing to many of your fellow users. Basically, what this feature does is detect if there are translations in the History of an untranslated term. In case there are, you can tell POEditor to recover from History the last one recorded. Please note that a translation gets saved in History only after one hour has gone by from when it was edited.

There are a lot of nice enhancements that we have on our roadmap, so make sure you keep an eye on us so you don’t miss out on any of the good news.

Happy 2 year anniversary to us!

We are proud to let you know that on the 2nd of August, two years ago, the project that came to be the POEditor you know today first saw the light of the Internet. Although we couldn’t imagine how far we’d get back then, we believe now that our localization platform has grown into a beautiful piece of software that is valuable to many people all over the globe. Along the way, we’ve added new & useful features and updates, always taking into account your opinions for improvement and other requests, making it our assumed duty to deliver to you in the shortest amount of time possible. This is the kind of relationship we will continue cultivating with our users.

A big thank you to everybody for supporting us and for using our product. We hope to keep on growing together while you enjoy POEditor for years and years to come.

Keep the #l10n roaring!

Proofreading translations in a localization project

When it comes to the translation part of a localization process, one of the most important aspects is proofreading the translations. Before exporting the localized strings back to your website, app or game, you will want to make sure they’ve been well adapted to their context and are, indeed, good to go. What’s the best way to achieve this? Assigning some proofreaders to your software localization project, of course.

In this post we will show you how our most recently implemented feature works. As usual, the POEditor translation interface makes things really simple.

POEditor localization platform - Project SettingsAs we did not want to clutter the localization workspace for anyone, to make use of the new proofreading feature, you will have to enable it on your project first. Just go to Project Settings and in Advanced Settings, set Enable Proofreading to “Yes”.

Once proofreading is enabled, a button will appear on the Project Settings page, which will make it possible for owners and admins to assign new proofreaders to the project from the current list of contributors. Any contributor added as a proofreader will be able to proofread the translations made in any of the languages he is assigned to. If the contributor is removed from the contributor list, he will also be removed as proofreader from the localization project.

The proofreading flag is only visible to proofreaders. In spite of this, if a POEditor localization platform - Proofreadingcontributor tries to edit a translation that has already been proofread, a notification will appear to warn that proofreading will be reset if he or she proceeds with the editing.

As it would be expected, the proofreading option, once activated, comes with a new couple of filters to sort translations by: “Proofread” and “Not proofread”. These can be used both while translating and on export.

As the majority of our most recent localization features, proofreading was added as a result of popular demand. Keeping the translation interface neat and simple remains our core principle, and this is why we hesitated a bit to develop this option, but the conclusion we came to, of making it functional only for those who choose to use it, should make everyone using the POEditor localization platform happy. Any suggestions are welcome.

Localization File Formats Support by POEditor

We recently made a list of all the formats we support for localization projects, and gave a few explanations for each of them, linked to POEditor’s expectations. We take the chance to clarify a question that keeps popping up in our mailbox: why do we not support certain formats?

The short answer is because of the perspective from which we’ve built the entire translation platform: we preferred to treat every localization job from a project point of view, and not as a mere file translation. For this reason, we need to be able to import every localization file format to the same list of terms and translations, so we can provide back to our users the same content, in the same format, flawlessly.

Taking this into consideration, and the fact that we don’t like to “partially support” language files, we’ve arrived at this list of main formats.

The current list of formats is not final, of course, and new additions will be adapted to this vision, so our users won’t get the feeling of getting too technical.

Have a look at our supported formats:
Gettext .po and .pot files, Excel .xls and .xlsx files, Android .xml files,  Apple .strings, Microsoft .resx and .resw files, Java .properties files, .json text files.

How to show the source language accross all languages

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:
POEditor localization managent platform - Labels (Language Page)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 ProjectPOEditor localization management platform - Set Default Reference Language

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. POEditor localization management platform - Set Reference LangaugeOnce 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 POEditor localization management platform - Language page (with Reference Language)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!

How to use tags in your localization projects

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:

  • Import FileOn 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).

  • Add tags in View TermsDuring 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:

  • Filter by tagsDuring 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.

  • Export by tagsOn 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.