I thought to write this since a blog is a more correct place for this kind of stuff than arguing about priority issues in bug reports. The title is one way of explaining the need of FLOSS distributions to shift a bit away from just improving on technical aspects. My controversial claim would be that fixing highly visible I18N bugs is more important than fixing random crashers. People are accustomed to seeing application crashes from time to time, but do not want to be disrupted with non-native language in their basic computer usage. Not all people agree, and neither all people should agree.
I'm quite technical kind of person myself, but I think it's not just proper artwork / design teams we are (still) missing on FLOSS distributions, but that in general non-technical people should get more involved. It will mean the usual ”bah, those marketing/artwork guys” vs. ”bah those nerds only tweaking kernels” discussions will raise, but it is IMHO needed to have more heterogenic group of people making contributions to distribution development. Some more technically oriented developers would still not value I18N or artwork issues as much as application crashes, and that's perfectly ok and those guys rock, but the average (statistically) mindset of a contributing person would shift to treat different kind of issues more equally.
As an example let's take Ubuntu, the arguably most John Doe -oriented distribution there is. It is still far from concentrating enough on non-technical issues, but it is already getting a lot of heat from more technically oriented developers and users by doing the amount it does and being successful with it. Ubuntu 9.04 is going to rock I18N-wise , but the people responsible of realizing the need for most of the fixes (and offering a fix for many of them) are a small group of people between the technical developers and the users, who understand when there is a technical mistake somewhere regarding I18N. Currently the average Ubuntu developer is more interested in point number 1 in the Ubuntu philosophy than the numbers 2 and 3, and that would need to change.
What I see as lacking here is that technical developers mostly still use English on their computer even if it would not be their native language. I would hope that some percentage of FLOSS distribution developers would be willing to use their own distro in their own language. It seems currently rare that this happens, since otherwise we would not rely as much on completely other people to file bugs on things that are very visible, annoying and giving a bad impression about a distro to any non-English user. One way to understand the importance of the problems is to discuss more with ordinary users, since at least I've heard a _lot_ about many I18N bugs from various people, but the same people never mention crashes separately even if those would happen (some may say "oh yes it crashes sometimes but not too often").
In addition to Ubuntu, I hope that other distros will offer competition in the field as well, because competition always yields better results. Fedora is doing some stuff very nicely, and their upstream-integrated L10N services is better than Ubuntu's Launchpad in some ways, but probably because so many developers are US-based, some really visible bugs get even less attention than in Ubuntu.
Subscribe to:
Post Comments (Atom)
6 comments:
Uhm...I'm not sure what you are trying to say in that last paragraph.
But just to be clear...the Fedora translation services are based on transifex..which is primarily developed by people who live outside of the US.
http://transifex.org/wiki/Development/Crew
You'll note their personal blogs are written in mix of English and their native languages. I'm pretty sure the transifex developers rely on native language support on a daily basis. So I'm not sure if your last paragraph makes sense.
The fact that non-native English speakers are driving Transifex makes me far more hopeful about its impact on how translations are going to be done by many projects in the future. Who better to build a translation services tool then the very same people who need high quality translations? I strongly believe the lead developers behind transifex understand exactly how to bridge the translator and developer communities for maximum benefit... because they've been translators and they do rely on the language support themselves.
It's also interesting to note that the Fedora Projects planet for contributors at planet.fedoraproject.org includes multiple native languages feeds from contributors... not just English. Native language support is not academic for them. They use it. The rest of us see they use it. Where are the native language blog feeds for the international Ubuntu members aggregated?
Fedora's community is demonstratively interested in high quality native language support in the open ecosystem. The people driving the transifex translation service are non-English speakers (as it should be), and their is a flotilla of non-English contributors adding their own native voice to the aggregate planet feed making the Fedora planet an authentic view of how international the Fedora project is.
What is needed is a focus on getting high quality native language support into each upstream project so that language support can be built into the development workflow for each project as a release management best practise, and not shoehorned into distribution workflow after the fact. Better language support in Fedora isn't the goal. Better language support in upstream projects is the goal, so that all native speakers benefit from it. The growing Transifex translation community is going to be a big part of helping to achieve that, its just a matter of informing upstream projects about what the transifex service can do for them as part of their existing workflow.
Another interesting note. Transifex grew out of a Google Summer of Code project originally mentored by a Fedora contributor. The Google Summer of Code opportunity can matter a lot with the right mentorship commitment. Its too bad that the very large Ubuntu community had to withdraw from Summer of Code this year due to a lack of people willing to making that mentorship commitment.
-jef
It was just a quick note that first of all Fedora has some neat stuff regarding I18N and I've also used them to contribute eg. Pulseaudio and avahi translations. Indeed not very clearly phrased. Secondly, Transifex is only one part of the whole picture of having properly translated releases, and problems are often created late in the release cycle by native English speakers who do not always remember to test or think their changes with regards to I18N.
The problems are typically breaking string freezes without giving translators information, time or even a possibility to translate new strings, or breaking I18N by not using gettext for new strings. Those kind of stuff are what plague about all distributions from time to time, and make it hard or impossible to really have 100% translated default installation. Fedora also for example often takes, well, like Ubuntu too, source code snapshots from various places with half-made translations because they want some new feature. The up-to-dateness of the translations included then depend solely on when some random translator happened to commit new work the the trunk, while it's usually only done close to a that individual project's release.
So one aspect is how to create quality translations, and another is how to have all texts actually translatable and the translatability and string freeze really managed for each release.
To which release cycle do you refer to?
The distribution cycle or the upstream project cycle?
Translatable strings and the concept of a string freeze are both upstream development and release management issues. They are not fundamentally distribution issues. We are not going to solve the problems by concentrating myopically on the distribution release cycle clock. Integrating the concepts like string freeze into upstream development will matter far more in the long run.
The more directly the translation community can work as part of an upstream project development cycle, the more likely you have translatable strings and the less likely you'll see feature creep at the distribution level that will break translations.
-jef
Distribution cycle, but also upstream project cycle is related if the distribution takes a vcs snapshot, not a release from some project. In that case the upstream project cycle wasn't let to do its job. Also, distributions tend to sometimes do string changes to the sources via patches.
In Fedora 11 cycle, I've heard about problems with the installer I18N (not 100% sure if it was related to the storage rewrite or something else). For every release, some string changes are done to the distribution-specific software after the string freeze, sometimes very late. And one continuing problem is localization of specific .desktop entries which would need code contribution directly to a tarball, not necessarily very easy (doable with PO files if the project is set up right, usually not). Bug reports as such things are often forgotten for a long time after release, like a bug for Thunderbird is now over a year old and counting, while the problem is very visible. There are also other .desktop entries in the default installation without translations, which gives an ugly look of the distribution for a casual user.
Things like that are somewhat more common in Fedora than in Ubuntu, but even with Ubuntu developers need to be constantly poked about some issues, which is related to what I wrote in my post.
Anyway, I'm not the best person to deal with Fedora-specific I18N problems, I'm just a casual user with random contributions. My quick note was just that, a quick note that hopefully all distributions will improve and give competition to each other.
Jef,
Translatable strings and string freezes are distribution issues, not just upstream issues. Let's take a look at Fedora and the Finnish translation statistics:
https://translate.fedoraproject.org/tx/languages/fi/collection/fedora/fedora-11/
Fedora is actually the upstream for most of those projects. You could argue those are all independent upstream projects, but really, most of them are used only in Fedora and distributions which are downstream to Fedora.
In order to do a release with high quality l10n, we need to have some string and translation freeze concepts in the distribution. Of course a lot of the translations come from various upstream projects, but we also need to make sure our "distribution internal projects" have good l10n coverage and no i18n issues before the release.
Tomorrow is the translation deadline for Fedora 11, so maybe we could take a look at some of the problems we've had during this, and previous, release cycles.
- Fedora 11 went into string freeze on March 10, but the anaconda translation template was updated in March 27, leaving little time for translations, https://bugzilla.redhat.com/show_bug.cgi?id=484784#c5 - this is probably due to the storage rewrite.
- A translated .desktop file for Thunderbird isn't being added into Fedora. The bug report has been open for over a year. Granted, upstream doesn't want to have .desktop files for trademark reasons, but isn't this sort of finishing one of the jobs the distribution should be doing. Bug: https://bugzilla.redhat.com/show_bug.cgi?id=435051
- There are translations missing from the .desktop file of system-config-lvm, even though the translations are provided in the po files. No developer comment in bug report. https://bugzilla.redhat.com/show_bug.cgi?id=482794
- System-config-display's translation template hasn't been updated for Fedora 11. No developer comment in bug report. https://bugzilla.redhat.com/show_bug.cgi?id=490016
Now that the translation deadline is here, it'll be interesting to see how many developers will actually rebuild their packages to include the updated translations. During previous releases this has always been somewhat of a problem as well.
I'm a geek used to English but I use Ubuntu in Lithuanian.
I strongly disagree with your assertion that I18N bugfixes are more important than random crashes.
To me as a user, a crashing application is much more disruptive than a mistranslated string.
Perhaps my world-view would be different if I didn't speak English. I can imagine how an incomprehensible message could stop me in my tracks.
Post a Comment