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.
Related
I had read documentation about localizing Embarcadero DocWiki.
But I do not know how to:
change language in Run-Time - for example I would to click in application menu change language to English or Polish
Show translated text in dialogs, e.g: ShowMessage('Zmieniłeś język');
1.
There was sample project (shipped with Delphi) called RichEdit which had run-time change of language. To achieve that, Reinit unit was used (you can take it from here) which actually reloads all the resources.
It's working normally on simple programs like that, but may be real pain to implement in something more complex, as all the controls on form are reverted to initial state in which they have been at start-up, so it's your responsibility to keep your data consistent.
Though in proper implementation where all the application logic is separated from GUI (so there are no vars on TForm, no storing user data in edit boxes etc), it should work normally.
See RichEdit sample's source code to understand how to use Reinit.pas
2.
The classical approach is to use ResourceString. In interface section of your unit or better in separate unit, write:
ResourceString
ChangeLanguageStr = 'Zmieniłeś język';
//another strings here
and for showing message:
ShowMessage(ChangeLanguageStr);
These strings will be shown in translation manager.
I have deveoped a custom file type, together with a custom editor (basically a tree with several data pages attached and a few extra buttons). OK, I can run it stand alone and that is fine, and even add it to the tools menu, but I would like to integrate it into the Delphi IDE so that my custom editor (or a similar new version) appears in the IDE, rather like a DFM file has a custom editor. I can find references to most extensions in the Delphi IDE, but not this one. Any guiding hands? Note that this is not a property or component editor (the file type has nothing to do with either of these) nor is it simply syntax highlighting of a text file.
AFAIK it currently isn't possible to reliably integrate a custom editor into the Delphi IDE. The required API simply isn't there. See QC89028 Custom Module support.
During the Delphi 2010 and XE betas I spent most my spare time trying to get a resource editor integrated. Although the effort had the official blessing of Embarcadero and got some, half hearted, support from the IDE engineer, I was never able to get them to deliver on their promises and surface the module API. I eventually abandoned the project.
Update: I've now checked my old correspondence regarding this and it turns out part of the problem was that IOTAModuleCreator (used to implement File|New for custom file types) and IOTAEditorContent (used to transfer data to/from the custom module) only supports text data. Binary data gets mangled.
You can probably do this via an IDE plugin that uses the ToolsAPI (see ToolsAPI.pas in the IDE's source folder (e.g. Program Files (x86)\Embarcadero\Studio\source\ToolsAPI\ToolsAPI.pas.)
For information on writing a plugin in general, see David G Hoyle's excellent blog. Once you know the basics - i.e., write a 'wizard' and get it to do something - you will need to work on integrating your editor.
I have never done this, and so I can't guarantee it is possible. However, some interfaces that look worth investigating and implementing are INTACustomEditorView, which represents a 'view' (file tab when that file is open - think the code editor, Welcome view, type library editor, etc) and IOTAEditorViewServices, to register your custom view. I do not know how you associate a view type with a file type, sorry - possibly something to do with the personality interfaces. You might also be interested in INTACustomEditorSubView which is what creates a tab on the bottom of a file.
Good luck, and if you find a solution please write here so that other people can learn too!
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'm compiling my application with Delphi 2010. My problem (it may not be a problem for anybody else) is that when you open that EXE with any resource editor you can see RCDATA which holds forms data. I don't like an idea of my program being "exposed" so I want to ask you is there any trick to remove that information from EXE or encrypt it that nobody (at least from resource editor) can see it?
You may create your forms fully via source.
opposite: you can't use the form designer.
with gexperts you can convert existing forms to source.
encrypting and compressing is not a solution. when the app can load the resources a engineer can it do, too.
I have written a DFM compressor that works inside of the Delphi IDE to compress DFMs at compile time. It then decompresses them on the fly at runtime.
I sell it for $15 US and it comes with src.
It currently works with D7, D2006, D2007 and D2009. I don't own D2010 but I have recently gotten XE and I will be upgrading it and making it available for XE as well in the near future. If someone makes a request for XE, or even D2010 compatibility, I'll work to make that happen sooner.
It's called the DeForM System and can be found here.
I use it for a number of my personal projects.
You would need to modify VCL source code to teach form loader to take resources elsewhere. Also, compilation would require post-build step or stripping resources from the compiled EXE and moving them to a separate encrypted file (for example). All of this is manual work, I never heard of any automation for described tasks.
One thing you could do IF your forms are finalized (i.e. they won't be modified further) is take GExperts and use their Component To Code expert to create forms and their contents in runtime. But modification of such forms will require changes in code.
It actually just holds published property of the components you drop on your forms and the form itself (actually the content of DFM file for each form), not any source code. So even if somebody extracts that data, they can at most produce a form visually looking the same as your form, but none of the codes you wrote for the form.
One way to hide such data from resource editors is to build all the components you use in your form at runtime, not using the form designer. This way, the DFM resource will not contain their data. As far as I remember, there are tools which are able to receive a DFM file as input, and generate runtime code for component creations automatically (e.g. GExpert), so that you could copy\paste the code in your form's OnCreate event-handler.
Another option is to use an EXE compressor. A compressor will compress your EXE file so the content of the file will be changed and not usable until being decompressed. Tools like UPX can compress your EXE file and decompress it on the fly when you execute the EXE. Take note that using known compressors like UPX has the drawback that many cracking tools or crackers can detect them and automatically decompress the EXE before processing it. So if you need more security, you'd better go for custom compressors.
I haven't used it, but Citadel for Delphi does automatic compression and encryption of DFM resources in your EXE. It doesn't look like they've updated past Delphi 2009 yet, but it's exactly what you're looking for.
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.