-
FOSDEM recap
-
Another February, another FOSDEM. And what a great experience it was. I can’t decide where to start from. From the joy of seeing familiar faces again and the networking with cool people full of ideas, or the beautiful Brussels and the delicious crêpes Suzette. What a great trip.
I’ll try to document most of the interesting stuff that happened. This helps me track down TODOs for the next days and provides a nice report to see how stuff are progressing over time.
Init, Mozilla BoF and beers
Last year I was there with a couple of Greek friends. This time, the group was around 20 people. Not sure how that happened, maybe from a few of those encouraging emails to Greek mailing lists. It’s so fun travelling with friends, lots of laughs, especially with Themis from my local city’s LUG.
The day before the event, the Mozilla folks organized a BoF to discuss with various people from the community L10n tools. Some cool projects were presented at the session, all revolving around tools used to translate stuff. A couple of presentations caught my attention, like Alexandru Szasz’s one about Narro and Friedel Wolff’s about Pootle.
Like software development, translation engineering depends on the structure of the project being localized. Fedora’s challenges revolve around the fact that it’s a distribution of resources: we have many independent projects hosted around, each one with its own type, release schedule and quirks. Fedora is an aggregation of upstream stuff — even if some of them are built by Fedora engineers, and hosted locally. Under this light, we are called to cross quite a challenging river. With each tool we design and each process we adopt, we need to keep in mind characteristics that would make any combination of processes more complex: content diversity, hosting uniqueness, scheduling differences.
In this respect, I was more interested how these projects could fit in this distributed and upstream-friendly way of developing software and writing documentation, and the scalability that Transifex can ultimately achieve. Unfortunately, most of the tools don’t do well in this respect, and need some work to handle large numbers of projects (eg. 3+ branches of 80 projects for now, one of which has 6K strings in it). I invited people who are challenged by the existence of multiple systems and versioning systems in their ecosystem to find me at FOSDEM to discuss how their tools can use Transifex to overcome these difficulties, and it seems most of the tool developers were interested in such options (I wonder how difficult it is to have PHP and Python work together).
At the evening, we hit the beer party. I have to admit, some Belgian beers are strong. Despite this fact, me and Yaakov of smolt fame managed to discuss a bit about server-to-server protocols and how we could achieve federating translation portals like fedora.transifex.org or india.transifex.org in separate servers, while retaining the benefits of a common configuration scheme. Challenging stuff, but with great potential of resource distribution and locality.
Presentation and Mediawiki
On Saturday the day started with a good breakfast at the hostel (no internet, no blogging) and the setup of the Fedora booth. I brought with me a 3m-tall Tux poster, which we hanged right behind our booth, along with Máirín’s new slick ones. Had some good discussions with Joerg about Fedora EMEA and spot about our L10n engineering progress.
My presentation went really nice, despite some mic twists. I was happy to see a lot of people being interested in it enough to attend and listen to me for 40 minutes, but also to see that people from Debian, openSUSE, Ubuntu and Wikipedia were there. Some very interesting questions were asked, like if Transifex can be used to provide a common terminology or lexicon to translators, and whether Transifex can be used with Launchpad, Ubuntu’s main development (and translation) service. Unfortunately, Launchpad is closed-source software, so I can’t know how to make it use Transifex to solve its limitations with dealing with upstream.
On the other hand, Launchpad hosts projects on a versioning system open to external contributions, so Transifex could be used to submit translations to projects hosted on Launchpad, just like any other upstream repo. Once our hooks are there and we can let any developer register his repo on Transifex, then any project hosted on bazaar.launchpad.net, code.google.com, sourceforge.net et al could use Fedora’s translation community for contributions.
We also had a good chat with the Mediawiki folks that were there. They want to grow their community (and hence, their language coverage) and reminded me that one of the values Transifex has is bringing translation communities together. I also seem to have forgotten to mention in my talk that compared to the traditional direct access, we can now have pre- and post-commit hooks to validate, for example, PO files being uploaded in terms of syntax, encoding, etc, send commit notifications with high-level checks and messages, etc.
Since we are thinking of using Mediawiki for Fedora’s wiki, I want to make sure that it has the i18n support we need, both in terms of the UI and the content. I am extremely happy to see upstream is so much helpful in this respect. I’ll investigate more on the extensions MW has to support i18n and try to report back sometime in the next weeks.
Fedora L10n Meeting, openSUSE, and Pootle
Since some of the most active European translators were present, we got together for a L10n meeting. We mainly covered topics around Tools, Community and European locality. I was very glad to hear the guys were feeling much more comfortable with the new tools. It seems despite the ups and downs we are having, the new way of things using a website to submit translations is much easier for newcomers (and for some experienced users as well) is more enjoyable. Always good to hear things are getting better. Got a lot of good suggestions too, and, after popular demand, it seems the possibility of getting Pootle setup on one of our publictest servers could arrive sooner than later.
The openSUSE folks confirmed my belief that we have many common goals and point of views. They found Transifex a good idea that solves important issues, and worth of investigating and working together on it. In particular, they agreed that an authorization layer is needed for proper bridging between larger projects that have existing translation teams, like openSUSE and GNOME. It’s probably a good time to start working on it, and the separation of the commit mechanism from the web server. This way, a remote project could install the commit service on its own server, eliminating the need for creating SSH keys, etc.
Finally, I had a good discussion with Friedel Wolff from Pootle about their future plans. They are planning for a bunch of exciting features, which put the project even higher in my scale. Pootle is undoubtly the most complete web-based translation management solution out there, and its developers are such a friendly bunch of good hackers. Which makes me want to download the source right away and start working on how to make it work with our environment and Transifex.