How do Non - Unicode applications support different language strings?
-
We have non-unicode application where it has to support different language strings like korean, chinese etc. I had installed the required language packages. I have to change the language dynamically through a menu item. Until unless teh language settings have been done in regional/language settings and reboot the machine the language strings doesn't change. Is there any way to by-pass teh reboot so that I can update the required registry values for changing different language??? Even there's The Microsoft AppLocale Utility for this but I shouldn't use that utility in my application. Please post your views
-
We have non-unicode application where it has to support different language strings like korean, chinese etc. I had installed the required language packages. I have to change the language dynamically through a menu item. Until unless teh language settings have been done in regional/language settings and reboot the machine the language strings doesn't change. Is there any way to by-pass teh reboot so that I can update the required registry values for changing different language??? Even there's The Microsoft AppLocale Utility for this but I shouldn't use that utility in my application. Please post your views
-
CPallini - Expecting reply from you
Sorry, I don't know... :rolleyes:
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles] -
We have non-unicode application where it has to support different language strings like korean, chinese etc. I had installed the required language packages. I have to change the language dynamically through a menu item. Until unless teh language settings have been done in regional/language settings and reboot the machine the language strings doesn't change. Is there any way to by-pass teh reboot so that I can update the required registry values for changing different language??? Even there's The Microsoft AppLocale Utility for this but I shouldn't use that utility in my application. Please post your views
-
We have non-unicode application where it has to support different language strings like korean, chinese etc. I had installed the required language packages. I have to change the language dynamically through a menu item. Until unless teh language settings have been done in regional/language settings and reboot the machine the language strings doesn't change. Is there any way to by-pass teh reboot so that I can update the required registry values for changing different language??? Even there's The Microsoft AppLocale Utility for this but I shouldn't use that utility in my application. Please post your views
That's not as "easy" as it may seems, because sometimes even the hardware is involved... Let me go back in the early days when the fist IBM PC comes to light: there was the ASCII charset (7 bit) that IBM extended adding 128 more character, fitting 1 byte, and adding gliphs to satisfy many latin-derived alphabets (accented vovels, diacritics. etc, pus some "semigraphics"). This did't in fact satisfy any of the langags since all of the supported ones always had something missing. When windows comes along, a number of "localizations" had been done by basically replacing some useless glyphs (for a specific language) with more useful ones. This led to a number of different character maps (the so called "codepages") some of them still fitting the 256 glyphs space and some other going ahead of that number by using particular "escapes" (and hence requiring MBCS or DBCS support from the string manipulation functions and from the font definitions, as well from the graphics drivers. Unicode then standardized all that stuff by giving to any existing "glyph" a specific and unique ID. That makes -in theory- possible to depict all the glyphs in any font but - beware - that requires lot of space so not all font makers does that (or does that in different packaging). So: non-unicode applications to properly display characters must not only rely on the specification of the langID, but also require the corresponding codepage in the system, and since they cannot be contemporary used (a same code means a different glyph within a different codepage) the kernel (better: the user-side of it: user.dll and gdi.dll) must know which codepage has to use. But this requires dismounting a driver and mounting another one, affecting the system globally. That's makes your problem not solvable as an "application local problem".
2 bugs found. > recompile ... 65534 bugs found. :doh:
