*Sometimes, contributing back to upstream open source projects is not as straight forward as one may think. “Helping downstream translations swim upstream” will be a new series of articles where I intend to explain the issues contributors may face when attempting to send translations back to upstream projects, and hopefully, devise a couple of possible solutions.*

In the past few years we have seen an astonishing growth of companies that started using Free and Open Source Software (FOSS) bits and pieces in their products. From netbooks, desktops, handheld and infotainment devices, televisions, and cellular phones, FOSS applications have become the founding blocks for several companies trying to leverage its power and stability.

During the process of incorporating open source projects into their products, it is not uncommon for these companies to modify the user interface of the packages they’re using. Sometimes, longer messages need to be simplified to fit devices with a smaller resolutions, such as cellular phones. Sometimes, newer dialogs and messages are added to the user interface to complement a new feature or to “brand” it for their audience. Since the source code is, well, open, these companies can tweak things to their heart’s content and in the end, they can ship their product, make their profit, end of the story.

However, the story does not not have to end here. Some companies are very proactive and try their best to be a first class citizen and give back to the upstream projects, whether by sending in patches or even providing translations. The keyword here is “try”, as the way back upstream is not as straight forward as one would hope.

A good example of a project using upstream projects is the Ubuntu distribution, synonym of innovation and ease of use, with its massive number of collaborators and even paid developers. Contrary to what most GNU/Linux distributions do, Ubuntu goes through the cumbersome task of importing applications from every possible upstream project (think GNOME, KDE, LXDE, Xfce, etc) into their own repositories, and then making changes and improvements to a variety of packages across the board.

They also expose the majority of its repository for translation in order to fill in the gaps for any untranslated or doubtful (or in the translators jargon, fuzzy) strings that came from upstream. Ubuntu enjoys of a huge team of translators who day in, day out use its Rosetta online translation tool to make sure your desktop can “speak” as many different languages as possible.

When the smoke clears after the six month cycle that takes to finish a Ubuntu release, the end product is a first class distribution so intuitive and complete that even your grandmother could use!

Now, it has been a while since I last participated in any Ubuntu activity, but I remember that sending Rosetta-based translations back to the corresponding upstream project can be a very painful if not frustrating experience for the most upbeat and well intentioned translator. Sure, there are concerns about the quality of the translations being generated by Rosetta translators, but even in the situations where accepting translations could mean adding a brand new language to the upstream project, getting downstream translations to swim upstream is very hard!

One of the existing problems is the fact that there is not a simple, well defined structure for sending translations to upstream projects.

Some projects prefer to receive patches attached to a bug report properly filed against their issue tracking system. Someone, usually an approved member of a language team, needs to verify the issue, validate the patch and either commit it to the repository, or decline it and (hopefully) provide a reason for the rejection.

Some have come to rely on other translation specific “platforms” such as Pootle and Transifex, and prefer that anyone who wants to contribute should register with these systems first and join an existing translation team. Between registering a new account, learning a new system and getting to know a new team, it could take a long, long time to get your patches approved.

There is also the fact that the many different language teams within any given upstream projects operate almost that autonomously with their own set of rules e processes, adding even more to the complexity of “giving back”.

So, just how can someone working on a downstream project give back to their translation effort of upstream projects? Keep your eyes peeled here for the next part of this story.