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.
Related
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?
I'm using embedded Delphi 2010 localization tools and I can't find the way how to change interface language at runtime. So, how can I change interface language at runtime ?
VCL is not designed such way that it would make runtime language switch easy. The RichEdit demo is actually using form reallocation. It is too strong action for a language switch because you will lose everything you have done for the forms on runtime.
Some localization tools have implemented add-on to VCL to implement runtime language switch. Some use components together with proprietary translations data to perform this. Some use the standard resource DLL with some units linked to application to perform language switch. For example take a look at this document. It describes step by step who to perform runtime language switch without needing to reallocate forms and without losing any data.
http://www.sisulizer.com/translation/vcl/VCL.pdf
Be careful with arrays containing resourcestring!
See the RichEdit demo in Demos\DelphiWin32\VCLWin32\RichEdit directory.
I have a large application which i want to migrate to Arabic. I have defined the strings that we show to the user under the resourcestring keyword.
I am using the External Translation manager provided with Delphi 6. However, I am not very much comfortable using the tool. I want to create a resource only dll with all the translated strings like how the Delphi ETM does, and then switch between languages at run-time at the click of a button.
I was able to link the resourcestrings to the Dll, but how about form's captions and hints and the component properties? I am loading the Dll at runtime depending on the language, but the form properties are not reflecting as they were not available in the Dll.
Any pointers in the right direction ???
Thanks
Rahul W
What the Delphi localization tool and runtime support do is to redirect resource loading - including forms - from the executable to the DLL. Forms, their components and controls (non default properties) are stored as resources into the executable (as long as you don't create them fully at runtime - but then you would have to set their properties one by one).
Thereby if you want to work alike the standard translation tool you have to work the same way. What the DLL Resource Wizard does is to extract all project .dfm (and those you add manually) and resourcestrings to a copy that can be localized. When an app is started the form loading code checks from where the .dfm should be loaded. You should override this code to load your resources.
Be aware that changes language at runtime may need a different approach, because loading a whole form from resources may "reset" it to the creation state. On the other hand, compared to approaches like gettext, it allows to localize far more than the form text, including images, colors, and to adapt control sizes to the new string easily. IMHO gettext is good for simple needs, but when localization becomes a complex task and you may need to localize for a very different "culture", more powerful tools are needed.
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.
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.