By transifex

Inactive projects you said?

By deleting those projects, all their settings are gone once and for all. Just imagine having to re-configure automatic updates for hundreds of source files that were once properly configured.

By keeping them, the projects’ contribution to the overall word count of the organization is a burden – and we know that because many of you have told us so.

From now on, organization administrators can take advantage of the new feature we introduce today and instead of deleting an inactive project, they can archive it. Let’s see what this actually means:

The project goes into a freeze mode. Users can see it’s there but cannot interact with it.

Its contribution to the total word count of the organization is reduced by 75%. To put that percentage into perspective, assume your organization is on the Plus plan, with a limit of 50K words, and two projects: a Big one (wordcount: 40K) and a Small one (wordcount: 7K). If the Big one is inactive and you archive it, you’ll get an “extra” 30K words (40K * 25% = 10K contributing to the word count) and give Small the opportunity to grow without needing to upgrade to a greater plan.

The settings of the project remain intact. At any given moment, you can restore an archived project and get its fully functional version from the past. Restored projects will contribute fully to your organization’s word count.

You can archive an inactive project – or restore an archived one – by visiting the archive settings of an organization (Organization > Settings > Projects Archive):

Archive projects

Transifex lets you know how many reserved words will be made available again if you archive a specific projects:

Archive projects

So, we’ll ask you one more time: You said you have inactive projects? Then what are you waiting for?

Introducing Team Managers

A few weeks ago we launched Teams, a major update which centralized the organization and management of your collaborators in Transifex. This allowed you to create independent translation teams and reuse them across any number of projects.

Today we’re introducing a new role in each team: Team Managers. These users have responsibility over the team, along with all its languages and members. This is especially useful when managing large organizations with many collaborators.

Team Managers have the privileges of translators and reviewers. Additionally, they can:

  • Add / delete languages in a team
  • Add / delete projects the team manages
  • Approve / deny requests to join the team
  • Approve / deny requests for new languages
  • Invite people to the team
  • Change the roles of the members within the team (including assigning users as coordinators)

If you’re curious about user roles in Transifex, you can read more in our documentation.

Organization administrators and existing Team Managers can add new Managers. To do so, visit the Teams tab in your Organization Dashboard and click on the Gear icon next to a team. There, you can put in the e-mail address or username of the person you want to invite/add as a manager.

Team Managers

Use Cases

  • When crowdsourcing translations, org admins are often overwhelmed by the number of requests to join a team or add new languages. Using Team Managers can help distribute the load among more people.
  • If you want your project maintainers to be able to add new languages to their projects, simply add them as team managers. Problem solved!

Give Team Managers a try and leave your comments here or at our lovely support center. 🙂

Group Your Resources Together with Categories

Happy New Year and best wishes for 2014, everyone!

We hope that you all had wonderful holidays full of joy and warmth.

Our team had its yearly meetup in Paris and, among other things planned, it’s now time to welcome the new year by announcing the replacement of Releases with Categories.

A releases was a group of resources. As such, you could include the same resource in more than just one group, and whenever some translation changed, all the releases would be updated accordingly.

Categories came to take their place, keeping this functionality along with an updated behavior as they are a kind of “labels” applied to a resource. For projects with many resources, categories are like an extra level of hierarchy. By grouping certain resources, every user is able to browse the ones he is interested in.

You can organize project resources into categories via the “Edit resource” page (Project > Resources > Resource > Settings). There can be multiple categories for each resource, as shown below, that group resources according to its content, context, or whatever differentiates it from other resources.

resource categories

You are able to view your resources categorized in all pages that show them and treat them accordingly.  What’s more, resources can be easily filtered by to existing categories.

The categories field is also accessible via our API.

resource categories filter

As simple as that.

More goodies are coming, stay tuned!

Github – Transifex Integration

Our friends at Strava have proven once more that great brains can come with brawn. Txgh, which they have recently open sourced under an Apache license, is a neat little Sinatra server that serves as a bridge between Transifex and Github.

