The Forums on slxdeveloper.com are now retired. The forum archive will remain available for the time being. Thank you for your participation on slxdeveloper.com!
|
|
SalesLogix Multi Language
Posted: 04 Sep 07 10:09 AM
|
Good Morning
Here is my situation: I have a customer that uses SalesLogix (7.0.1) in English. This customer has offices in many countries such as Russia and China.
They need to have a way to add Contact Addresses but in their languages - Russian and Simplified Chinesse - It may be done with an additional one to many table -
They are running Oracle 9.0.2.7 - Also all contact information will remain in English. This is not a localization issue, they have to be able to habdle multiple languages in the DB.
Thanks in advance for your help
Regards,
Agustin Galindo
 |
|
|
|
Re: SalesLogix Multi Language
Posted: 17 Oct 07 8:55 AM
|
| I have a similar situation requiring the need for multi-byte character data storage (Japanese and Chinese languages). I was informed that SalesLogix would support this but I havn't heard any concrete response how this would be done. Since SLX does not support Unicode data, how would these languages be stored in the DB? |
|
|
|
Re: SalesLogix Multi Language
Posted: 18 Oct 07 9:46 AM
|
We have handled this by setting up China in a separate db hosted in China. I can provide details if you want to email me directly, but I'd rather not post the whole thing publicly.
Rick |
|
|
|
Re: SalesLogix Multi Language
Posted: 19 Oct 07 11:06 AM
|
A suggestion given to me was to change my DB to Cyrillic. That particular setting can handle multiple languages. I moved to another job before I had the opportunity to fully investigate - but the source was Stephen Redmond.
I handle only English and occasional Japanese here. One of the things I use with SQL is the literal ( N') preface and the nVarChar data type. (Is it the same in Oracle???) This works beautifully for the areas where we store Japanese. If addresses are the only area you will be handling 2 byte characters, this may be an easily implemented. If you will be handling them everywhere the customizations would be too intensive. 
Carla |
|
|
|
Re: SalesLogix Multi Language
Posted: 15 Jan 08 2:36 PM
|
I have documentation on how to add multi-byte language support for the SalesLogix Application. One issue with multi-byte however is that you can only have one multi-byte language per machine and the raw data is translated to whatever the code page indicated is.
i.e. if you enter a Korean address on one client, then goto another with the Chinese code page installed, the sales client will translate the Korean characters (character by character) into Chinese - which may ready as gobbledegook to the Chinese client.
If you would like this documentation please let me know, it took several months for us to find the right resource inside Sage to help us with this. I would need to e-mail it as it is approximately 3MB zipped.
Another issue is the SalesLogix control set. It cannot handle - reliably - a databind to the nvarchar or ntext type. Trying to bind to those datatypes using the SalesLogix controls WILL introduce errors (tested by myself) and not reliable ones. You would also be required to create the table outside of the db manager then enable it - which you can only do if using SalesLogix 7.0 or above. |
|
|
|
Re: SalesLogix Multi Language
Posted: 14 Feb 08 3:54 AM
|
Hello Matt,
I would be very interested in that documentation. Did I understand correctly that I can change the client to multy-byte langueage but still have a Global server?
Thank you very much!
Best regards,
Kai von Borck |
|
|
|
Re: SalesLogix Multi Language
Posted: 14 Feb 08 9:14 AM
|
Yes you can Kai, there are only two real concerns as far as I see from SalesLogix's multi-byte support:
1) When storing multi-byte characters, field size is effectively cut in half (i.e. a 32 character field would only store 16 multi-byte characters)
2) all multi-byte languages are reduced to the same byte codes, this means if you store Chinese, a Korean user could have the Chinese text (improperly) displayed as Korean (because the region settings code page found bytecodes and tried to translate them). This could result in, at best, gobbledegook (useless strings of letters/numbers) or at worst, some inadvertently profanity laced diatribe 
I will send the documentation to your email address. |
|
|
|
Re: SalesLogix Multi Language
Posted: 20 Feb 08 1:13 PM
|
Hi, Matt.
I have a client that is inquiring about Chinese language support and your posts are the most imformative that I've found. I can't seem to find anything on the SalesLogix Knowledgebase and I'm striking out just about everywhere else I look. I was wondering if you could send me the documentation that you found on this. Your help is greatly appreciated!
Thank you!
Melissa |
|
|
|
Re: SalesLogix Multi Language
Posted: 20 Feb 08 1:20 PM
|
I should probably just post the documents here but I'm not sure of the legality of that.
I sent a message to your profile. Just let me know if you have any questions and have a great day! |
|
|
|
Re: SalesLogix Multi Language
Posted: 26 Feb 08 9:58 AM
|
Hi
I am using Sales logix 7.2 via citrix presentation server 4.5. I have a problem displaying characters on saleslogix for the the central european countries countries like Slovakia, Czech Rupublic Hungary etc. How can i resolve this problem? please help
Dipesh |
|
|
|
Re: SalesLogix Multi Language
Posted: 29 Feb 08 9:49 AM
|
I'm not sure of those languages characteristics, but it may be that, if each one of those is a multi-byte language in itself, that you have to go to a citrix farm, with one citrix server per multi-byte language.
The reason for this is that SalesLogix multi-byte language compatibility utilizes the Windows systems regional settings. Since you can't have more than one regional setting (language wise) per machine (although you may be able to do so with Citrix, Lord knows I'm no citrix expert).
I will be editing, paraphrasing, and adding to the documentation I have and uploading to this site later today and will post a link when I do so. |
|
|
| |
|
Re: SalesLogix Multi Language
Posted: 03 Mar 08 7:11 AM
|
Hello Matt,
Thank you for excellent article "Setting up a Multi-Byte Environment for SalesLogix".
As living in a country where localization issues were primary task for IT in the past 20-10 years I come myself to most of your recommendations.
We use highly customized installation of SalesLogix v. 6.2 working with SQL2000sp4. Our team is also new to SalesLogix.
After setup Regional settings and AutoTranslate as you recomend, now we can store and read field in local language.
One of the issues I come to is that searching is not working with fields, entered with local language values. I do not create multi-byte setup yet.
Next step is to customize print reports, to be formatted for local language (code page 1251) and find solution (if it is possible) for search within accounts/contacts entered with 1251 character set.
Any suggestions for Searh feature and customizing print reports?
Best regards,
Nikolay Penev
Sofia, Bulgaria
|
|
|
|
Re: SalesLogix Multi Language
Posted: 03 Mar 08 9:25 AM
|
Search is a BIG issue with this localization type, because the code pages and collation orders don't match up (always) with the localized language, you will find things 'mis-ordered'.
The only real strategy I've been able to come up with to combat this is to use localized picklists as much as possible - leaving only the free form text fields un-searchable. There is a drawback to this in that the use of these picklists essentially removes the ability for non-super users to create groups/list views as they get fairly complex.
|
|
|
|
Re: SalesLogix Multi Language
Posted: 04 Mar 08 1:45 AM
|
I have tried change collation technique in the past with other databases: change database collation to Cyrillic_General_CI_AS or SQL_Latin1_General_CP1251_CI_AS and in most cases it works, including search/ordering.
The problem is that in our case we have stored procedures and trigers, requiring collation Latin1_General_CI_AS. Probably that change will be the best solution (also solving the search issue), but first we should check all the stored procedures for collation requirements.
This also may break the ability to directly apply future updates to the database.
best regards
Nik |
|
|
|