In my little miniseries here of things we can do better I would like to put focus on another conceptual issue that we really need to deal with too.

Code and Translations are 2 very different things and they should never be mixed. Okay I said it and maybe I will get a little verbal beating for doing so, however it doesn’t make it less true.

The way we deal with translations today by putting them into the compiled objects has its roots a very long time back in the application. Long before Dynamics NAV had a service tier. Long before we had even considered SQL as a database platform and maybe it is time to rethink that again. I am not saying that they did it wrong when they created translations the way the work today, but I am simply saying that the times has changed and so should the product.

Purely form a conceptual point of view Code and Translations should never be mixed. It is simply a bad practice.

Now we can technically already do this as we can host the translations on the service tier and not include them in the code, however this is not the standard way and unless you work with a country that needs this, we hardly ever see this in any install.

You can read all about how this is done on MSDN here:http://msdn.microsoft.com/en-us/library/dn479852%28v=nav.80%29.aspx

Now at this point Microsoft doesn’t recommend this unless needed because it is slightly slower than using the translations when compiled into the objects. So you have been warned… J

In a side note when it comes to this discussion: “Why do we handle translations the way we do?”

Take a word like “Customer”. The word is translated many times because it exist in many locations across the code, but why do it that way? This is not a very efficient way of handling the translations and it would be far more efficient if we stored this translation once and pointed to it many times based on need. This would also greatly help when a given translation needs to be changed by a partner for a given vertical as I am sure many of you have tried.

I want to see our great product become even better than today. We need to constantly improve to stay in the lead. Removing these simple inefficiencies, so partners and developers can concentrate on building great products, will surely benefit us all.