It ensures you always have up-to-date translations in Github, and that the source text in your Transifex resources are kept up-to-date with the text in Github.

Here’s how I set-it up, from scratch, in a few hours.

What you’ll need:

1) A free Amazon EC2 instance. I chose the basic free Amazon Linux AMI which should be enough. It comes with Ruby, Git and pretty much all you need. If you don’t want to use EC2, you can use any kind of server with a recent version of Ruby installed with the ability to receive and send HTTP API traffic from the internet.

2) Maintainer access to your Transifex project.

3) The ability to add Service Hooks to your Github repo.

Once you’ve got your EC2 instance, connect to it using ssh. You’ll do all your work from there. Take a note of its public DNS name, as you’ll need it later.

# Make sure you have all the build tools installed
sudo yum groupinstall "Development Tools"

# Install dependencies
sudo yum install -y gcc-c++ patch readline readline-devel zlib 
  zlib-devel libyaml-devel libffi-devel openssl-devel make bzip2 
  autoconf automake libtool bison iconv-devel
# Install RVM
bash -s stable < <(curl -s https://raw.github.com/wayneeseguin/rvm/master/binscripts/rvm-installer)
# Install Ruby
rvm install 1.9.3
# Install Bundler
gem install bundler --no-rdoc --no-ri
# clone txgh
git clone https://github.com/jsilland/txgh.git

# cd txgh

Now you will create the txgh config file. It’s a YAML file, which looks like this:

txgh:
    github:
       repos:
           <your/full/repo/name>:
                api_username: <your Github API username>
                api_token: <your Github API token>
                push_source_to: <transifex project slug>
   transifex:
        projects:
            <transifex project slug>:
                tx_config: "/path/to/.tx/config, see below if you do not have any"
                api_username: <Transifex API username>
                api_password: <Transifex API password>
                push_translations_to: <full/github/repo/name>
# edit txgh config file
vim config/txgh.yml
# paste the contents above and edit to fit your configuration

If your Transifex project currently uses the command line client, you probably have a Transifex config file checked into your repo. Its default location is under a .tx/ folder in the root of your git repo. If it doesn’t contain one, use this support article to create one, or use this template:

[main]
host = http://wpdev.transifex.com

[<transifex project slug>.<transifex resource slug>]
file_filter = ./Where/Translated/<lang>/Files.Are
source_file = ./Where/Source/Files.Are
source_lang = <source lang>
type = <FILETYPE>

Finally, start the server:

# install bundled gems
bundle install

# start the server
bundle exec rackup
Puma 2.5.1 starting...
* Min threads: 0, max threads: 16
* Environment: development
* Listening on tcp://0.0.0.0:9292

Now, you can keep the server running, and go configure the webhooks in Transifex and in Github:

How to configure webhooks in Github. You will want to point the new service hook you’ve created to:

http://<public DNS name>:9292/hooks/github

To configure your webhooks in Transifex, you will need to go to your project management page and point the webhook URL to:

http://<public DNS name>:9292/hooks/transifex

image

That’s it! While this starts the server in development mode in a free ec2 server, if you do any kind of larger scale development, you would probably want to run this on a more stable instance, in production mode, with appropriate monitoring. But once you’ve configured the webhooks, any change that makes a file be 100% translated in Transifex will trigger the server to push a new commit to Github with the updated translations files, and any change in Github to the source files will trigger the server to update the source content in Transifex.

Happy localizing!

Read Next: Eating Your Own Dog Food: Managing a Continuous Localization Project

Community Translation In The Real World

One thing our customers have recently been curious about, yet hesitant of trying, is to tap into their user community to translate their content.

Having been involved with such efforts, I can sympathise. It’s a daunting undertaking. Will it work? How do I make sure my community stays active? How do I deal with quality issues, or even detect them?

I also wanted to expand on my presentation at Localization World. Some interesting points were raised by the audience, and I wanted to share some of the issues we discussed and give those who were not present a chance to participate.

Why Use Community Translation?

While community translation programs are quite difficult to start, they are also incredibly gratifying: the ability to connect with your early users in a country is key if you want to win a market. As this TED video explains, you have to take care of your first followers if you want to start a movement :-).

