Code "internationalization"

Question

I worked on different projects in different countries and remarked that sometimes the code became internationalized, like

SetLargeurEtHauteur()                            (for SetWidthAndHeight, fr)
Dim _ListaDeObiecte as List(Of Object)   (for _ObjectList, ro)
internal void SohranenieUserov()             (for SaveUsers, ru)
etc.

It happens that in countries with Latin alphabet this mix is more pronounced, because there is no need of transliteration.

More than that, often the programming "jargon" is inspired by the project specifications language. There are cases that terms in "project language" have a meaning that is not "translatable" in English.

There are also projects on which works only, say a French team, uses French words (say, Personne, Vehicule, Projet etc).

In that cases I personally add in specifications a "Dictionary" that explains all business object names and only these objects are used in other (French) language.

Say:

Collectif - ensemble des Personnes;

All the actions(Get, Set, Update, Modify, Load, etc) are in English.

Now that "strong" names could be used in code: AddPersonneToCollectif.

• What is your approach to "internationalization"?

_{PS.
I was amused that VisualStudio compiles and runs projects in .NET with buttons named à la "btnAddÉlève" or "кпкСтоп"...}

Answer 1

My personal approach, which is shared by many but not all in the programming community, is that source code should be in English and, if possible, all the development tools should be in English too.

The most important reason for this is being able to share your problems and solutions with the world (like we are doing now in StackOverflow, no less) without having to translate class names, error messages, paths and other artifacts every time.

It also helps consistency, because most libraries are written in English and having element names that mix two languages doesn't really help anyone, besides being a constant focus of internal conflicts when a verb like Add isn't always traslated.

English code also makes it easier to add foreign people to a project without worrying about comprehension and misunderstandings (especially between closely related languages, like Spanish and Portuguese, which have lots of false cognates)

A good link on this subject: http://www.codinghorror.com/blog/2009/03/the-ugly-american-programmer.html

(In case anyone wonders, I'm south-american and English is not my primary language)

Answer 2

Even if everyone on the team is a good English speaker (which is not a given), they may not necessarily know the English equivalent of all the business terminology.

I think it's a project-specific decision what to allow, but I would generally tolerate and in some cases encourage business terms (e.g. entity names) in the local language, but not technical terms (i.e. not Largeur/Hauteur instead of Width/Height).

For example in the financial world in France, everyone knows what is meant by OPCVM and FCP - if you attempt English translations you might end up with more misunderstandings than you do by allowing mixed languages.

Answer 3

I have the same issue with Norwegian currently. I guess it depends on your position in the project, the available time and the role of the software.

In my case, I have decided to keep all terms in an existing protocol and library I am working with in Norwegian, as I can reasonably expect that generations of administrative workers have gotten used to these, and since the library depends on the protocol. In a library wrapper for an international project, I have translated each method name literally, and added an English language documentation of the method.

Comments and documentation on the code are in English.

If designing a software from scratch, I would try to find English terms for all method names and even business terms (if reasonable. I can hardly think of an example where no term can be found though.), to keep it "portable".