Comments - what language

Johannes_Nielsen

Hi

Quick question.

What is the best practice when doing modifications, write C/AL comments in native language - easier to understand OR in english - readable to the world.

I don't think any person outside Denmark would ever read this code.

Is it a normal practice for a serious ERP partner to comment code in native languages?

Luc_VanDyck

I prefer English-only comments in the NAV objects. You never know what is going to happen with the customer (taken over by a international group), or what add-on's you are going to implement in the future. If you need support for an add-on, which is developed outside DK, it helps that the ISV can read the comments in the NAV objects.

Belias

i always comment/write code in english. Although i generally prefer english language to italian one, there is also the concrete advantage to not have special characters (letters with accent, in italy) that sometimes are not interpreted by PCs with a different collation..
...Plus all the motivation explained by luc

pdj

I the good old days nobody used anything but their Native language developing in NAV. Before 3.0 Navision even translated the variables, to make each version very local. From 3.0 their stopped this and a lot of VARs started documenting code in English, maybe even without actually considering pros and cons. That made it a bit easier for NAV customers to switch to a different VAR in a different country, or for the VAR itself to hire foreign either cheap or highly skilled labour (in some cases even both ). Some developers might see this as a threat and therefore keep documenting in their Native language, unless directly requested.

In my current company we have a company policy requiring English documentation and field names and even text-constants, even-though for some of our customers the likelihood of them expanding internationally is less than zero.

I guess it would be necessary with a poll to say what is normal practice?

What language do you use for commenting your code? (Only for native developers in non-English speaking countries)
1) Company Policy say English and I follow it
2) Company Policy say English but I don't follow it
3) Company Policy say Native and I follow it
4) Company Policy say Native but I don't follow it
5) No Company Policy - comments in English
6) No Company Policy - comments in Native
7) No comments - "my code is self-explaining!"
8 ) No comments - "it was hard to make therefore it should be hard to understand!"
9) Other - explain below...

Other options before the poll is created? :-k

kine

We have the policy that primary language for developing is ENU, including all captions and text constants. Because I am working on many international projects, I hate the other cases. I have already seen many customizations in German, Polish, Hungarian and other languages and it is a mess. If everybody follow the rule, the live will be much easier and nicer... I remember the time, when the NF 2.60 was fully translated into Czech and the impact was big, mainly when we were trying to upgrade these DBs to newer versions...

I totally RECOMMEND to use ENU as the basic language for development (names, identificators, captions, documentation) for everybody. Event it is easier to get some support when you need it...

Belias

i fully agree kine...i am "1)" in pdj poll, and if i will change company, i'll continue to use enu as primary, even if the company says to develop in italian.
btw, sometimes it is a pain to translate every textconstant, but on the britght side, you start using functions like FIELDCAPTION etc more and more frequently because you're too lazy to do translations.
After some time, you'll also start to make codeunits and functions with the only purpose of make available common words translations that can't be found in your application, (for example "must be"/"must not be").
needless to say that programming text constants like this, make the overall quality of the development better.

Andwian

I prefer to use ENU, so that when you need a help from mibuso, just simply copy-paste the code here, and everyone could help you more.

lvanvugt

Agree with all the above arguments on ENU. I surely want to stress on Andwian's arguments which also applies in your communication towards MS.

kriki

I agree with all the arguments to have ENU as development language.

An extra reason: develop in ENU and let the functional testers test in the local language. You will find a lot of language-related bugs.

Most of my colleagues still program in Italian (English is a big problem in Italy) and I can assure you that when changing the language, a lot of language-related bugs come up : forgetting ENU-PageNamesML on forms gives a beautiful error when run in ENU, Caption ONLY in Italian, calcdate date use '+1G' and that works only in Italian, ...