How to Translate with Your Community

The three most common misperceptions about community translation that I hear are the following:

Quality

Most people have heard the horror stories: some site having to retranslate their whole user interface after a poor attempt at community translation. While some of these stories are true, what they do not mention is that most sites that had some early setbacks still use community translation to a certain extent, and some quite successfully.

mistranslation

An often forgotten point is that while there are certain pitfalls to avoid when starting down the community translation path, some of the same ones apply to working with vendors as well. There are stories of poor translations in the language service provider world too. I actually found that most of these stories share a common problem: throwing content over the fence to be translated with little collaboration doesn’t work. Translating anything requires a dialog with the initial creators of the content to ensure its meaning is properly interpreted.

translator comments

Finally, an essential element of quality in a community translation program is the quality of the moderation program itself. We will get to that in a bit.

Speed

Another common misperception of the community translation solution is that it prevents any kind of deadline to be set. While some of it is true, it is certainly possible to work with a community of users and have them keep a good enough pace to keep a relatively large website translated. Some early Twitter languages took a while to be translated, but others like Traditional Chinese took just a week.

The critical aspect to speed in community translation is that it is a byproduct of a good moderation program. Steering users to the content with the most priority is important when dealing with their limited time. Keeping the most important content to translate at the top of their list ensures that it gets translated fast.

Cost

Most people believe that community translation is a cheaper alternative to hiring professional translators. Careful observation of the costs involved, in my experience, shows that not to be the case. Between the moderation program, research, and software development, most successful community localization programs incur costs that are even or larger than contracting with a language service provider. Salaries, servers, etc. can result in big monthly fees you have to pay even when you do not have a new language or new features to launch. Do not choose this model if you’re trying to cut costs!

An important thing to keep in mind is that monetary incentives are pretty much off the table. Orit Yehezkel, Head of Localization at Waze, says:

“If you give the community money, it’s not a community anymore. They become mercenaries.”

A better way to spend that money is to put it to work in community building efforts: organizing conferences, meetups for your community, creating programs to recognize them and providing other types of incentives like access to beta features. While these can represent a large investment, the money doesn’t go directly in the communities’ pocket. It is used to create goodwill, and comes with an investment in some of your time, which will be much more noticed and appreciated.

What to Translate?

There are so many different types of content that are produced and translated that attempting to list all of them would be fruitless. I’ve categorized them into seven different types below, but keep in mind that because your content is not listed here doesn’t mean it won’t work.

The most important aspects are to be aware of what kind of category your content fits in and to think about what might drive someone to translate that content or to become disinterested in it.

1) User Interface

This is typically the first thing attempted and historically the most successful. This is what drives most of your community to translate: they want to see the product in their own language.

There are variations on how you would approach this translation process depending on what type of software you’re translating (mobile app vs. website, responsive HTML5 vs. static content…) but those variations apply to how you would handle this content with a traditional language service provider so I will leave them to another blog post.

2) Marketing

Short fun stories will be translated very quickly and well, even by volunteers. Some other content may require enlisting the help of a local marketing expert.

I’ve attempted to crowdsource the translation of a slogan at Transifex into French with some good success. The discussion that came out of it was very useful and thought provoking.

3) Static Help, FAQs

Short, simple text can work, but it will require a large community and dedication that is closer to the type of efforts we see for some Open Source projects. Twitter, with up to a million translators, had to decide to translate this with a language service provider. However, forums and social media can also help build a knowledge base. Some companies have experimented with users supporting each other. There are great tools out there to do that already!

4) Support notes

Support notes are time sensitive and need to be right the first time. Translations need to be fast and accurate right away, and their content is often very dry. This makes it a tough sell for a community localization program.

5) Glossaries

The idea with this content is to have the community help create the terminology, but leave the interpretation / execution to professional translators.

