Leaderboard

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

I have implemented a few improvements in the Uses Clause Manager Identifier Search: 1. The number of Identifier Search filter results is now displayed. 2. Previously the search term was searched only at the start of the identifier names. Now you can choose between "Match anywhere" and "Match at start". If you change the match type then the filter results are updated automatically. Here are the sources, so you can build GExperts with these new features yourself: GX_UsesExpert5.zip Fixed a small bug just now; if you have already downloaded GX_UsesExpert3.zip or GX_UsesExpert4.zip then re-download this archive. Here are a few Uses Clause Manager features planned for the future: • Export the list of Project Units additional option: Preformatted as uses clause. • Identifier search: Fuzzy-Search option • Identifier search: Optimize filter performance with TParallel.For • Identifier search (or all tabs?): Multiple search terms (like in RFindUnit) • Identifier search: Search the selected Identifier result in custom help files • All Tabs: Button/Combobox on the bottom panel to Copy the selected List item(s) to the clipboard, or to copy the selected unit path(s) to the clipboard, or to copy the selected unit FILES to the clipboard • SearchPath: Add a custom list of user paths • Add a Statusbar to the UCM window which displays the file-path of a single selected unit; then a Ctrl-click on the statusbar opens Windows Explorer at the location of the selected unit and selects the unit file in Windows Explorer.

Delphi 6 (and Delphi 2007) does not have any enhanced threading library, so TParallelFor is out. I hope the rest of your changes hasn't broken too many places. (Mind you, I'm not complaining, I'm glad that somebody shows so much enthusiasm and contributes to GExperts, but as long as it can be done without too much hassle, I want to continue supporting Delphi 6 and 7. And Delphi 2007 is a must as long as I'm stuck with it.)

Well, then simply renew your subscription and you are good.

I just had a short look at the sources: They don't compile with Delphi 2007 because you prefixed many identifiers with the full unit names, e.g. Vcl.Controls.whatever. Delphi < XE does not understand this, so please don't do that. Also, there are quite a few unknown properties, but there isn't much that you can do about this. If I get it to compile I'll commit this, so you can base any additional changes on the changed code. Edit: Done.

Especially with DevExpress everything should be setup perfectly if you run their setup. You only end up recompiling their sources (and even if that should not affect linking time it adds a bunch to the compile time) if you manually put the directories with their sources into your library or project search path. Within the DevExpress installation directory there should be a Library folder (besides all the different ExpressWhatever folders for their different component suites). That Library folder contains all the dcus along with dfm and res files being produced by the compilation during their setup. That directory is being put into the library path. If anything else is the case then that is not ideal. P.S.: If you don't mind and are able to send me the map file of your application and I can quickly run that through some tool I wrote to peek if it suffers from heavy generic bloat.

No, it's not a good practice - write your classes in a way that you could do pure DI. If you do field injection that code can't run without a DI container or some other ways to do such injection. If you have too many ctor arguments you are suffering from so called constructor over-injection and there is a way to solve this: refactor your code and respect the single responsibility principle - see https://blog.ploeh.dk/2010/02/02/RefactoringtoAggregateServices/ Always think of a DI container as something like an automated assembling plant - all the screws and pieces that are put together there by robots don't know of the assembling plant. You can as well grab a screwdriver or some other tool yourself and put the pieces together manually with a lot of work and sweat but it's possible.

iirc circular units should affect the compiling but not the linking phase but I could be wrong. Extremely long linking phase for has been almost always a result of extensive use of generics (either through third party or your own) because the linker then has to look through all the dcus and remove identical ones (for example every unit that uses a TList<Integer> has the code for that entire class emitted into its dcu which the linker then has to read again fix up pointers and write that to the final binary which only contains one copy of TList<Integer> - but also one for TList<string>, TList<TPerson>, TList<TcxWhatever>, ....) Also sometimes very innocent looking generic APIs can cause a huge clusterf... of types being emitted into the dcus if one is not careful (I should know I wrote such APIs ^^) Look into the dcu output directly and tell us the size of all dcus combined - that should give a rough estimate if that is the cause or not

You can try those options: 1)Don't compile the third party components every time. Just compile them once when you install a new version, in both release and debug mode. Put the path for the release dcus in the "Library path", the path for debug dcus in "Debug DCUs" and the path for the .pas in the "Browsing path" This way you can still fully debug the third parties (by selecting "Use debug dcus" in the compiler options) or treat them as a black box (by unselecting use debug dcus). But the more important thing is that you will compile much less lines of code every time you do a build. 2)Look out for circular dependencies between units. 3. move used units down from the interface uses section to the implementation uses section 4. remove not needed units from the uses section You can also compile the project with the command line and output the results to a file. Then open the file with the output, and see which units take a long time to compile. then review the uses sections (both interface and implementation)

The same could be asked for any UI control that has a published Action property and a published OnClick (or other actionable) event. One reason is code reuse, the same Action object can be assigned to multiple controls, even the Form itself. For instance, Actions are commonly shared with menu items and other UI controls that invoke the same actions. Another use would be sharing common properties with multiple controls (Enabled, Visible, etc) so you can update 1 property and have it propagate to multiple controls automatically.

Amazing amount of unittests