“Ubuntu includes the very best in translations and accessibility infrastructure that the Free Software community has to offer, to make Ubuntu usable by as many people as possible.”

as well as one of the core philosophical ideals of the Ubuntu Philosophy of Software Freedom:

“Every computer user should be able to use their software in the language of their choice.”

I complained about this situation in the past Ubuntu Translations Meeting on 2009-07-02. You can see the details in the wiki:

https://wiki.ubuntu.com/Translations/Meetings/2009-07-02

My opinion is that the creation of the new Ubuntu Translations project (https://launchpad.net/ubuntu-translations) will contribute to increase the importance of the i18n/l10n bugs. I also think that having David Planella as the Ubuntu Translations Coordinator will improve the things a lot. I hope so!

https://bugs.launchpad.net/ubuntu/+source/aspell/+bug/379971

Number of English speakers of any capacity, highest estimate: 1.8 billion.
Total number of potential users for your software: 6.7 billion

I18n isn’t just important in terms of bugs but also a design consideration. Better strings makes for better interfaces and superior application experiences. If you want a piece of those additional ~5 billion users you need to work with translators from the day you start designing your program, keep the strings short and neat, let them stop you from bestowing insanity upon your users (see: Evolution). If you fail at taking i18n into consideration from day one, you risk losing out on 5 billion users, and remember i18n reviews cost you the developer only a polite mail and the time it takes to improve your program as a result from feedback. The cost of having an overly complex collection of redundant strings on the other hand is coming in last on the lost of programs volunteers will translate.

I wasn’t talking about Ubuntu (well, just at the last part for some specific stuff), I was talking in general about i18n bugs that are already filled in upstream or downstream.

IMHO, if those upstream po files are correct but they breaks at some dowstream project (Ubuntu, Debian, Fedora…) the bug should be filled at the downstream project.
And a lot of problems are not just with old translations or mess on pkgs, but also with some upstream code that doesn’t support i18n or doesn’t mark some strings for translations or that just breaks something with i18n support.
Those kind of bugs should be filled upstream.

Anyways, I don’t really think your complain fit with the idea of the post… Or maybe I didn’t undertand you wel…

Thank for the comment anyway