The challenges with this idea is how fluid community translations can be sometimes. Having the right tools to lock down terminology and making sure that it is finalized before sending it to the professional translators can be a challenge.

Today, some tools can do an automatic glossary extraction. With a community translation process applied to the output of these tools, coupled with a modern TMS to perform the actual translation of the content it might be possible to try it out and get a good feedback from a limited community of users.

This might be a good sweet-spot for an organization who wants to try out community translation with a small investment.

6) Style Guides

There are tons of standard ones. An option to involve again the community in this process could be to use a wiki to have the community participate in the definition and creation of how the product talks to them?

7) Terms of Service

This is probably best handled by a lawyer. Most of the time, the work required is not just to translate, but to adapt to fit the customs and rules of the local country. This makes this type of content a poor choice for community translation.

Languages

Beyond those different types of content, there are also surprising differences in which languages happen to be successful at doing community translation. While it’s difficult to point to any particular trend, it’s worth keeping in mind a few things:

Some smaller languages are dying to help you translate, so don’t overlook anyone. For instance, you may have a very loyal following in a in lesser known community: a small community of users in Catalonia who email your CEO for an official translation effort so much that he had to crack and ask their engineering team to do it :-).

One nice side effect of community translation, because it is a heavy investment, is that it needs to scale across many languages to be cost effective. But being able to access a lot of these smaller pockets of users quickly can be an effective strategy for some!

In some languages, most early adopters are “perfectly fine with English” and thus will have a limited interest in helping translate your website in English. If this market is important for you, you might have to invest in a professional translation. The risk there is that the translation may not be necessary.

Moderation

An important feature of a successful community localization program is the quality of its moderation team. While moderation is good in moderation, there is an art to doing it well.

You might think that a core competency for moderators would be to be able to tell the difference between a good translation and a bad translation. For instance, our initial tests showed that the best moderators were not those who provided the best translations, but those who voted up the best translations.

Another important job for the moderators of these communities is to actively find “broken windows” in the community to repair. These jobs can vary from putting out a flame war between translators on which form of the word “you” should be used in your product, to organizing a translatathon where translators get to meet on IRC, or a brief chat to discuss various glossary terms that have been misused.

Finally, as a moderator you have to act as a control and monitoring tool for the health of each community, making sure it has what it needs to be active and productive. This can mean being innovative in creating content, to keep people coming back:

When it comes to translations with the community, with enough volume you can think of the community as a forest fire. It spreads outward translating everything, leaving inactivity behind in the middle. You want the strings and translations that are active to be the most useful ones, or the ones with the highest priority. As the activity increases, there’s more and more trolls on the limited strings available for translations. This makes for a poor user experience. I learned a few choice words in Greek that way…

There are three approaches to moderation:

1) Automated Moderation

In this model, the system is self-policing. Each user is both responsible for contributing moderation and content. This typically uses a reputation system based on votes. In general, 3-5 votes are enough to promote a translation to reviewed.

image

  • Pros: This model can scale to lots of volunteers.
  • Cons: With this large of a community, they will potentially feel like you are out of touch. Implementing this takes time.

There are a few ways to automate the moderation, running the gamut through what I call a “laissez-faire” approach to a fully gamified experience.

Laissez-faire: This uses votes as a signal to decide moderation. The underlying assumption is that the community in this case relies on intrinsic rewards; Getting the site translated is an end to itself.

Gamified: This allows you to extend community efforts beyond translations, but actually editing content or personalizing the experience for users in that country.

2) Controlled Moderation

In a controlled moderation environment, users provide the translations, but a paid team of linguists/reviewers/community managers adapts and corrects the translations for consistency. We recently experimented with this approach at Transifex and translated our site into FIGS with the help of our community and e2f.

  • Pros: Human sized, easy to implement.
  • Cons: Cost to scale, hard to find experts in some languages.

Quality control can be done using different processes:

a) On signup, using an invite only system: Users can only be invited to translate, using some kind of a referral program, or after having been vetted by a human. This also provides a good way for you to ensure your translators have access to a contributor license agreement if your legal team requires one.

