Double-byte support for non-English language.

clairvoyant

Hi all,

We are about to install additional language support for our existing NAV project which supports only Eng now.
In that case, we will have many local languages from Chinese to Russian or Turkish.

Seems because of the new database creation/installation in NAV, we have to set the language for non-Unicode program in Windows localization to the proper value for selected languages. (i.e. Chinese (PRC) for Chinese). And also that means we need to install all such databases in a separated machine. I mean we will need install separate machines for each databases which need double-byte support. (Which is not good!!!)

What I d like to ask is which languages will need to install in this way. Is there a such list provided by Microsoft ? In our case, we will need to check how many VMs we will need and hardware needs will be specified according to this VMs.

Are you aware such list or do you have any experiences with installation of NAV with multi-language support ?

Thanks in advance.

Savatage

I've read this - perhaps it will help?

http://blogs.msdn.com/b/nav_developer/a ... ing-c.aspx

http://mibuso.com/blogs/ara3n/2009/06/1 ... -2009-sp1/

clairvoyant

Thanks for the reply !

Seems the way most of people use the double-byte chars are same. Non-unicode parameter in OS is set to a proper value for the selected language. But this costs a machine and it causes to separate databases into the different machines. I mean we need to install a new machine from scratch for the Chinese database. and this system hosts only one database on one instance.

Is there any list showing that which language needs which collation and non-unicode value for OS ?

I found such list and seems it s covering all possible languages.

Does anyone of you have experience with such languages Chinese, Romanian, Russian, Turkish, Japanese, ... etc ?

Thanks.

quidamm

Curious if you've made any progress as far as getting a Mandarin character set installed? I have a customer looking to do the same, haven't worked it out yet. I went down this road before in February of 2009 - the path ended at Tectura's doorstep. They were very slow to respond and ultimately sent a price sheet that had the Mandarin character set for $7250!! This was required to be purchased on top of the Language add-on for the license from Microsoft for $2784. I don't believe this included any support for getting the package installed or troubleshooting problems as they arise.

Tectura also offered a NAV China Localization Pack for another big chunk of change, again this was in Feb of '09.

My customer ultimately decided it was too pricey to go through with but recently has requested the functionality again. Of course they don't want to pay all of the above, plus the time to install, test, train etc.

If anyone has had any success or can point me in a direction I'd be as impressed as I would be grateful!

Feel free to contact me directly at dahern@intradynamix.com

dmccrae

From what I understand of the question, you would like to use 1 database only, and have clients using that database with different languages - one of which is a DBCS based language.

The success of that depends on a couple of things:

1. If you can tolerate an incorrect sorting and filtering of character data, in a least one language.
2. How you separate your data in the database.

To use 1 database you need to decide on a collation (and therfore code page) for that SQL database, which in turn will determine how character data is ordered and compared for all languages. If one of your languages is DBCS then it is essentially unimportant which collation you use in the database - strictly speaking a binary collation would be the best for DBCS alone, but for the other languages you would like to use then a dictionary choice that matches another language would be better. For example, if you would like to use Chinese, English and Romanian, then either an English or Romanian collation would make sense. If you chose English for example, then certain characters would not order correctly according to Romanian dictionary rules and that would be a compromise. Similarly for filtering - some characters would not match in a filter as expected.

If you can separate the data out into separate companies for each language, then there should be no problems with characters that do not get displayed/converted properly. Eg. A Chinese client will only ever use a company intended for Chinese, and you would never see characters in there generated by a Romanian client, then all should run fine. Of course, non-per-company tables are a problem, but are relatively few.

In paractical terms to get this scenario to work, you need to disable the Validate Code Page (or Validate Collation from 6.0 SP1) to allow a client to even connect to a database where the code pages of client and database don't match. You need to ensure that you have the language sub-folders installed for each language, and CaptionMLs to be imported for the application objects, to make use of the correct captions in forms and so on.

I know of installations were all of these factors have enabled a working system for several languages, with the only main compromise being the incorrect sorting, which is really a minor problem.