Blog

Last week I delivered the C/SIDE Development course for partner community in Zagreb. As always, questions abound afterwards. Today, I’ve got a question from an attendee: “What’s the best way to print a report in multiple languages?”.

Up front: this is NOT a technical post. It IS about technical solution, but it is primarily about design, usability, standards and best practices. I’ll plain ignore the fact that it does use a few C/SIDE or C/AL references, so please, do likewise 😉

(I said this because I kind of swore not to C/AL around this blog anymore, but again – sometimes I just have to do it.)

The question went: For foreign customers I sometimes want to print an invoice in their language, but sometimes I want to print it in Croatian (it’s the language spoken in this tiny corner of the world). Should I add options Print in Croatian, Print in English, or do something else?

Of course, there is standard functionality on customer/vendor card: go to Foreign Trade tab, and notice the Language Code field. It is used to specify which language you use in printed documents for such customer/vendor. However, it automatically prints the document in that language, no questions asked. If a customer has DEU set as their language, the documents will drücken auf Deutsch, no matter what (of course, provided all your CaptionMLs sprechen Deutsch.)

So, obviously, we need something else. And we need something that would play along NAV standards.

The reason why you shouldn’t do options such as Print in Croatian, Print in German or Print in Klingon is that it is downright hardcoding, and we all learnt long ago that hardcoding is bad, really bad. (Hint: these two are links, you can try clicking on them.)

So, what else can you do? There are many design choices you can do, that are closer or farther away from NAV standards. Here are a few suggestions:

1. Request Options tab option: add a control to the Request Options tab, have it look up values in Language table. In main OnAfterGetRecord trigger, instead of standard language setting functionality, add your own code which sets the language to the language specified in your freshly added option, or if the option isn’t set, sets the language the standard way (by taking it from customer/vendor).
2. Set of Request Option tab options: add several controls to the Request Options tab, and have them all look up values in Language table. Add another loop data item linked to Integer virtual table, call it LanguageLoop and filter it to trigger at least once, and at most as many times as there were languages set. Have its OnAfterGetRecord trigger set the language to the respective language chosen in the respective option. This is ugly, and I don’t like it, because it violates basic design principles with having a limited number of repeated controls for something that can have an unlimited number of repeated options. However, NAV is full of such things (ever seen Shortcut Dimension 1 thru 8 Code? Or report 5600 Fixed Assets Analysis?) Furthermore, it is highly unlikely that anyone would want to print a document in more than two languages at a time anyway.
3. Weirdo #1—Language list: link the Request Option form to Language table through its SourceTable property (yes, you can do that), and make it temporary through SourceTableTemporary property. Now do the same kind of loop data item as in suggestion #2 above, and have it loop through as many integers as there have been languages specified in the temporary table (don’t forget to fill the temporary table with the default language!). This one doesn’t violate the design principle of not limiting the unlimited, but violates common sense. And is somewhat exotic, admit it.
4. Weirdo #2—Language setup: if you really feel masochistic, create two tables Printing Language Setup Header and Printing Language Setup Line. The former has only the Code field, the latter has Code and Language Code fields. Create corresponding forms. Add Printing Language Setup Code field to customer/vendor tables. Modify the reports so that they display the Printing Language Setup Code control in the Request Option form. Add the language loop data item (explained in suggestions #2 and #3 above), and have it loop through all language codes from specified Printing Language Setup Code from the Request Options form, or if no code is specified there, to use Printing Language Setup Code from customer/vendor master record, or if that one isn’t specified, to use standard NAV language setting logic.

Whoa. #3 and #4 are monsters. #3 is totally non-standard, as well, and even though it does what it is supposed to do, it’s ugly and non standard. Um, now I’m repeating myself.

#4 is the cleanest of all, since it doesn’t violate any standards; on the contrary, it plays nicely along NAV standards, design principles and program logic, and it is scalable as it can satisfy any kind of language printing fetish. But honestly, who needs this? United Nations General Assembly doesn’t use NAV, and I don’t think this feature would sign them up anyway, so…

Go for #1, it’s the simplest of all, and will probably meet all your needs. If you need to print in two languages in parallel, plain go and print twice, exercise is healthy.