I’m currently managing a global implementation of Microsoft Dynamics. When our project is finished we might very well be in approx. 50 countries with our Core.
We are running our project after the single code version devise. That means that we are putting all localizations into one global code version (could be one database, but this has not been selected for performance reasons), which means a lot lower cost of maintenance. But this is not my question.
The issue is now that many of these countries now require that they get their own local language, i.e. Chinese (both Traditional and Simplified), Thai, Spanish and Portuguese.
We want to use the translations already provided by Microsoft where available and implement the language layers into the objects in Dynamics NAV.
The actual questions is: Should we integrate these language captions/texts into our development version, or should we do this after?
I’ve looked at the Mergetool from Per H. Mogensen (available in our download section). And this has a very fine support for language handling in it’s latest version. But Per Mogensen’s suggestion was to do this after our development version - on our ready to release version only. My problem here is that I see that this would delay our releases with at least 3-4 days, as we need to test every release completely. The other option to have it directly in the development version, would mean that we should handle every language text update as a modification to our solution, just like any other modification.
Do you have knowledge of how to handle this? Or do you even have experience in doing this large scale? Then I would love to hear from you. Although I might like to pay you to do this for us (if you have the golden solution - we are actually planning to hire a localization and language/translation coordinator for a full time job), then I would like to hear your suggestions here for the benefit of all other users.
The few times I have made projects there involved translating always was adopted to make it in the end. A project that had translation being made at them same time of development, when it reached to the end there were still missing some translations. So it was still needed to make more translations and more tests. I think there isn’t nay magic golden formula to achieve an effective translation.
Yes. Naturally translations will be an ongoing process, as we also will continue to develop the system and add more functionality. But the question is more, if we should integrate the translation in the version our developers are also working on and testing on, or if we should treat the translation as an entire separete task in the end of our release process.
Hello Erik,
I’ve been working on some multilingual projects like Yours (6-7 different languages).
From my practice it’s better to make a seperate task for translation process which might go AFTER the core adopted for country needs. The steps I did:
Core is fully ready and special programming for a seperate local base needed.
Finish programming all the features using English language
When modified cores for each country is ready you must start localization task process:
a) First of all import language layer
b) Use the technique for translating Your own addons (don’t forget that there could be some problems with options and tabs in forms, after everything is translated you will need to make a testing process to check if localized objects works fine)
Currently for the step b I’m doing special solution to parse objects and search where translation is missed, cz I’m bored of the “localization tool” it gets me nervous:)
So as You can see translation process must be the last task (in my oppinion).
My main concern is really that this process will slow the periodically update process down a lot. We currently have approx. one go-live per month, and besides the regular and scheduled monthly release (new functions, reports, error fixes etc), then we also must be able to handle the irregural hot fixes that happens at least two or three times per month. And if we should do it as a post-development-phase process then it would mean that either it would take a lot more time to make hotfixes, or alternativly that objects which were hot fixed does not get the language layers…
Hello Erik,
It’s really difficult thing to manage all these processes, even where are too many languages … but there are no way out. As for me the fastest way would be to make a seperate task for global translation before live start and for the future translations define a periodic tasks for missing translations check for doing a batch fixing and applying fixes for a defined period.
Every situation is different, so I think its a good idea to get as many opinions as possible. I can see valid cases for diffetn projects to go either way. Core would be comparing the size of the project, and the complexity of language issues vs development issues.
I think the division of tasks is a key issue in your case. Because of the size of the project, you really need to separate the tasks, and that means get the code implemented and testing in an English environment, and only do the translation once all is ready for release.
You also need to introduce strict rules in design, things like DON’T add an Selection to an Option string, even if its one of your custom fields, or at least a good procedure to make sure the option is handled in translations, but I think you already have that under tight control knowing your strive for perfection [:D].
Although if it was me, I would much rather have the tasks in parallel, i.e. one big multi lingual system, I think that to achieve a high quality translation you are going to need to do it as a two step process, especially since you are outsourcing the translation process.
Well actually your comments lead me more towards to the other direction. We have a Core Project setup with a rather strict design and implementation methodology. All code done by any of our external developers (we are only using external developers) is QA’ed according to the standard. Everything is already tested at least three times before it’s getting released. So we should actually have the process in place to do it in parallel (treat it as development - and keep the language layers in the Core base versions).
if you have external developers to do the development you are probably aware that they are not able to do the translation and adding the ML captions at the time of development? I would be surprised if you can come up with several external NAV developers that are able to cover all of your languages :).
In my opinion translation should be done after you have QA’d objects.
You’re right. Not many developers (if any) would be able to cover all these languages. And in now way I would expect that my developers where good at more than English and C/AL!
The major question was really if we should split the code into two databases and handle the releases in two tasks. This means that we have a development only database (without any other language codes than ENU), and then we would have a language-release database including the translated texts.
To add on to this conversation… what about collations? Since a SQL database only supports 1 collation (pls correct me if I am wrong here…) that would mean, I can only run 1 double byte language per database. I will not be able to run mutliple double byte languages in 1 database.
For example… I would not be able to run Chinese and Thai in 1 database.
Hi - I read your posted details about NAV. I have a question for NAV 2009 -Chinese Language pack. One of my clients need to have chinese language addons. My problem now is - what is the step by step procedures to do this… Can anyone suggest me …
Quite a bit off topic! It would have been better to start a new topic, especially since the last post in the thread is more than 3 years old.
But I’m not really sure what you are asking. What do you mean by “Chinese language add-on”? Are you talking an add-on to get your whole NAV 2009 translated into Chinese or are you talking about getting a Chinese add-on?
If you are talking about the first, then you need to buy the Chinese Language Pack. It used to be available from Tectura East Asia, but there might be other partners who have a Chinese Language Pack. I don’t think that Microsoft has an official Chinese Language Pack.
… but there are no way out. As for me the fastest way would be to make a seperate task for global translation before live start and for the future translations define a periodic tasks for missing translations check for doing a batch fixing and applying fixes for a defined period.