Localization Update for the 2010 Q3 GNOME Quarterly Report

(As drafted on the gnome-i18n mailing list several days ago.)

On July 29, Andre Klapper represented the GNOME Translation Project at the AGM meeting at GUADEC with a Project update report. At GUADEC, he also gave a talk on “Identifying software projects and translation teams in need” where he provided an overview of interesting data combined & gathered from Damned Lies, GNOME Bugzilla and other relevant sources.

Gil Forcada, with the feedback from other community members, conducted the GNOME I18N Survey by sending a questionnaire on August 13 to every GTP language coordinator, and collecting answers for two weeks. Out of 120 coordinators, 36 answered. The rationale behind the survey was to know each other within the GNOME translation community better, and thus to find ways the GTP can improve the overall experience of translating GNOME.

The sent questionnaire consisted of more than 20 questions on various areas of community l10n in GNOME, e.g. inquiring about general team information, coordinatorship & membership, team workflow, QA processes, use & evaluation of GNOME Damned Lies infrastructure, collaborating with downstream translators, other translation teams, and language institutions, community knowledge sharing, etc.

As for the GNOME development itself, GTP language teams have been busy working on providing l10n support for the new GNOME stable release 2.32, which was delivered on September 29. GTP has been also investigating approaches to help out language teams that seemed to be considerably short on manpower and/or proper coordinatorship, this included the Persian and Welsh teams.

We also communicated with GNOME developers to try to solve i18n issues with translating strings within submodules, strings with constructed sentences, and some other problems that (re)appeared during the Q3 period.

During Q4, apart from working on l10n support for the upcoming GNOME 3, GTP community aims for identifying issues with the current i18n & l10n infrastructure inside and outside the GNOME Project, like the Git commit functionality, and solving them, hopefully implementing the necessary GTP support for repositories hosted at git.gnome.org and elsewhere. This is to be done in conjunction with the Release Team’s proposal for moduleset reorganization.

Translation Teams Off

You are a developer and you want to keep your project moving forward. You set up various communication channels and organize an open community around. Your vivid project starts to attract new people, amongst them are people who intend to contribute code to the project. Great, because that’s what you were waiting for when you started building your FLOSS community.

Naturally, you do not allow anyone on the net to directly contribute code without any, more or less formal,  review process. That’s good, since you care about happy community of contributing members, but you also want quality that you can be proud of.

Translation Teams Off

And then there’s the world of community localization. You are most likely not a polyglot, and you can hardly do a review process with tons of languages from around the world, apart from making sure that the localization work you’ve been provided is not missing some obvious bits of technicalities. So you simply open the submit process for l10n to anyone, or reach to some nice outsourcing tool, hoping that translators will eventually cope with it and the project’s l10n will be worthy, as is the code. But really?

But Really, It’s For Your Own Good

That is, not to stick to the openness at any cost. The fact is that, quite similarly to the code contribution, the quality work in l10n will not miraculously show up. It needs reviews, proper management, suitable workflow. It needs community.

One of the first things you need to do if you want to facilitate building a real l10n community is to set up, more or less formal, rules. So you turn the translation teams option on. You encourage work in translation teams & projects, so your translators can interact with each other and share knowledge. You keep an eye on l10n. You are responsive to the needs of your translation team members. Then you are a great developer with FLOSS project that deserves quality & efficiency in l10n very much comparable to that of the professional (as in commercial) translators with plenty of ISO & DIN certificates. And your project has it. For free. (Almost.)

Translation Teams

It’s time to participate in the GNOME i18n survey

If you happen to be one of the GNOME Translation Project language team coordinators, and you haven’t done so yet, now is the right time to participate in the GNOME i18n survey conducted by Gil Forcada on behalf of the GNOME Translation Project!

The rationale behind this survey is that the GNOME i18n community (which the language team coordinators are naturally part of) wants to know better each other, so that the GNOME Translation Project can improve the overall experience of translating GNOME, as Gil outlined in his survey email. Some of you may remember that there was a similar survey conducted by an Ubuntu i18n community in the past which greatly inspired this effort.

