Leaderboard

Hi Stanislav Did you find out what was causing this issue? We had the same problem recently after upgrading our project to Delphi 12. When running on devices (particularly older than Android 14) it crashed with the same Resource not found for drawable/splash_image_def. In our case, the problem was the colors.xml file not containing an entry for: <color name="splash_background">#FFFFFF</color> We replace the standard colors.xml file in our project deployment with a custom one to support a custom Android widget library. Our xml file was from D11.3, but from D12 it now needs to include the extra color entry for splash_background. I hope this helps if you're still having problems. Chris

The C# library Raptorious.Finance.Swift.Mt940 has been ported 5 years ago to .NET core at https://github.com/mjebrahimi/SharpMt940Lib.Core/tree/master I have used the raptorious one to successfully parse ABN AMRO MT940 files and convert them to CD at https://github.com/jpluimers/MT940-to-CSV It should be relatively straightforward to port them to Delphi. --jeroen

Well, if you are looking at the bottom-up view then you will get the result ordered by the call tree leaf nodes. As I understand it, you want to trim the tree to remove the low level entries. I think the closest thing to what you're after is to simply use the top-down view instead and drill down to the desired detail level.

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.