1 of 1 people found this helpful
This is actually not just a LANDesk problem per se - it goes far, far deeper - it's also Windows/Database Character set problem.
I'll explain (somewhat simplified) in a way which I hope will convey the magnitude of just how deep this goes.
Problem # 1 - "I get Japanese scanfiles in, and they show up unreadable when I open them in Notepad..."
This is down to the OS being unable to display the characters of Japanese (or any other 2x byte character language really) 'straight off the bat' - it's a pretty easy thing to fix, as you just need to add the respective language's drivers, and then that works. This is usually the lesser of the problems, but still one that exists.
Problem # 2 - Database character sets.
Much like Windows itself, Database have certain character sets. There's a huge plethora of those, but the only one which I'm aware of which can cope with MULTIPLE double-byte character-sets (such as Russian + French special signs, or Chinese + Japanese) us Unicode (you might know of them as UTF8 / UTF16). Without Unicode, a specific characterset will - much like Windows in my description of Problem # 1 - show up some stuff as garbage.
This is where your problem comes from - software information is the most likely to use localised characters - on account of including strings like:
"Product" - "Bob's Software Package"
"Vendor" - "Bob's Cornershop"
... and so on, where the strings are often not in English, but in a localised language, which then increases the chances of complex characters to appear rather dramatically.
So why not use UNICODE?
Problem is that LANDesk does not support it presently. And there's more to it than this too - it's a huge change to the product to incorporate that support.
It's unfortunately not something that can be introduced into the product "on the quick", as it requires a major change to all the components which talk to the DB. As you can imagine, that's close to "all of the Core Server" - so no small feat, as you can imagine. UNICODE support is something that has been requested by some customers already (usually large enterprises which span multiple countries with 2x byte character-languages).
From a LANDesk-process point of view, it would be great if you could log an enhancement request with your regional LANDesk Support center, which will give extra weight to the existing enhancement story. The clearer a picture we have how many customers are hurting for the feature, the better its chances at being done (again, however, a clear statement that this is hardly a 5-minute or even 5-day job - a change like this is potentially capable to eat up most of a full product release on its own).
For now, however, regrettably I do not know of a way to have you successfully be able to display both Chinese and Japanese characters and not have other problems as a result of it. It is unfortunately not as simple as we'd like it to be, I regret to say :(. Very much one of those cases where it doesn't seem like much (on the surface), but is actually quite a major deal to do.
LANDesk EMEA Technical Lead.
You should always be able to get English and any one other language to work from what I have experienced.
So if you only have English and one other language, you may have just used the wrong character set.
Thank you for all your replies about this probelm.we met the Probelm #2 as you explained.
As you suggested, We'll contact LANDESK (China) Support Desk to request an Unicode enhancement and wait patiently for new version to settle this problem.
BTW:Is there any schedule by now?
The later you start to work on Unicode support the harder (more unrecoverable Double-Byte data already in DB)to take it out,isn't it?
The only other way is to have a regional install of the core so that the correct code page is supported. That way you manage Japanese systems in a Japanese core and Chinese in a Chinese core.
Slight tangent; if you had both sets of characters in the same database, how many people would actually be able to read them anyway? I see this question quite a lot in Enterprise clients as Paul suggests and very often the next question is whether we can translate those characters because they don't have people that can read all of the languages and it causes issues when some software names are in Chinese characters and others in English.
Whether you have Unicode or not, data will still be incompatible in some way unless everything standardises on one language/naming convention. Therefore seriously consider the regional cores and/or restrict your reporting expectations to items that are common across OS language versions.
Hi Paul, it has been a while since your post.
I am wondering if there is fix on the multi-language client with 9.5 release. Does anyone still seeing this issue in 9.5?
We have problems in displaying the Chinese and Japanese characters in the inventory data. It appears as ???.
But we are able to view the Japanese characters in Patch and Management windows (we have some patches in Japanese version). The issue seems to be with inventory data record only.
We are able to view the scanfile's Japanese font in the core server if we opened in Notepad.
If we import the scanfile into the database. The font looks good too.
We can see the non-english font as highlighted.
We have an old LANdesk server running at v9.0sp2, weird part is that the inventory data on Chinese and Japanese are ok.
But it does not work for v9.5. The old and new Landesk servers are using separated databases in same instance & server.
At this point, I really have no idea on what is causing the problem.
If any of you have the similar experience, please share with me.