Create VCL Forms Application
Drop a TLabel component on the form.
As per Adding Languages to a Project
add language French CANADA and compile the project with this changes.
Open .dfm file and change the caption of label under french translation column.
Deploy the exe in another machine as mentioned in Localizing Applications
Execute the exe and noticed those junk characters instead of the original string.
When we try to build the exe for French Canada some of the characters(like é) are coming as differently as “©”
Which is incorrect.
is there any solution for this?
Related
I am trying to localize a VCL application, but I can't seem to find LoadNewResourceModule and ReinitializeForms. What unit(s) do I need to add to the uses clause for Delphi 10.3.4? Or is there another way to switch language dynamically?
Reference: http://docwiki.embarcadero.com/RADStudio/Sydney/en/Dynamic_Switching_of_Resource_DLLs
LoadNewResourceModule and ReinitializeForms are only for an example purposes. They are not very practical because it recreates the form.
Here is a complete Delphi localization document. It also shows how to make the runtime language switch in the right way.
You can localize your application in many way
One exe for each language. The application always start in the language of the EXE. Deploy the EXE matching the user's language.
Original EXE plus one resource DLL for each language. You can have runtime language switch or just select a language at the time when the application starts. Deploy the EXE and any number of resource DLLs.
One multilingual EXE. Windows will select the language. You have no control for it. Deploy only the multilingual EXE.
I want to change the language of the Delphi XE7 IDE from German to English. BDSSetLang.exe doesn't work for the toolbar and menu items (e.g. 'File / Open project' instead of 'Datei / Projekt öffnen').
Use BDSSetLang.exe in the bindirectory of your Delphi installation.
Did you notice that there are separate settings for the IDE UI and the Library?
QUICKFIX: Move all *.de files from the folder C:\Program Files (x86)\Embarcadero\Studio\15.0\bin\ to another location (so you can move them back if it does not work). If that fixes your issue, delete them.
(Or *.fr for French or *.ja for Japanese- (English is default).
for current versions (Delphi 10.4.2), the solution here works for me:
>cd C:\Program Files (x86)\Embarcadero\Studio\21.0\bin
>bdssetlang en
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.
I have a Borland C++ Builder VCL app (so I am not working with Unicode yet),
I want to provide a simple translation of controls' caption text to Russian at runtime.
I can easily use EnumChildWindows to get the English caption, then lookup the translation and replace the caption text using SetWindowText. This does work well for my western European translations where I don't have to worry about the font.
But I am not sure how the Russian version of Windows and then VCL handles 8 bit cyrillic character sets.
Currently all the VCL controls have the font settings:
Charset=DEFAULT_CHARSET
name=MS Sans Serif
Am I correct in assuming that when my program is run under a Russian version of Windows the
character set will be cyrillic with the DEFAULT_CHARSET setting so I won't need to
change the font settings in all my controls?
If I do have to change the font (at run time), should the Windows API function SendMessage(hwnd,WM_SETFONT,(WPARAM)hFont,TRUE) work with VCL controls ?
I have tried using the CreateFont() and SendMessage(..WM_SETFONT..) with RUSSIAN_CHARSET and a cyrillic font face. This doesn't appear to have any effect,
it keeps the font that was set for the control in the form at design time
(even ANSI_CHARSET and a standard Windows-installed font face doesn't affect the controls' font) so I looking for confirmation that I won't have to change the font of the controls, or else tell me some VCL method for setting all the controls' font settings at runtime .
There is no need to reinvent the bicycle. Why don't you use Integration Translation Environment Tools which are provided with Borland C++Builder? There is a wizard that will help you with translations and will make a special resource file which will contain translation of all text strings in your application. Then program, will check system language and availible language resource files at startup, and will automatically use appropriate language. Check C++Builder help system with index - "Integrated Translation Environment (ITE)" for more detailed process description.
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.