Leaderboard

I did a more thorough test with these four localization tools. Our application is huge. It contains hundreds of forms and thousands of units. Most of those units have resource strings. We also use visual form inheritance in every form. We use frames and inherited frames, too. Our forms have been designed such a way that there is plenty of room for string expansion. So, we do not need a form editor to change the layout. However, translators need a form preview to see the context of the strings. We use several freelance translators that need to work simultaneously with the developers. We use CI/CD and new content appears almost every week. Finally, we have both 32-bit and 64-bit version of our application. We target to 6 languages. Before we start, I would like to point it out that Delphi has a specific pattern how the localization should be done. It is to use forms, resource strings and resource DLLs. ITE uses this approach. Unfortunately, the implementation of ITE is just so bad that it is barely useable. Therefore, there is room for other tools. Let’s start write TsiLang. It is a component-based solution. It does not follow the standard VCL localization method but forces you to do major refactoring to your code. This means adding components to every form and replacing resource strings with TsiLang’s own implementation. The product works, and it is very cheap. I am sure TsiLang has its own fans. In a large project like ours, the price of the localization tool is not the prime factor. The features are. This is where TsiLang gets short. No form preview, propriety implementation, limited team work features, limited translation aids (TM, MT, terminology). This was the first to go. Korzh Localizer is a step forward. It allows you to use resource strings. It does not refactor your source code hardly at all. However, it is not based on resource DLL but uses its own language files. Like TsiLang it does not have form preview and has very limited translation aids. This was the second to go. Remaining two tools, BTM and Soluling, both works on the right principle: the standard VCL localization method. They are also totally decoupled from Delphi IDE that is very important. I like them both. BTM is a free tool and a very good one. It does the localization so much better than the TsiLang and Localizer. BTM is free and Anders has maintained it for three years. Huge respect for him. However, BTM lacks some very important features. First the form preview. Second is that if you have both 32-bit and 64-bit applications, you need to create two separate projects and somehow copy paste the translations. In addition, it scans all strings properties and you have to exclude them manually. There are no rules to configure what properties to localize and what to ignore. BTM has some translations aids but lots of features are missing, such as translation validation and interactive TM/MT/terms. My test sample contains TTreeView and TListView components. TsiLang, Localizer and BTM did not scan the nodes of those components. They were just ignored. What am I supposed to do in a case like that? Remove the design time data and populate the nodes on runtime using resource strings. No thanks. In most case you do not need (and should not) localize images but sometimes you have to. These tree tools cannot handle them either. This brings me to the last tool, Soluling. Soluling is more expensive than the above three tools. However, with that price, you get a tool that has all the features you need to localize a large VCL application. Soluling has a brilliant form editor. It is not only a preview, but you can change the layout. I would suggest not to go on that path but to pay some extra attention to your original UI design. However, if you need to do layout change, you can. Soluling localizes TTreeView, TListView and images. Soluling also has a concept of platform files. It means that you can add many variants of the same EXE file (e.g. 32-bit, 64-bit, debug, trial, etc.). No need to have a duplicate project file. No need to translate the same strings twice. Soluling’s translation aids are top level. Soluling’s features even exceed the features of the mainstream CAT tools like Passolo, MemoQ and Catalyst! Finally, in most cases you have also some other files but Delphi application to localize. For example, you might have some documentation files and web pages. Soluling can do those too. I quickly tested HTML, React and Markdown. All worked nicely. Both BTM and Soluling have a command-line tool to be used in the build pipeline. The both tools require zero changes to your source code and you are not forever bound to the tool you selected, such in the case you selected TsiLang or Localizer. Ultimately, this is a “battle“ between two Nordic guys: Anders and Jaakko. They both did it right. If you have a small Delphi-only project and small budget, go for Better Translation Manager. If you have a larger project or budget, or you also have other files but Delphi EXEs, go for Soluling. I have attached screnshots from each tool.

Good, after a long time stressing this forum, especially the Python4Delphi channel, with lots of rookie requests, I got to a good point with the development of my first Python program. Until a few months ago I had always ignored Python and its possibilities as Delphi has always been a tool with which I create all my works and I have never thought of anything else. When Python4Delphi and DelphiVCL showed up I wondered if I could do something interesting with both and I must admit that although Python was completely new land to me, the fact of sticking with Delphi anyway took away any doubt. .. I had to try. Basically, the program is pure Python (after being compiled with Cython), an embedded version, with the addition of DelphiVCL (I've never used FMX so it's better to start from the VCL that I know very well) and some Python modules made in Delphi where I put the more delicate parts and in use real threads and not "crippled" threads by the GIL. I anticipate, it is nothing transcendental, but as a first Python project, I am satisfied with it. Description of video In this short video, we can see the execution of an external program written in Python for the holding of print markers necessary to calculate the zero machining, the rotation of the piece on the work table, and all the scaling needed to compensate for the error of model printing between CAD and plotter printer. The Python program interacts directly with the CNC that moves the XYZ axes for the final cut through an API Client (cnc_api_client_core in PyPi) to the CNC control software API Server, retrieving information and sending direct commands to the CNC System. Image capture is done using a proprietary IP Camera equipped with LED lighting. The Python program is executed through an embedded version of the language prepared with all the necessary tools and allows two UI, vertical and horizontal, to adapt to all types of monitors. NOTE: The below CNC Control Software is 100% made with Delphi 🙂 Many Thanks to forum people for the support!

Unloading and reloading has always been possible with P4D, but quite tricky and not foolproof. You need to manually unload the dll's loaded by imported modules and if you fail to do that it will fail. PyScripter does that and allows you to change python version without exiting.

My First P4D was completed and released 🙂 Thanks to the developers of PyScripter and P4D for these amazing tools.

The ZLIB changes to use System.Zlib are now in SVN, considerably simplified so two defines are now only used once each in one unit, making it easier to support. But you do need to use the new OverbyteIcsDefs.inc or edit your own version, see the SVN notes. Angus