tag:blogger.com,1999:blog-31939153.post5461656595079839630..comments2022-04-04T19:31:25.720+03:00Comments on Losca: Non-technical work should be more important than fixing "small" technical issues like crashesTJhttp://www.blogger.com/profile/17762291681744356830noreply@blogger.comBlogger6125tag:blogger.com,1999:blog-31939153.post-69368673957822448842009-04-07T13:43:00.000+03:002009-04-07T13:43:00.000+03:00I'm a geek used to English but I use Ubuntu in Lit...I'm a geek used to English but I use Ubuntu in Lithuanian.<BR/><BR/>I strongly disagree with your assertion that I18N bugfixes are more important than random crashes.<BR/><BR/>To me as a user, a crashing application is much more disruptive than a mistranslated string.<BR/><BR/>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.Marius Gedminashttps://www.blogger.com/profile/15155998626202067226noreply@blogger.comtag:blogger.com,1999:blog-31939153.post-4258033875942536492009-04-07T12:38:00.000+03:002009-04-07T12:38:00.000+03:00Jef,Translatable strings and string freezes are di...Jef,<BR/><BR/>Translatable strings and string freezes are distribution issues, not just upstream issues. Let's take a look at Fedora and the Finnish translation statistics:<BR/><BR/>https://translate.fedoraproject.org/tx/languages/fi/collection/fedora/fedora-11/<BR/><BR/>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.<BR/><BR/>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.<BR/><BR/>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.<BR/><BR/>- 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.<BR/><BR/>- 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<BR/><BR/>- 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<BR/><BR/>- 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<BR/><BR/>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.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-31939153.post-81917104863595055032009-04-07T09:25:00.000+03:002009-04-07T09:25:00.000+03:00Distribution cycle, but also upstream project cycl...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.<BR/><BR/>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.<BR/><BR/>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.<BR/><BR/>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.TJhttps://www.blogger.com/profile/17762291681744356830noreply@blogger.comtag:blogger.com,1999:blog-31939153.post-40701783119899746692009-04-06T23:19:00.000+03:002009-04-06T23:19:00.000+03:00To which release cycle do you refer to?The distrib...To which release cycle do you refer to?<BR/>The distribution cycle or the upstream project cycle?<BR/><BR/>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.<BR/><BR/>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. <BR/><BR/>-jefJef Spaletahttps://www.blogger.com/profile/11439754449677675460noreply@blogger.comtag:blogger.com,1999:blog-31939153.post-17245151596902365802009-04-06T19:53:00.000+03:002009-04-06T19:53:00.000+03:00It was just a quick note that first of all Fedora ...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.<BR/><BR/>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.<BR/><BR/>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.TJhttps://www.blogger.com/profile/17762291681744356830noreply@blogger.comtag:blogger.com,1999:blog-31939153.post-45858550419740352782009-04-06T19:24:00.000+03:002009-04-06T19:24:00.000+03:00Uhm...I'm not sure what you are trying to say in t...Uhm...I'm not sure what you are trying to say in that last paragraph.<BR/><BR/>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. <BR/><BR/>http://transifex.org/wiki/Development/Crew<BR/><BR/>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.<BR/><BR/>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. <BR/><BR/>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?<BR/><BR/>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. <BR/><BR/>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. <BR/><BR/>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.<BR/><BR/>-jefJef Spaletahttps://www.blogger.com/profile/11439754449677675460noreply@blogger.com