When should the programmer's spoken language be used during development? [duplicate]

Question

I'm an Italian developer, but I have a good understanding of English.

Sometimes, when developing an application targeted for an Italian audience, I wonder whether it is correct to use the Italian language in my code or not. By "Italian language in my code" I mean the names of methods, classes, comments, variables and so on.

For example, when I write code like this:

/* Attenzione: metodo esageratamente complicato */
public double calcolaImposteDeiServizi() { ... }

Do I break any sacred law of programming because I didn't write that code as follows?

/* Caution: overly complicated method */
public double calculateTaxesOfServices() { ... }

I remember a project I worked on some time ago. It was about calculating VAT/taxes/bonuses. Some of this code was dealing with concepts that existed only in the Italian economy at that moment.

I preferred to write that project using only Italian names for methods, otherwise it would clearly have become a mess understanding that VAT was Italian's IVA and so on.

By using this example, should there be some kind of rule for deciding whenever to use your language or not in code?

Did any highly authoritative programmer ever said something about this issue?

How do you make this kind of decision in your projects?

Answer 1

This is a very good question.

In general, I prefer to keep things in English, because it is more or less the de-facto standard for software development.

However, I also believe in creating domain models that represent the actual business, and the domain model should be described in terms that make sense to the business stakeholders. And if the business is not natively English, then creating an English domain model violates this principle. And what is then in reality happening is that you, the developers, invent translations which may or may not be correct.

And there are most likely terms in your business that does not translate into English.

One such example is the concept of "Sygedagpenge" in Denmark. It's a system where people with a job can get public benefits if they over a long time period are not able to fulfill that job because of a medical condition,. This word cannot be translated into any language because the system is purely Danish. Other countries probably have similar systems, but it's not the same system.

So don't try to translate very country specific domain terms*. Whether or not you then write the entire domain model/business code in the native language of the business, or if you translate as much to English as possible, only keeping the untranslatable words in the native language of the business is up to you**.

But creating the entire domain model in the native language of the business will help you, the developers, to better speak the business language with the business stakeholders.

But personally I would keep all non-business code in English, e.g. infrastructure and gui code.

* Given that you say that you work with taxes, vat, etc. I guess that you do have some country specific terms, as you are probably dealing with rules dictated by legislation in your country.

** The system I am currently working on, most of the domain model is in English, but we have a few concepts that cannot be translated, so we have kept those in Danish. I think this approach is working pretty well in our case. But that doesn't mean that I would prefer that approach for the next project.

Answer 2

I prefer English with some little exceptions.

Why English:

• If you communicate with other developers its easier for them to understand your code. For example, copy & paste Italian code to stackexchange.com is time-consuming if you have to translate it before publishing.

• Many technical terms are in English. So translating this terms from English into country specific names is more complex than to use ready-to-use English terms.

• If you have a country specific domain model ask English native speakers for corresponding English words for your domain. It's very likely that somebody used this terms before or there may exist very descriptive and expressive English translations as well. Moreover you can verify your English business terms as well as your domain model, because English natives speakers often ask for background information that you first often don't consider yourself.

• If you want to search over your codebase (file search, member search, search & replace ...) its easier to realize, if you have a consistent language. Imagine you search for classes that have to do with taxing: its more easy to search for the two nouns tax and VAT than to find out the waste number of corresponding Italian, Japanese or Danish nouns.

• If your project grows up and you have to involve external developers, save them the pain to translate your code.

• Some compilers or tools don't like special characters. So it's better to use the minimal set of English letters.

• Improves your own English ;-)

When not:

• If you have very special country specific terms or personal nouns, its better to use the personal noun, because its most likely that English native speakers wouldn't translate it as well, think of street names or some public holidays for example.

• Comments I always write in the language that the main audience[1] speaks, because the intent of the code should be the code itself. The intent of the comments is that the main audience can understand the intent of the code more easily. So if the main audience speaks Russian, write the comment in Russian. Moreover coding in English and writing native comments gives a better and consistent understanding of code for the main project members.

My decision rule:

for Code

Imagine you will write a book, that you write for mass consumers: If you would use the native word then use the native word in your code as well. If you would translate it into expressive English term so that your English readers can feel the meaning, so also use the English translation consistently in your code base.

for Comments

Write comments for the audience[1] like a reviewer a review in the language that the audience can feel.

---

[1] Audience aren't users! With audience are meant developers, reviewers, maintainers and persons who have to handle the code!

Answer 3

It depends on the company you are working for. Many companies will ask for English only source code, since it has more value this way (you can outsource features to other countries with lower support costs). Some will accept local language for specific reasons:

• in the business layer, you may find it hard to translate business specific terms. Using English may bring some trouble when modeling the domain layer because each developer has to create his own vocabulary, unless a standard is defined and used for the team
• the company is not planning to outsource its development work

Answer 4

My rule of thumb is to describe what the method does to a rubber duck in English. If I have to use a Hebrew word because there is no English equivalent, then the method name is in transliterated Hebrew. If I can describe what the method does in English, then the method name is English. Try to keep English as the default, and Italian as the rare exception.

Just don't do half-Italian, half-English method names. That confuses everybody, including yourself when you go to maintain it six months from now!

