One big issue with translating a software in a language, even if that is your first language, is that you might not be sure of which term is used to translate a given one in, for instance, English. This is even worse when a given software is targeted to specific areas of interest that might not be common knowledge.
You can read this quite interesting entry on Michael Kaplan’s blog shows that even Microsoft can get localisation wrong (and mind you, Microsoft and Apple seems to pour money and money on localisation, and are usually better at localising than Free Software, although there are more chances for amatorial Free Software to be translated than non-Free “Gratisware”). And in particular, quoting Michael:
This does not speak against linguists as linguists, but it can be looked at as speaking a little bit against linguists as localizers, since the skillsets and what makes people great in these two very different jobs are not entirely overlapping skills.
So this dos not really mean that you need to be a linguist, or a professional translator, to be able to properly translate software. Which is nice, especially for Free Software.
But you certainly have to find a way to handle properly terms that are specific to an area. It’s common, in textbooks translated in the ‘80s from English to Italian, the word array, in programming, was translated with “*schiera*”… which is right, linguistically, but it’s horrible to think of. Today, array is left in English, and written in italic. Similarly for directory and direttrice (most of the younger italian people around will probably think I’m lying, but it’s unfortunately true).
One way to come around this is to use a glossary that provides translations for common terms in multiple languages. It’s not an idea of mine, I read the existence of it again on Kaplan’s blog, unfortunately when he was writing that it got removed from Microsoft’s website.
Another way that is more common in Free Software, and that should really really really be used more, is to centralise some of the user interface handling. KDE and GNOME use this by just defining a series of default actions and dialogs, so that they can be reused in different software, providing the user with the same text (modified when it has to be, for names of software or other details like that), and only requires one translation at once.
This would also be nice to be applied to ebuilds. Present the user the same interface, similar error messages when an USE flag has to be updated, try to reduce the amount of new text that every ebuild, init script or other script that users need to interface with.
This would be a nice first step to have, in the future, internationalised ebuilds. Yes there are tons of messages to transltae, but they usually don’t change so much, and if we can get a more externally-accessible repository, say, with GIT, in the future, we can get translators as well as proxy maintainers, to commit on their own the translations for USE flags documentation (metadata.xml) and for ebuilds’ messages.
Update (2017-04-28): I feel very sad to have found out over a year and a half later that Michael died. The links in this and other posts to his blog are now linked to the archive kindly provided and set up by Jan Kučera. Thank you, Jan. And thank you, Michael.