I’m Spanish speaker and my English level (as the most of Spaniards) was very bad before I went to Ireland few months for learning English. I was kind of lucky because I could have some extra English lessons at the school and they taught me some technical English at the university, although I couldn’t understand well complicated and technical papers.
I think that this is the typical profile of a computer science student in Spain. Of course, there are a lot of exceptions, but I guess you got the idea.
Well, but the Guadalinex/GNU/LinEx/Molinux/Lliurex/Ubuntu‘s users haven’t that profile at all. They usually don’t know any English at all. Most of them (we are talking of thousands of users) are children at schools, people who hadn’t got any contact with computers before using those distributions and people who know the typical few words in English to ask for directions on London or to ask for a pint in an Irish pub…
The most of our problems are about things we (developers) think are very intuitive but they don’t understand well. Even when they are explained in their own mother tongue…
Now let’s say that this people having a problem with their computers, with some desktop application. The most of the warnings and error messages are scary for them. Sometimes they say something useful, but the most of the time people with almost no computer skills or experience get scared and they stop doing what they were doing and think that the “machine” is broken… or whatever….
And now let’s see the same scenario, but with the warning and errors messages in a language they don’t understand… But this is not much better to have an option at the UI you don’t understand. They don’t use it, because they don’t know what is that about and to avoid breaking something…
If they don’t understand options or features, it’s like don’t having them, but also it gives to the user some feeling of “I can break something“.
Ok, this is not always like that. This is the worst scenario. But, trust me, this happen to the most of our users. I also could bet that this happen to non-English speaker users from any country.
All this introduction and explanation is to say: Please developers and triagers, don’t put internationalization (i18n) or localization (l10n) bugs as “Importance: low“.
We are pushing really hard to get the free desktops to the end users, to the schools, to the (non-technical) professionals and we need to have software well translated for that. But the i18n and l10n bugs are worst of having some strings untranslated.
Strings untranslated in one language are bad, but it’s easy to find people for translating those strings than find someone to understand the app’s code, the gettext and i18n stuff and then fix the code.
I think the developers need to be aware of the importance of fixing those bugs and what amount of users won’t use their cool features if they can’t be translated.
I don’t say those bugs are the most important ones, but sure they are not “Importance: low“…
I’ve seen to change this priority level in Ubuntu and GNOME, but I’m sure this is happening in more projects.
I would like to say one more thing, this time, just for Ubuntu. By now, there is no official tag on Launchpad for i18n or l10n bugs. I would like to ask you that if you report, triage, or find one of those kind of bugs and they have not this king of tags, to add it.
- i18n: For those bugs about something broken in the application that makes the translations not being working, or strings not included at the translations templates (not marked for translations).
- l10n: This is a localisation issue. Including errors in localisations, typos, etc. Adding locations and weather stations is one example. Correcting date and time formats is another.
In those cases, will be desirable you follow the Ubuntu Translations guidelines:
All translations (internationalization or localization) issues should be filled against the Ubuntu Translations (ubuntu-translations) project. From there the bugs will be triaged and assigned to the right persons and package.
You can also tag the bug with “l10n” or “i18n”.
Here is a (non-exhaustive) list of problems that should be filled against an Ubuntu Translations Project (ubuntu-translations):
- if a string from the application is not available for translation in Launchpad Translations
- if an application from Ubuntu main repository is not available for translation in Launchpad Translations
- if a translation made in Launchpad Translations is not updated in the Ubuntu Language Packs
- a source package has the wrong (or inconsistent) translation domain
- you find a duplicate template
- a template/translation is no longer used in Ubuntu and should be deleted from Ubuntu Launchpad Translations
- errors in spellcheckers or language support
You can find these guidelines and much more useful info at the Ubuntu Translations’ wiki.
Well, I hope this makes sense to someone and more developers get aware of the importance of i18n/l10n bugs.
See you soon and happy hacking! 😉