Answer 5

Previously I did a 2-month QA internship at a software company in the USA branch, but HQ was in Japan.

All of the functions and variables were written in English (though this is easier for Japanese people since they're taught English as a second language), but all of the comments and documentation were in Japanese. When we started to build on top of certain modules, we would append comments in English. It would look something like:

/*
日本語 comment
--------
English comment
*/
void doSomething() { }

If working in an environment where everyone speaks one language, feel free to use that language. If working in an environment where two or more languages are used, it's best to use whichever language is most universally accepted by all parties, which usually ends up being English, but can be different.

Answer 6

I'd say use English, but it's more complicated than just saying that. I'd not use public Money calcolaIVA() for the same reason that I would not use public Money calculateVAT(), they're too specific to the domain.

IVA and VAT are domain specific terminology that only applies to each respective country. Even when different countries use the same terminology, they often have slightly different rules that it does not really make sense to use domain-specific terminology here.

Instead, I would use public Tax[] getAllTaxes(), and use an strategy pattern to choose, in runtime, between ItalianTaxRules(), UnitedKingdomTaxRules(), USTaxRules(), some_country = SimplePercentageTaxRule(0.05), etc.

Each strategy then can use domain specific terminologies in the target language for nouns in comments and class names, because translating domain-specific nouns would almost always introduce confusion and ambiguities even for people who do not speak the language.

Public methods between the Strategy and Context should always use generic terminologies in English. Private methods within the Strategy itself can use domain specific language as appropriate, but I would have just used English verbs with localized nouns private Money calculateIVA() {} rather than private Money calcolaIVA() {}.

PS: replace English above with "The Common Language". "The Common Language" is the language you expect ALL maintainers of the program now and in the future will speak. In most situations, the only reasonable choice for this is English, but there may be situations where it make sense that "The Common Language" be another language.

Answer 7

I would personally always use English.

• English is a de facto reference language for development (among others).
• The third party liraries or web service API are written in English. I feel that mixing language in that case is a bit ugly and confusing.
• English is also spoken worldwide so it is generally chosen by persons speaking different language to communicate. This point is the most important for me because I live in a country with three official languages and many foreigners working as developers. It is by consequence quite common that members of the dev teams speak different languages. Furthermore I often worked on projects developed or going to be maintained abroad.
• If you intend to create libraries, web services..., it is obvious that API and documention in English are required if you want it to be used worldwide..

As mentioned in other answers, there are some restrictions, of course, such as specific terms that are hard to translate in English, but it remains quite exceptional and shouldn't make you prefer another language.

Answer 8

I'd say you should do whatever works best for the people who are going to be looking at your code. The purpose of method names, variable names and comments is to make the INTENT of your program clear.

If you can reasonably expect that the only people who will be reading the code will be Italian speakers, the why the heck make them try to puzzle out English translations? Furthermore, if English is a second language for you, then trying to translate everything is likely to lead to less clear comments and names than if you'd stayed with your native language.

If, on the other hand, those who come after are NOT expected to be native speakers, then English is probably a good choice as a second language.

Answer 9

I do some programming myself (although I'm primarily a sys-admin) and we've got a large software development team here on site.

We have a clear consensus among the people here:

In general the programming language itself has its basis in English.
Using non-English names for methods, functions, variables, etc. is therefore, in our opinion, to be avoided to prevent the author AND the reader to having to switch back and forth between 2 languages.
Mentally juggling 2 languages is in general not good for overall understanding and tiresome too.
The added benefit is that getting another programmer working on the code is easier as just about any programmer can be assumed to have a working knowledge of English. (Note: Working knowledge doesn't equal "good". But usually it is good enough to get by.)

Writing the comments in another language is also to be avoided, for exactly the same reasons.

The ONLY exception to this the is naming objects, functions, variables that have a very specific meaning in the context of the program and the language of the target audience.

The example already mentioned of a tax that only exists in Italy is a very good example to illustrate this: It makes no sense to try to translate the Italian name of that tax into another language. To really emphasize this is specific to Italy the Italian name stands out and makes sure, at some later point in time, no programmer is going to confuse it with another (more general) tax also mentioned somewhere in the program.

Answer 10

As quite a few other people say, English is pretty standard. You might have to think of what the lifetime of your code could possibly be.

Some time ago I worked in the Indian development office of a multi-national European company and my team members were interspersed amongst some developers from another team on an unrelated project, but we all got to hear each others' team's discussions and issues. The problem the other team had is that this gigantic company had bought a tiny Finnish start-up (or just bought their software, I'm not clear) that wrote all their code in Finnish.

None of the Indian team members spoke a word of Finnish. They spent months and months trying to translate the code, or at least, the non domain specific parts of the code. Lots of search and replace, recompilation, errors, fixing, errors, recompilation.

All in all, due to Finnish vs English, the company didn't get any productive use out of their purchase.

Answer 11

I would say never.

Is better for you and for the maintainer to have a common language (english). you don't know when your language will not be able to express what are you doing, I speak 4 different languages. I don't master english, is not even my best language but any commentary or definition fits better in english than any other.

And I must add, this can help improve your understanding of technical English , your ability to understand global forums which probably will not be in italian.