image

b) After the fact: Users provide the translations, but a paid team of linguists/reviewers/community managers adapts and corrects the translations for consistency.

3) Crowdsourced Moderation

In this model, the responsibility of choosing moderators falls on the community itself.

  • Pros: Promotes a fully collaborative environment, scales to tons of languages easily.
  • Cons: Delivery dates can be very fluid, can stir conflict and flame wars.

Used frequently in the Open Source world, this model requires you to steer your community towards a collaborative model rather than a competitive one. The gamification techniques mentioned earlier may thus need to be adjusted.

Beyond Translation

Another interesting area to explore once the translation effort has settled is to expand the localization effort to other types of work. Now you’re asking your community to not just add translations, but to actually act as editors or curators for some of your content. Waze comes as a very successful example in this area, with users contributing mapping data, gas prices, hazards, with very specific location area. Twitter has a similar effort on-going currently with their country specific suggested user lists.

Customize Translation Checks for Your Files

Transifexians, we have good news for you! From now on, you’re going to have even more power in our editor to manage your translations the way you wish. Now, you are able to choose the validation checks that will be run against your translations, such as whether a URL is entered correctly by the translators. So, let me introduce you to our new feature.

How did it work?

We have been doing that for you by setting what checks are necessary for the new translations. These checks can be errors or warnings. When an error check for a translation fails, then the translation is rejected, but when a warning check fails, the translation is saved. In both cases translators see an appropriate message.

But isn’t it better for oneself to decide on the rules that will have an impact on his life? We believe so and that’s why we now let you decide in which occasions your translators will be just warned or not be able to save a translation at all, if it doesn’t match the rules you set.

To be more precise, each organization can now set its own translation checks for each type of file that it uses under the Manage Tab of its dashboard. Take a look below:

image

Example case is the following:

Let’s say I have PO and YAML files: I can choose what checks  I want to be run for each file type whenever a translator translates my content.

So for the .po file, initially I see the default checks for errors, warnings along with the disabled ones. Now I can easily change them and switch a warning check to be an error check, and vice versa. I can even turn one check off. So if I switch a check to “Error” then the  translation that does not pass the corresponding check will  be rejected but if I switch it to “Warning” then the translation will be accepted and saved. If I turn off a check then it will have no effect at all.

Let’s try it live.

Case 1: I set the validation check “Email addresses found on source string are preserved in the translation” as  Warning.

image

Then, if I try to translate a string that has an email and I don’t preserve the email in the translation, I get a warning but the translation is saved.

image

Case 2: I set the same validation check  as Error.

Then, if I try to do the same in the editor, I get an error mesage and the translation is rejected.

image

And that’s all!

Isn’t it cool? And it’ s available for all. Let me know your opinion!

We’d also love to have feedback on our validation checks. Which ones are the most valuable in general, or the most valuable for a specific file type and so on. We could also have suggestions for new ones!

Happy localization people!

Eating Your Own Dog Food: Managing a Continuous Localization Project

eat your own dog food

In this post we’ll describe how we, the Transifex team, use Transifex itself to localize our own product. Though we focus on our specific workflow, our hope is that you would become more familiar with handling localization workflows when using the tools and frameworks we do (namely gettext, Django, Git). That said, the same principles and procedures should work with any tool or framework, and even non-software products as well.

Note: Since we’re talking about translating Transifex with Transifex, things might get a little confusing whenever the word ‘Transifex’ appears (Transifex!). This is the fun part, however. It’s what “eating your own dogfood” means after all. Try not to get confused.

Some preliminary basics

Gettext

Gettext is one of the most popular open-source libraries for software localization. It allows developers to mark strings in the code as ‘translatable’.

In Python, it is done like this:

from gettext import gettext as _
translatable_string = _(u'A sentence to translate.')