On August 13, Gil sent out a plain text file with survey questions to all coordinators’ addresses we could gather. Nevertheless, only a fraction of coordinators have responded so far, so once again, in case you are one of the majority, please don’t hesitate to take a few moments to fill out the questionnaire! Or if you know any of those coordinators, please ping them! Yes, it’s quite important!

For those of you interested in knowing what the survey questions are, you can find them attached in the aforementioned Gil’s email, and a final draft is available on live.gnome.org. Also keep an eye there for results.

Living with legacy hardware

In case your hardware still consists of very legacy NVIDIA chips like GeForce2 or GeForce4 and you are experiencing some problems running X server on Fedora 13 with the now and for some time default nouveau driver (like screen freezing after a period of time with an apparent need to hard restart), you can still switch to the old nv driver and refrain from using either an extremely basic VESA driver, or a legacy proprietary driver produced by NVIDIA. (Which, looking at rpmfusion.org, doesn’t seem to be packaged for Fedora 13 to provide a support for GeForce2 etc. I’ve read something about compatibility issues with version 1.8 of the X server, but I haven’t looked into that further.)

One of the drawbacks is that you will have to live without hardware acceleration, since only software acceleration is provided. (Okay, these chips weren’t GNOME Shell-ready anyway.)

A quick memo on how to accomplish that switch on a fresh Fedora 13 install:

First, you need to create your own xorg.conf file, since this isn’t delivered anymore by latest distribution releases. In order to do that, install the system-config-display package, and then run:

system-config-display --set-driver=nv

Simply setting the desired driver in the xorg.conf file, however, is not enough, because the nv driver is interfering with nouveau, so you will likely get this error message when trying to run the X server:

The PCI device has a kernel module claiming it.
This driver cannot operate until it has been unloaded
(EE) No devices detected.

Fatal server error:
no screens found

That means you need to disable the nouveau driver e.g. by modifying your /etc/grub.conf file and adding the following at the end of the line starting with kernel:

rdblacklist=nouveau nomodeset

Then you can simply reboot your system and that’s it, you should be done.

Sylpheed FAQ revision 2.2 released

Sylpheed FAQ revision 2.2 released on 2010-08-09
================================================

New revision of Sylpheed FAQ has been officially released from the Sylpheed Documentation Project to reflect changes in the upcoming Sylpheed 3.1.

You can view the FAQ either as a multi-page or single-page HTML document at:

http://sylpheeddoc.sourceforge.net/en/doc_faq.html

Or download it together with source DocBook XML files in a .tar.gz or .zip archive from:

https://sourceforge.net/projects/sylpheeddoc/files/

The source DocBook XML files are also available in the Project CVS repository, see:

https://sourceforge.net/scm/?type=cvs&group_id=20952

Changes over the past 4 months
------------------------------

* New Q&A "Can I run multiple instances of Sylpheed?"
* New Q&A "Execute command for my dynamic signature seems not to be working!"
* Updated Q&A on environment variables
* Updated Q&A on automatic name completion
* Updated Q&A on Sylpheed plug-ins
* Other minor edits throughout the document
* To better comply with the GFDL license, the source DocBook XML files together with the plain text copy of the GFDL license and appropriate legal notice are now distributed in tarballs with each documentation release, and the exact way of how to obtain the source files is mentioned explicitly in the document; thanks to Ricardo Mones for pointing these legal issues out

All other information on the Sylpheed Documentation Project including how to contribute to the documentation effort is available at:

http://sylpheeddoc.sourceforge.net/

Contributors to this and previous releases
------------------------------------------

Paul Kater, Jens Oberender, Francois Barriere, Olivier Delhomme, Petr Kovar

Enjoy!

Interested in helping Pan?

Usenet may not be as popular as it used to be years ago, but this worldwide net definitely still has its users. According to Wikipedia, it was established in 1980, so Usenet users observe a nice anniversary this year. Given its popular stance throughout the Internet history, there exist, without much surprise, many FLOSS solutions to access Usenet, or to work with the NNTP. Using GNOME software, you can accomplish it e.g. with the official GNOME PIM Evolution.

