Could anyone advise how to programmatically change the default Windows XP code page (I'm doing this from Delphi)? (This would be the equivalent of going into Control Panel -> Regional Settings -> Language for non-Unicode applications).
In this case, I want to switch to Chinese (PRC) and so am writing to the following registry strings:
HKLM\SYSTEM\CurrentControlSet\Control\Nls\CodePage\
ACP=936
MACCP=10008
OEMCP=936
(Which is exactly what changing the non-Unicode codepage drop down in Control Panel does). There must be another setting which I need to change - and I'd prefer to use a Win API call (if available) rather than writing to the registry myself.
I've also tried setting
HKLM\SYSTEM\CurrentControlSet\Control\Nls\Language\
Default=0804 (Chinese PRC) to no avail.
I don't want to change the 'locale' per se as this will also change time / date settings, separators, etc. etc.
This is because I'm using an ANSI application that needs to render Chinese characters, and I'm writing a tool to automatically switch the system show the characters (while leaving other aspects of the UI intact).
Thanks!
Duncan
The only time this would be appropriate is if you're writing a kiosk type application where nothing else will run on the system. That change will affect every other application on the system.
If you just need to render the characters and can get them into a WideString you can render them in older versions of Delphi by calling the W versions of the Windows APIs directly, rather than going through the TCanvas methods. That is, call DrawTextW or ExtTextOutW instead of TCanvas.TextOut and it will draw the Unicode characters without converting them to the system's ANSI codepage.
A more complete option is the TMS Unicode Component Pack. It supports making Unicode-enabled applications in Delphi 6-2007, and handles calling all of the W functions for you. It works well, and you can just use TCanvas or the Caption/Text properties like normal.; the only difference is the properties are all WideStrings instead. That was originally the TNT Unicode Controls pack, and there's an older, unsupported version of that available here.
Finally, you can use Microsoft's AppLocale utility to change the ANSI codepage for just your application. There are details on calling it from a batch script here, a patch to run it without the nag screen here, and a command line clone named SBAppLocale. It works, but it's a hack, and the other options are better long-term.
Related
we have a application written in vb6, we also have the multilingual support for this application, we provide all the user message along with the ID's in .LNG file but application is not supporting the Unicode language like Japanese, Chinese etc.,can anyone suggest how to proceed the minimum change in the code and make this work !!!
Thanks
Standard VB6 controls doesn't support UNICODE. It is possible to use MS Forms controls (FM20.DLL). INFO: Usage and Redistribution of FM20.DLL.
The problem is that old version i buggy and is updated by MS-Office. New version of office id 64-bit and doesn't contain 32-bit FM20.DLL. I think it it only 'simple' way of implementing UNICODE but still it is massive change to the application.
Howerer VB6 supports different languages at least European, but the texts have to be properly encoded (Code Page Identifiers). I suppose that usual Windows font such as MS-San Serif, Arial supports most of languages.
If the windows default language is set properly other language characters should work. See e.g. HOW TO:Change language settings in Windows XP or try Japanese windows direclty.
We're programming in Delphi 2006, using Multilizer 5.1 to translate the program. Now we've to added Polish as a new language in Multilizer. But when we open our executable, Multlizer says "Polish is not supported by the codepage".
If we adjust our regional settings to Polish, whenever we open the executable, the regional settings flip back to the original setting, which is Dutch. Maybe we should set the CodePage setting in our Project Options, but the dropdown list does not give us any options.
Any ideas?
So it turns out we only had to set the Language for non-Unicode programs in the Regional and Language Options in Control Panel. The bad news is that the French version is now having the same problem.
If you want your application to support all possible language regardless of the Regional and Language Options on the user's computer, you'll need to migrate your application to Delphi 2009 or later. Starting with Delphi 2009, Delphi produces Unicode applications. It'll likely take some effort to fix any code that assumes that SizeOf(Char) = 1. But that one-time job should be much less effort than constantly having to deal with code page issues in your Delphi 2006 application.
Does Delphi support internationalization in any way?
I've seen that I can add different languages for a project, but that seems to create multiple instances of the dfm files. Am I right that the language therefore cannot be changed at runtime?
How do you handle internationalization (if you do)? Are there any best-practices?
Delphi ships with some tools to do this.
Here is a tutorial for Delphi 2005, and a video of Nick Hodges showing off the more recent version for Delphi 2009.
I have once experimented with runtime change of languages. It worked great, but I needed to write lots of code myself (and circumvent the dfm files). The problem is, it is a lot of hassle and you almost never need this.
The better option (in my opinion) is to create a base language version and use a translator tool for the other language. We use a third party translator that works on the executable and dll. It replaces the strings in the resources and creates new binary files.
One big plus of this tool is that it shows the translated dialogs (standard windows components only) so you have direct feedback if labels are too large.
Amd then there is dxgettext:
http://dxgettext.po.dk/
traditionally one of the tools used to change language runtime without restart.
Note that with Delphi/unicode the amount of code changes with this packages has decreased (one no longer has to change any resourcestring use)
I have been using the SiComponents before. They allow you to change all text independently from the executable. You can embed the diferent languages in your executable (not recomended) or load them from files. There is also an editor to support translation. They are very good, stable, and fast.
In Delphi 2006 under Tools, Options, Translation Tools Options you can configure the translation tools, especially theTranslation Repository. It can be found under View, Translation Manager. All translated strings will be ressource strings and can be stored in language specific dll. Searching the help for Translation Manager will point you in the right direction.
I second the recommendation for using the TsiLang components(www.sicomponents.com). I've just used them to upgrade from English-only to English + Chinese, selectable at run-time, and found the process to be quite a lot easier than I was expecting. The end results are not perfect, but certainly good enough to work with.
It is possible to work with a Delphi 5 project in the Delphi 2009 IDE by referencing the Delphi 5 version of dcc32?
If so are there any issues to watch out for concerning the way that project settings (search paths, conditional defines etc.) are implemented in 2009?
Edit: Just to clarify I am also upgrading the project to Unicode but will still need to debug and run releases in the old configuration
It depends on what you're trying to accomplish and what limitations you are willing to accept.
As far as I know, you can't use the Delphi 2009 IDE to maintain Delphi 5 projects directly. For example, even if you stick to functionality that's common between the two, some properties that are not supported in Delphi 5 are written to your DFMs, causing an error at run time.
I've maintained projects and library code that were written in Delphi 2005/2006/2007 that was also being used in Delphi 6/7. I usually edited and debugged these using the latest IDE. I had separate project files for each target version and made sure they all used the same memory manager. Finally, I had an automated build process and unit tests that would strip incompatible properties out of the DFMs (my own DFM Scrubber), make sure all of the targets always compile and run unit tests, which are also recompiled for each target.
All in all, it's more effort and I wouldn't recommend it unless you have a specific requirement to do so.
No. That said, it is still Delphi, and assuming you have source or D2009 versions of any custom components it can be modified to compile in Delphi 2009. The layout of the VCL has changed quite a bit since D5, so expect to have to modify your uses clauses and probably rewrite some small chunks here and there, but it is doable.
You either port your code to Delphi 2009/2010 level (Unicode), or you may as well not install the product.
I suggest you open the project and see where it fails, close the project (without saving anything), find the component versions you need and install them, and once the project opens up in design mode (all components are installed) you can start porting.
Read the Unicode Delphi migration (porting) information available at the website.
Ask your self each time you see PChar, and Char, if it needs to be PAnsiChar, or AnsiChar instead? If you are reading bytes from a disk, a com port, or a network connection, you will need to change from Char to AnsiChar, from PChar to PAnsiChar, otherwise, you might just leave the Char and PChar as they are and they will become Unicode. Always be aware that Char is not a Byte, anymore.
You also must replace explicit references to narrow Win32 API calls with versions without the A (ansi) suffix. Example: CreateFileA might need to become just CreateFile.
W
I have developed about 300 Applications which I would like to provide with multi-language capabilities independent from the Operating System. I have written a just-in-time translator, but that is too slow in applications with many components. What would you suggest I do?
We are using TsiLang and are very happy with it.
One of the best points is that you can pretranslate the project with a dictionary (which you filled from existing translations).
I've heard that the TsiLang components are nice, but your looking at an inplace solution...
I've used GNU gettext for Delphi which does exactly the thing you want, it loads the translations from a text file and replaces the text in your components. It even has a pas/dfm scanner to automatically generate the English translation file.
It's also possible to automatically change your pascal source code to inject the gettext procedure inplace of your static strings. If I'm not mistaken it just adds a underscore as function to it, as below.
ShowMessage('Hello'); // before
ShowMessage(_('Hello')); // after
I must say it has been 2 years since I last used this method.
One thing will remain problematic, the Delphi components are not unicode enabled (D2009 fixes this), so when you don't change the components you'll still have limited support for other languages.
A good free solution would be GNU gettext for Delphi. It has some capabilities not present in TsiLang - for example, you can put the knowledge on how to count things (different endings for one, two, four, hundred and two, many ...) into the translation file so that you don't have to teach each program to know this stuff.
License for the Delphi part is very permissive but I'm not sure how much the included GNU stuff will affect your application.
Get Multilizer. It is made in Delphi and it can handle Delphi programs like no other with special support for VCL. You can even redo your screens easy for every language. With Multilizer you can use different techniques to translate and run your program.
Delphi 2009 has added an Integrated Translation Environment/External Translation Manager
ITE and ETM are now available for both Delphi and C++Builder.
In Codegear's article: What's New in Delphi and C++Builder 2009, they state:
The Integrated Translation Environment
(ITE) is a part of the IDE that
simplifies localizing your projects.
ITE can create a new localized project
from an existing project. ITE does not
automatically translate text, but
provides a dialog listing all text
that needs to be localized and fields
in which to enter the corresponding
translated text. Once you have entered
the translated text and built the
localized project, you can set another
language active and display a form in
the localized text; you don't have to
switch locales and reboot your system.
This allows you to perform
localization without requiring a
localized system.
The External Translation Manager (ETM)
is a standalone application that works
with DFM files and text strings in the
source code. Although ETM does not
allow you to create a new localized
project, it does provide a dialog
listing localized text and the
translated text, similarly to ITE.
This is what I plan to try first once I am at the point that I want to Internationalize my product.
However, to me the easy part is to translate the program. The hard part is to translate the help file.
I would say GNU gettext for Delphi in combination with TMS Unicode Component Pack (previously free under TntWare) to get unicode support in the components.
To work with, or have translators work with, the gettext files I recommend looking at the free cross-platform Poedit that may edit the .po files.
Just to mention cxLocalizer if you own DexExpress components.