i18n bugs are important too

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! 😉

6 thoughts on “i18n bugs are important too”

  1. I wonder why should I open bugs on Ubuntu when *upstream po files are correct* but they always break the pkg with incosistent downstream and old translation files…

    1. Hummm… I don’t sure I get your complain…

      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 😉

  2. You can do that post much shorter:

    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.

  3. I’m with you at 200%. I usually post many i18n/l10n bugreports and almost always they’re marked as low priority, which breaks one of the main Ubuntu principles:

    “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!

Comments are closed.

Creative Commons Attribution-ShareAlike 3.0 España
This work by Juanje Ojeda is licensed under a Creative Commons Attribution-ShareAlike 3.0 España.