And then there’s Pan, quite minimalist, HIG respecting, easy-to-use newsreader for GNOME, that has been developed for a decade. Unfortunately, owing to the limited time resources of the main Pan developer Charles Kerr (whom you might also know from the Transmission project), the Pan development has slowed down considerably during the last two or three years, and it’s now officially in hiatus.

The community around the newsreader will hopefully be able to organize itself enough to resume and continue with the active development in the Pan official repository hosted on git.gnome.org. Luckily for Pan users, there’s a competent developer K. Haley around who has been working on Pan during the last few years, although not in the official repository.

Anyway, what the project now needs is, preferably, a bunch of volunteers with interest in Usenet and NNTP who are willing to lend a hand and get involved in the project.

The much needed roles include:

  • a developer with experience in C++, to help out with the Pan main development, to review and accept patches that got accumulated during the years in the “Pan” product at bugzilla.gnome.org,
  • possibly a developer who may be willing to  take over the maintainership in the future, once it is needed, or in case K. Haley will resolve to participate in the project not as the maintainer,
  • bug triagers, patch reviewers, testers,
  • people who are willing to work on user documentation and Pan website that might be migrated from its current location, and which is in serious need of getting up-to-date; I, for myself, am willing to work on these and will appreciate any help,
  • translators who are thankfully willing to work on Pan without break, as the last commits to the official Pan repository are those from the GNOME Translation Project members,
  • users, users, users.

If interested, please contact the Pan community that gather together on the following mailing lists:

Naturally, as with other FLOSS projects, every help and every contributor is welcome. TIA.

Hi Planet GNOME!

Being syndicated on Planet GNOME from yesterday, I’d like to thank Lucas Rocha for adding me to the list!

If interested, you can read more about me as a GNOME contributor e.g. on live.gnome.org, and about intentions behind this blog in my first post.

Okay, enough of self-promotion for now, back to the work.

Documentation, GFDL, etc.

Last summer I found myself delving into documentation writing & maintaining. My email client of choice, Sylpheed, which many FLOSS users might remember from early 2000′s when it was one of the first full-featured GTK+ clients (at least as far as I know), was distributed with a set of long-time unmaintained documentation that quickly became more or less completely out-of-date.

In fact, it wasn’t touched for over three years and was left in a state of partially completed LinuxDoc SGML to DocBook 4 XML migration. The first thing that needed to be done, even before finishing the migration and previewing the actual documentation, was obviously evaluating whether it is actually worthwhile for a new maintainer without deep knowledge of the given maintenance rules & processes to try to continue with updating the original documents, or whether it would be better to start from the scratch, i.e. with a complete rewrite.

Since I wasn’t feeling very adventurous and my previous experiences were quite limited, to say the least, I eventually sticked with the former option.

Now I can say that the biggest obstacle is not a need to understand DocBook 4, neither it is adapting work flow procedures and writing style of documents with numerous authors in their history, it is actually dealing with the GNU Free Documentation License, the license the said documentation is distributed under. I believe that many rants have been written before already about this piece of legal text, so I won’t repeat others here. Still, I’m quite grateful for Creative Commons licenses as something fresh and needful coming into scene and replacing GFDL within many documentation teams & efforts. I wish it was more feasible for maintainers to relicense a documentation work done by many (inactive and probably unreachable) authors from GFDL to CC. That being said, the clause that appeared in the GFDL version 1.3 is/was apparently not very helpful, unless you wanted to relicense content on Wikipedia or something very similar.

Anyhow, what I have found in my experience (IANAL) to be least amusing about GFDL is:

  • The idea behind invariant sections etc. (Yes, I can understand those good intentions that went pretty wrong, I would say.)
  • The definition of a transparent format.
  • The need for distributing the full text of the license along with a licensed document.
  • The thing that a generated HTML file with included GFDL copy (i.e. a generated file converted from DocBook XML source files) is or at least might be seen as an opaque copy, that is one needs to distribute a (plain text) file with full text of the license along with HTML file distribution (be it via tarball or any other standard channel). This issue was brought to my attention by Ricardo Mones and discussed on the Sylpheed mailing list.

Planet Fedora

So after crying my eyes out, I realize that this is my first blog post that might land on Planet Fedora, so I would like to say hi to all the hopefully interested readers out there! You can find most of my Czech localization & documentation writing contributions upstream, however, with me joining the Fedora Czech translation team ca. two years ago, and enjoying my encounters with the Fedora l10n infrastructure, notably the Fedora Transifex instance, ever since. Though I do remember the times when translate.fedoraproject.org was running a Damned Lies fork, also. OK, not too far away history, anyway.

Localization Update for the 2010 Q2 GNOME Quarterly Report

(As discussed on the gnome-i18n mailing list.)

Various localization teams that are part of the GNOME Translation Project continued with focusing their localization effort on stable GNOME 2.30.1 and 2.30.2 releases which were released on April 28 and June 23, respectively. Localization teams will proceed further with working on localization for the upcoming GNOME 3 release.

GNOME translation community that gather together on the gnome-i18n mailing list discussed and conducted common translation project administrivia, including assistance in changing coordinators in several localization teams, the most notable case being the Slovak translation team, in which several translators expressed their discontent with the current way of coordination. The issue was thoroughly discussed within the Coordination Team in order to mediate the dispute and was settled down in the beginning of July when the current Slovak coordinator announced his resignation.

Among other things discussed was the legal issue of whether translators who are not legal experts should translate legal notices or license texts that usually come with the free software distribution. This topic was further discussed on the GNOME legal-list with Luis Villa.

Also, there was a change done in the structure of the GNOME Translation Project coordination. Previously, the project was formally led by two Spokes Persons who were also senior members of the extended Coordination Team. Now, the Spokes Person status has been obsoleted in favor of a larger Coordination Team.

For string freeze break requests during the GNOME Desktop development cycle, developers are now required to obtain the approval from two members of the Coordination Team. The Coordination Team that now consists of 11 members will also seek ways to improve the responsiveness about requests.

One of the important tasks that the GNOME Translation Project intends to accomplish during Q3 is completing the implementation of Git commit support through the infrastructure running on l10n.gnome.org.

Czech GNOME LUG nonsuccess

A member of the Czech GNOME community once had a promising idea to strengthen and organize user community in our country (and possibly also counting in people from the neighboring Slovakia) at a common place where interested visitors could find various information on the GNOME Project, and on what could be called as a GNOME software ecosystem, on its developers and, in particular, end users. This all provided in their local language, and considering needs and concerns of the local user group. It was nothing new, after all, we knew about similar local groups that have been very active in, e.g., Asia or Hispanic world.

But contrary to the vital successful ones, the Czech group (or what was meant to be the Czech group) soon showed its limits. I assume that this GNOME LUG attempt failed mainly due to the quantitative factor: in a country with 10 million people, the FLOSS community may be seen as strong and vital enough, probably thanks in part to a distinct tradition of higher technical education (in the country that has been continuously attracting many ICT businesses from 90s on, including those well-known in the FLOSS world), but in the end, it showed that it’s not enough for an enthusiastic individual or a handful of people with interest in a minority software to be able to form an organized group.

Instead of that, Czech and Slovak people who want to read or communicate about FLOSS tend to frequent two or three major Czech FLOSS-oriented websites with a standard set of social networking services. In addition to that, the only viable FLOSS websites beside the major ones are those aimed at “downstream” projects, i.e. distributions, operating systems or productivity software end-user support. This might be a significant drawback for upstream and much more “generic” projects like GNOME in general: users are aware of the distribution they are running, but they don’t know much about exactly what desktop environment they use. Nor they seem to care that much, after all.

So to make long story short, we had (and still have, for what it’s worth) a LUG-supporting website, but we quickly learned that such a website is merely unable to attract its potential users. That being said, for our Czech case, it wasn’t very helpful, either, that the project was planned and realized more or less as a one-man-show, with its primary and sole author not allowing website visitors to actively participate on and contributing to website content, thus making it hardly interactive, making it less like what many call Web 2.0 nowadays.

The author was ultimately able to work on the website for less than a year, from Summer 2008 to April 2009, with the last published news commenting the GNOME 2.26 release. Since then, the website has been dead as in never coming back.