Looking for feedback as always.

As you might know (or not) we ship a set of standard reports with ForNAV which are optimized for the product.

With these reports you’ll also get a set of tables, pages, codeunits and in the next version even a query.

Out of the box, ForNAV is translated to all the NAV 2018 languages plus Portugese.

For sure we also like to translate the standard reports and we want to do it right.

The LCS Translation Service

I’ve taken a look at the LCS Translation Service provided by Microsoft. This service runs on XLIFF files which is an optional format for Extensions.

Since our product still runs best on C/Side (you could run it as an extension if you so desire) I figured I could still use LCS and convert XLIFF back to C/Side as long as the translation is ok.

If you google on this subject you land on the blog from Gunnar and he has an example result on his GitHub.

The screenshot shows the result of the translation by LCS to Dutch and this would not be something I would enjoy shipping.

The Alternative

Now I am not sure if I will make a complete fool out of myself but let me share how I get my translations.

As you know standard NAV has a lot of standard tables, pages and codeunits that are translated by Microsoft. Microsoft inherrited most of the translations from Navision as the base application never changed much since 2002.

The Navision translations were always very consistent and could be trusted.

You can export the translations from C/Side and that is what I did. I’ve downloaded NAV 2018 in the languages I needed and exported the translations into a file.

The next thing I did was import these files into some tables I’ve created in NAV. Now I have my own database with translations.

Codepages

There is one caveat. C/Side is not unicode. In order to make sure I get the correct characters in my strings I have a virtual machine that runs in Danish Codepage. My Danish improves with every report I translate.

Discipline & Common Sense

The next thing I did was to go through my objects one-by-one and searched for translations. As some of our reports are from the North American version of NAV such as the Inventory to G/L Reconciliation report some of the captions don’t exist.

Inventory Value is an example of that, and so is Received Not Invoiced.

However, Inventory Value (Calculated) exists. How hard is it to remove the one word from a string and use that translation. It feels a lot safer for good results than using the LCS (which I did not try).

Receive also exists as does Shipped Not Invoiced. Common sense helps me to create a decent translation.

Conclusion

Translation sucks but it is a requirement for the succes of your ISV solution. It is to be handled with care because there is only one first impression of your application and a weird translation can destroy that.

Clean code also helps. If you try to normalize reusable code into libraries you can re-use the translations once you have it.

Please share your idea’s in the comments.