This has the following effects:

  1. It allows the ‘gettext‘ command-line program to find these strings in your code and extract them into a .po plaintext file. This file, known as a ‘source language file’, can be given to translators to produce additional language files — one for each language.
  2. Once language files for several languages are available in the code directory structure, the ‘msgfmt’ command compiles them into binary files (which use the ‘.mo’ extension). When the actual product renders the strings that were marked as translatable with the ‘gettext‘ call, it uses the information in the compiled files, cross-checks with the current language selection of the program, and displays the appropriate translated version.

Gettext in Django

Django is the web development framework that we use to develop Transifex (while Django developers use Transifex for localization management and crowdsourcing). It provides several wrappers around the gettext calls that are more convenient for web applications. Specifically,

For marking translatable strings in the code:

from django.utils.translation import ugettext_lazy as _
translatable_string = _(u'A sentence to translate.')

For html templates:

{% load i18n %}
<h1>{% trans "A header to translate" %}</h1>
{% bloctrans count ppl|length as num %}
Person:
{% plural %}
People ({{ num }}):
{% endbloctrans %}    

To create the source language file (from the command-line at the base directory of the project):

python manage.py makemessages --locale=en

To compile language files:

python manage.py compilemessages --all

Django keeps a settings variable called “LANGUAGES”. This is a list of all the languages that the product can be displayed in and that will be compiled when calling ‘compilemessages’. Transifex sets this variable by reading a plaintext file in ‘locale/LINGUAS’, which contains a simple list of those target languages.

