Search the Community

Better Translation Manager https://bitbucket.org/anders_melander/better-translation-manager The Better Translation Manager (BTM) is a replacement for the Delphi Translation Manager a.k.a. the Integrated Translation Environment (ITE) and External Translation Manager (ETM). Why is it better? Well, for one thing, it's free but more important; It actually works - unlike the ITE/ETM. Why? The standard Translation Manager that ships with Delphi today was originally an individual product known as the Borland Translation Suite. With Delphi 5 it became a part of the enterprise edition. The Borland Translation Suite showed great promise but unfortunately it never evolved from its roots as an external tool and has always been hampered by severe bugs that made it completely unusable in practice. As a result nobody uses it. This can be witnessed by the plethora of homegrown and commercial alternatives. The great benefit of the standard translation system is that it just works (this is the system itself I'm talking about, not the tools. The tools suck). Apart from the requirement that you must use resourcestrings you don't need to do anything special when writing your code. At run time you just place the compiled resource modules in the same folder as your application and the Delphi Run Time Library automatically takes care of loading and using the translations based on the current Windows user interface language. Anyway, since Embarcadero has now finally admitted that they are never going to fix the Delphi Translation Manager and instead recommend that we find alternative solutions, I decided that it was time I solved this little problem once and for all. The core functionality of the Better Translation Manager was written in two weeks during my summer vacation in Italy 2019. Amazing what you can do with a little pasta! Features Does not require any changes to the source code of the application being translated. Works with the existing standard Delphi localization system. Translates resourcestrings and all strings in forms regardless of any 3rd party components used. Works on compiled application. Source code is never used. Generates localized binary resource modules (resource DLLs). Does not use an external compiler. Can import existing translations from compiled application and resource modules or from XLIFF localization source files (dfn, rcn files). Read and save TMX and TBX translation memory files. Import Translation Memory from TMX (Translation Memory eXchange), TBX (TermBase eXchange), Microsoft Glossary and CSV. Machine Translation using Translation Memory, Microsoft Translation Service or Microsoft Terminology Service. Forms, Components, Types and Values that should be ignored can be specified in a Stop List. Translations are Spell Checked. Validation Rules to catch common translation mistakes. Supports Right To Left (RTL) editing based on translation language. Translation project is stored in a single XML file. Command line interface for use in automated build systems. Fast! Refreshing a large project typically takes less than a second vs. many minutes with the ITE/ETM. Supports all Unicode versions of Delphi (i.e. Delphi 9 and later). Resource modules contain the version resource of the source application. What it doesn't do There's one task that BTM, by design, doesn't attempt to solve: Localizing the placement and size of controls. Since it has been my experience that it is a far better idea to design the user interface in such a way that the layout automatically accommodates changes in font- and text size and shorter/longer texts due to translation, I decided from the start that I would not be supporting localization of size and position of controls. This also relieved me of having to create a run time form designer, supporting 3rd party controls visually (something that nobody so far has managed to find a foolproof solution to) and deciding what individual properties constitutes size/position values. Instead I just localize all string values - and only string values. But wait... There's More! Yup, you not only get this little wonder for free. You get the full source code too. Grab it at the repository linked at top. More details at the repository. Enjoy / Anders Melander

Hello, i am having trouble "localizing" VCL built-in dialogs. Generally, i think there is multi-language support for the VCL. Also, there are means of localizing custom forms and vcl controls at runtime. But i could not find documentation or examples on how i can have for example the buttons in a "Vcl.Forms.TApplication.MessageBox" displayed with english or german captions? The Captions vary when using the System settings, switching "Windows language", but i would like to switch language "at runtime" of the application, so, if you like. To be more precise: For example i call the MessageBox function and have it displaying one "OK" and one "CANCEL" button. I would like to make sure in application code that the Button Captions are displayed in english or german (independent of the windows language settings). The same applies for the VCL "Dialogs::MessageDlg" buttons. Buttons are added by "System::Uitypes::TMsgDlgBtn"-type idenifiers, but the resulting buttons on the form can not be localized in the described way. This should also apply for "shortcut" caption extensions. For example i add a menu with a TShortCut that is using a key identifier (extern DELPHI_PACKAGE System::Classes::TShortCut __fastcall ShortCut(System::Word Key, System::Classes::TShiftState Shift);). These ShortCuts are displayed on the UI as a "caption extension". But i do not know how to have them displayed according to language chosen at runtime. Is this maybe impossible to switch display language of such controls at runtime? And if possible, does anyone know how to achieve this? Thanks in advance and kind regards, Ulrich