Finally, Django provides functionality that helps users switch languages when using the product (e.g. the language selection dropdown at http://wpdev.transifex.com).

Version control

We use Git, a distributed version control system, for maintaining the state of the product’s code through time (a.k.a. version control) and for distributing the code among the development team. If you’re not familiar with version control, here is a brief overview:

Imagine your product’s code as a chain of states in time. These states, or ‘revisions’, are maintained through a repository on the developer’s computer. To begin working on the code, a developer copies the latest revision to the ‘working directory’ on his computer.

After working for some time, the developer adds the changes to the version control system and issues the ‘commit’ command. This command compares the current working directory with the previous version and generates the difference between the two — the changeset. The changeset is then committed into the repository along with the new state.

As you read further, you will only encounter three commands:

  1. git checkout’, which copies a specific revision to the working directory,
  2. git add’, which adds a file under version control and
  3. git commit’, which commits a new changeset-revision to your repository.

The advantages of working with a distributed version control system are many and are not the subject of this guide.

The Transifex command-line client

The Transifex-client is a command-line tool we created to help developers sync their content with the content on Transifex. In general, this means pushing source language files and pulling translation files.

In order to use this command, navigate to your project’s directory and call ‘tx init’. This initializes your connection settings with the Transifex server, which are set on an operating system profile-level (in Unix-based systems, this means that they are stored in ~/.transifexrc), and creates a ‘.tx’ directory in your project’s directory that stores your current project’s localization settings.

Then you call ‘tx set‘ along with some options that set the association between your project’s language files and the resources that are set up on the Transifex server. These settings are stored in your ‘.tx’ folder for the current project.

Now it’s a simple matter of running ‘tx push‘ and ‘tx pull‘ to sync your files with Transifex.

One of the neat things you can do is commit the .tx folder under version control so other developers can use the same sync settings as you without running the ‘tx init‘ and ‘tx set‘ commands themselves.

Here’s how the Transifex-client is configured for Transifex itself (this will work for most Django projects on Git):

# install client
pip install transifex-client

cd <path to Transifex project>

# We assume the Transifex project has been created in Transifex
# (http://wpdev.transifex.com/projects/p/transifex/)

tx init # you may be asked for your Transifex credentials
tx set --auto-local 
  --resource=transifex.txc 
  --source-language=en 
  --type=PO 
  'transifex/locale/<lang>/LC_MESSAGES/django.po' 
  --execute

# details on how to use the 'tx set' command can be found with 'tx help set'
# or at http://help.transifex.com/features/client/index.html#set

# (optional) add sync configuration under version control
 git add .tx/
git commit --message="added .tx configuration directory under version control"

Localization workflow

Most software products are distributed incrementally in releases, with release dates and upcoming features announced in advance. Before the release, developers make sure the product is bug-free and well documented. And if the product is to be offered in other languages, teams will announce a ‘string freeze’ on the product.

For developers, this means they can no longer change the code in a way that affects the source strings (bug fixes and improvements, however, are acceptable). For translators, the string freeze provides them adequate time to work.

When the release day arrives, developers get the translations for their target languages, compile them into the product, and release it.

How Transifex is actually used

Here’s the gist. Try to make what you can out of it as an exercise, however, I will explain each step in detail afterwards:

# String freeze date:
# -------------------

git checkout master
tx pull --all
git commit --message="stored past translations under version control"
python manage.py makemessages --locale=en
git add locale
git commit --message="updated source language files"
tx push --source

# Release date:
# -------------

tx pull --all
gedit locale/LINGUAS # choose sufficiently translated languages
python manage.py compilemessages --all
git add locale
git commit --message="updated target language files (translations)"

Let’s break this whole thing down:

String freeze

‘git checkout master’:

Copy the latest revision of the repository to the working directory.

‘tx pull —all’
and
‘git commit —message=”stored past translations under version control”’:

Before re-creating the source language files for Transifex, I pull all translations from the Transifex server to my working directory and commit them to the repository. This step is optional and mainly serves to preserve translations for future use and/or backup. Transifex employs a Translation Memory feature that provides powerful restoring functionality wherever needed (more on this later). However, it never hurts to have an extra backup.

‘python manage.py makemessages —locale=en’:

Extract all translatable strings from my code (marked with gettext) and create the source language file which is stored in ‘locale/en/django.po’.

‘git add locale’
and
‘git commit —message=”updated source language files”’:

Commit the updated source language file under version control.

‘tx push —source’:

Push the newly updated source language file to the Transifex project on Transifex.

Release

‘tx pull —all’:

Get all available target language files from Transifex and put them in the appropriate place.

‘gedit locale/LINGUAS’:

Choose which languages to include when compiling translations. For example, our principle for Transifex is to include all languages that are 90% translated or above. The completion percentage can be viewed on the project overview page on Transifex (https://www.transifex.net/projects/p/transifex/).

‘python manage.py compilemessages —all’:

Compile all languages indicated in the LINGUAS file in the final product.

‘git add locale’
and
‘git commit —message=”updated target language files (translations)”’:

Commit the translations to the repository.

The automated nature of this process means you can have as frequent release cycles as you like.

Now that you know how to employ the most automated localization process out there, here are some advanced tips:

What happens when you ‘tx push’
(and a few notes around Translation Memory)

A source language file is essentially a collection of source strings. This is reflected in the way resources are stored in Transifex’s database: when you push a source language file on top of an existing resource on Transifex, it finds the subset of common source strings in both the source language file and on Transifex. For these strings, it keeps all translations for all languages as they are. Source strings that were on Transifex but not in the updated source language file however are not simply deleted, but:

  • Firstly, they are stored in the project’s Translation Memory. Actually, all translations ever submitted to a project on Transifex are saved in the project’s Translation Memory, and this happens automatically immediately after they’re submitted.
  • Secondly, they are compared to the new strings imported from the updated source language file. If there is a high-enough similarity between the old and new source strings, Transifex doesn’t consider there to be a ‘delete’ action on the old string and an ‘insert’ action on the new string, but an ‘update’ action on the pair altogether.

The Translation Memory finds occurrences between two source strings and presents existing translations on one source string as automated suggestions for the other.

So, when Transifex tries to insert a new source string to a resource, one of the following three outcomes will happen:

  1. If a 100% match from the Translation Memory occurs and the relevant setting is set in the project’s admin panel, Transifex will automatically use the entries available in Translation Memory as translations for all available languages.
  2. If Transifex considers this insertion as an update, it uses all existing translations as suggestions for that specific string. This means if existing translations are still appropriate, they will be able to be used by translators with a single mouse-click.
  3. Otherwise, Transifex simply inserts this new string with no available translations or suggestions.

Restoring Transifex resources

Many products have major releases several times a year and developers want to include translations to as many languages as possible in each release. However, it’s not always practical to invest the effort/time/money to do so straight away. In some cases, you may have started on the next release only to realize that you want to increase the number of target languages in a past release.

Suppose you issued a stable release on January 1st called ‘1.7’ and 5 target languages made it into this release. On January 8th you generate a new source language file from your development version and push it to Transifex because you need translators working on your next release as soon as possible.

In February, due to the incredible success of your 1.7 release, you realize you can employ many more target languages for your product by your professional translators or even from you community. Since your development version and the 1.7 release share a lot of texts content, it would be perfect if you could apply some of the new strings/languages you have available to it. The proper approach is to issue a ‘maintenance release’ called ‘1.7.1’ which includes more and fuller target languages. However, you run into a roadblock: the resource file on Transifex is produced by a different source language file than the one present in the 1.7 stable release.

Transifex can solve this issue automatically. All we need to do is run::

# do the maintenance release
# --------------------------

git checkout 1.7 # '1.7' is a tag that pinpoints the stable release's revision
python manage.py makemessages --locale=en
tx push --source
tx pull --all # yes, issue this immediately
gedit locale/LINGUAS # set new languages to be compiled
python manage.py compilemessages --all
git add locale
git commit --message="maintenance release: added more translated content"
git tag 1.7.1

# set things back to normal
# -------------------------

git checkout master
python manage.py makemessages --locale=en
tx push --source

Note: In case you noticed and are confused, the ‘git commit’ command will create a new ‘head’ on your repository. This is an advanced feature of distributed version control systems you needn’t worry about for now.

Notice how no time has passed between the ‘tx push’ and ‘tx pull’ commands for translators to work. Yet new translations will emerge for your project. During the ‘tx push’ command, Transifex uses its “magic” to use new available translations for the source strings.

By pushing an older version of your source language file on an existing resource on Transifex, you can restore your resource to a previous point in time. Actually, you do more than that. Not only do you restore old translations, but you also add new translations to your old source strings!

Announcing the Transifex Referral Program

Think back to the first time you heard about Transifex. For many of you, it was through a friend or colleague.

Well, what if you could tell your friends about Transifex, save them money, and land your organization a free subscription — all at the same time?

With our new referral program, you can do just that.

How it Works

It’s simple. Give your friends your unique coupon code and if they subscribe, both of your organizations will get a 10% discount for the next 12 months.

Sign up 10 friends and that’s a full year of Transifex, free. It’s a win-win.

To get started, go to the dashboard of the organization you wish to make the referral for (i.e. the organization that’ll receive the discount when another organization subscribes) and click the “Refer friends now” link in the referral widget on the left.

Referral widget

A popup will appear where you can share the coupon code via email, Facebook, or Twitter and track the referrals you’ve made. You can also grab a special link and post it on your the website or blog.

Referral program

Any Transifex user can make a referral — organization administrators, project maintainers, team coordinators, translators. Just be sure that the organization you’re making a referral for a) has a credit card on file and b) is subscribed to a plan that’s $1,000/month or less, including the free plan.

Get Started

So, got a friend, co-worker, or company you know that needs a platform to manage their translations?

Invite them to Transifex.

Introducing Reports in Transifex

Ever been curious about how many words your translators handled during the past week? If yes, we have good news for you.

Organization Administrators can now get a report of the users who have contributed to their projects along with the number of new and edited words each one has translated.

Translation Reports

You can filter reports by project, language, and date. For instance, it’s easy to find out who worked on German translations for your iOS localization project from September 15 to 30.

Report filters

Sort results by the number of words in new or edited translations to see who your most active translators are.

Translator word count

The reports can also be downloaded as a CSV (Comma Separated Value) file and imported in the spreadsheet software of your choice.

Reports is still in beta, but it can be accessed from your organization’s dashboard. Give it a whirl and let us know what you think.

Update: Reports is only enabled for organizations subscribed to the Premium plan or up.