Local letters appear incorrectly when project and device OS (android / ios) different i.e. "ÖöÜü" > "OoUu" "Project > Options > Building > Resource Compiler > Default language" may be solution according to some web resources, but no precise value available. Help page explains: "Default language (-l) Specify the default language. For example, -l409 represents English. See http://msdn2.microsoft.com/en-us/library/ms776324.aspx for more information about specifying language identifiers." but aspx site n/a and "-l409" gives no match internet searches (possibly "l" stated instead of "1") Language Identifiers and Locales page states "0x1409" "English New Zealand". Then German value should be 0x0407. Unfortunately Project > Options > Building > Resource Compiler > Default language: 0x0407, 0407, -0x0407, -0407 values did not change anything. Do you think whether any other value works? If it is not the solution, then can you suggest a solution for more languages for future versions? Keeping a table in app and each time application starts, scanning and replacing all object texts and strings TsiLang ANN: Better Translation Manager Any other option supports both android and ios with min. 3 languages?

We have been using Sisulizer localization tools many years. Recently I have noticed that their website is down and even the emails don’t go through. Does anybody know what is going on?

I found a bug in Gnugettext and I thought I would let you know and ask your opinion about my fix. Gnugettext does not translate Action linked properties. It does that by calling a function ObjectHasAssignedAction and in TGnuGettextInstance.TranslateProperties there is the following code: if ObjectHasAssignedAction(AnObject, PropList, Count) then Continue; The problem is that if an object has an assigned Action property no property of that object gets translated action-linked or not. I got bitten by this since there was an action in PyScripter used in different menus, and in one of them I had overwritten the Caption, so the Caption of that item was in the dfm file and the default.po, but it did not get translated. The solution I am trying with success is to remove the above code in TranslateProperties and instead added a check as to whether the property is stored (IsStoredProp😞 if ((currentcm=nil) or (not currentcm.PropertiesToIgnore.Find(UPropName,i))) and (not TP_IgnoreList.Find(Name+'.'+UPropName,i)) and IsStoredProp(AnObject, PropInfo) and (not ObjectPropertyIgnoreList.Find(UPropName,i)) then begin TranslateProperty (AnObject,PropInfo,TodoList,TextDomain); I did check that action-linked properties are not translated multiple times (IsStoredProp returns False). The above also appears to speeds up the translation. But I do wonder whether the above fix has any obvious drawbacks. @dummzeuch Any thoughts?

ImageEn, image editing and display library for Delphi/BCB, v10.2.0 is now generally available.This update is free if you purchased a license or extension after 15 September 2020: http://www.imageen.com/support/download/ Other users can extend their registration for 12 months at: http://www.imageen.com/order/ More info and a free trial of ImageEn are available at: http://www.imageen.com Top Ten Enhancements in ImageEn 10.2.0 ImageEn now uses a DLL for localization support. If you do not need localization it reduces your the EXE size by 780KB. If you use localization it adds support for eight more languages: Czech, Danish, Finnish, Hungarian, Norwegian, Polish, Swedish, Slovenian The ImageEnViewToolbar can now be used to view and edit PDF files Now supports high quality PDF printing, including via ImageEn TAction classes Various improves to measurement, including new interactions to measure areas and lengths with a polyline and more detail in hover hints, e.g. perimeters when measuring by rectangular or circular areas Masks can now be applied to non-image layers, like text and shapes TIERichEdit adds support for all RichEdit 8.0 features, including spell checking All ImageEn keyboard shortcuts can now be easily customized or disabled New mouse interaction allows selection of text or images in a PDF files (with automatic detection based on what is under cursor), plus it is much easier to switch to pan and zoom mode Many other improvements for PDF file viewing, including new options for selection, highlight and form field colors, and performance enhancements Now supports Delphi 11

Hello, We're glad to announce the release of TsiLang Components Suite 7.8.3! Simple and powerful localization solution for software developers. It's virtually impossible to find popular software that would not be translated (localized) into multiple languages. In fact, even niche and second-tier developers localize their products to increase international sales. Unfortunately, the process of software localization is both time consuming and very expensive. Luckily, developers who use RAD Studio, Delphi or C++Builder platform can use TsiLang Components Suite to localize their software for worldwide distribution for a fraction of the usual costs. TsiLang Components Suite brings you the complete and universal solution to create easy and fast multi-language or localized applications for ALL target platforms! Version 7.8.3 among with support for RAD Studio 10.4 Sydney introduced several improvements. Description of the new features and improvements available at: https://www.tsilang.com/whats-new/ Detailed description of TsiLang Components Suite is available at https://www.tsilang.com You can download a fully functional and no time-limit version from https://www.tsilang.com/download-tsilang-components-suite/