Anders Melander

I've not tried Fork but based on the screenshots it's an almost identical clone of SourceTree...

On Windows: Yes. Everywhere else: No. On Windows it works the exact same way as with VCL; Forms are stored in the EXE resources in DFM format and resourcestrings are stored as string resources. AFAIK for cross platform FMX you were supposed to use the TLang component for localization and invent your own system for managing and applying translations, but that system has been deprecated as well. Yes, you can load resource modules dynamically (they are just DLLs) but forms that have already been instantiated will not be affected by this. This means that if you create a form and switch to another language, then the form will stay in the original language. The post just above yours points to an example:

It seems that the Delphi SOAP framework is unable to handle SOAP responses that contain cookies with Expired=Fri, 31-dec-9999 23:59 GMT. Is this a known problem? The web service that sends this response in my case is the Microsoft Terminology Service. While there seem to be some disagreement about whether the year 9999 is out of range (some say 2038 is the maximum allowed value), the value so common that Delphi should be able to handle it. Under any circumstance the reason that Delphi fails to handle to value is clearly not by design - i.e. it's a bug. Here's what happens: The client (the Delphi application) sends a request to the SOAP server. The SOAP server responds. The response contains a cookie with an expiration time of "Fri, 31-dec-9999 23:59 GMT". The Delphi SOAP framework converts the expiration date to the local timezone (CET in my case). The result is 31-dec-10000 01:59. The value 31-dec-10000 is passed to SysUtils.EncodeDate but because the year value is outside the allowed TDateTime range (1-9999) this fails with an EConvertError exception: Invalid argument to date encode. I have not been able to find a way to work around the problem.

Done: https://quality.embarcadero.com/browse/RSP-30282

"Works As Expected" - What The Hell? Stupidity like that is high among the reasons why I no longer bother reporting bugs.

It isn't the tool that determines the result. It's the one wielding the tool.

Indeed. Here's the Delphi 1 version: destructor TComponent.Destroy; begin Destroying; DestroyComponents; if FOwner <> nil then FOwner.RemoveComponent(Self); DisposeStr(FName); end; It's been a while since I looked through the Delphi 1 sources. Classes.pas is only 3916 lines long. It's just sooo cute

I don't understand why you would get a compiler warning on that. I'm not getting it with Delphi 10.3.3 and since you are compiling from the source on bitbucket we should be using the exact same compiler options. This is really strange. You are getting an error when the project default source language is set. The origin of the default value is the GetUserDefaultLCID Win32 API function... but $2000 isn't a valid LCID value. My guess is that you are using a custom locale (see: Locale Names without LCIDs). I had hoped I wouldn't have to deal with those but I guess I weren't that lucky. You can probably work around the problem by modifying the default locale settings in the registry: HKEY_CURRENT_USER\Software\Melander\TranslationManager\System DefaultSourceLanguage=1033 DefaultTargetLanguage=1033 The above values sets them to "English (United States)". I will have to see if I can reproduce the problem here and then figure out how to deal with it. Stay tuned... There are several ways you can control what language to use at run time. Start by reading the Delphi help topic "Deploying Localized Applications". This explains how you can override the default language choice using the registry. BTM itself can be used as an example of how to load a specific resource module based on a user choice. Look in amTranslationManager.dpr in the function named LoadResourceModule and in amLocale.pas in the function named LoadNewResourceModule. There used to be a Delphi example project (RichEdit or something like it) that demonstrated how to localize an application and how to switch resource modules at run time but I don't think it's been included for a while.

Thanks. My guess is that the DRC-file was out of sync with the EXE file at the time you created the project. You should compile the application again and make sure you generate the drc file (see below). Then you can Update the translation project and the resourcestring names and values should now match. Unfortunately the existing resourcestring translations will be marked obsolete since the source name/value pairs have all changed. The only way to recover the resourcestrings you have already translated is to add the translated resourcestring values to the Translation Memory before the update and then use the Translation Memory to apply the translations again after the update. The DRC-file contains the mapping between resourcestring names and string resource IDs. It is created by the Delphi compiler if the "Output resourcestring .drc file" linker option is enabled. Since this isn't obvious I have just updated the DRC-file prompt to state this fact: I have also added a check to display a warning if the timestamp of the EXE and DRC-files are too far apart (>10 seconds), indicating that they are probably out of sync:

Works fine for me on Window 10.

The revision you used should be Okay. I'm curious about where you got that warning. There should be no hints or warnings when compiling and no where in the source is there a #$1000. Anyhow, if you're up for it you can try downloading the precompiled application instead and see if you can reproduce the problem with that: http://melander.dk/download/amTranslationManagerInstall-1.1.7465.55536.exe I committed a change yesterday that replaces the empty DLL stub I use to generate the resource modules with a smaller file. I haven't tested the new or the previous version of the DLL stub on Windows 10 though, so I will do that right now. Windows doesn't use the file type for anything. It's the file header (the PE header) that identifies the file as a DLL. The "DLL" file type is just a convention - and the default file type for DLLs. You can call them anything. For example Control Panel applets (*.cpl) and Screen Savers (*.scr) are also just DLLs. The resource modules are loaded by the Delphi RTL using the LoadLibraryEx API function. See LoadResourceModule() in the system.pas unit. When your application starts the RTL by default looks for a file with the same name as the application and an extension that matches the current locale. If that file is found it is loaded with LoadResourceModule. See GetResourceModuleName() for the (broken) algorithm that calculates the name of the resource module file. It's pretty obfuscated due to all the conditional defines.

You can create that from within the IDE: Component | Import Component | Import a Type Library

The /regserver should register the type library embedded in the application (via TComServer.UpdateRegistry). Didn't it do that?

...and you can juggle chainsaws.

Yes, the registration is stored in different places in the registry but that's really a Windows implementation detail. For out-of-process COM servers a 32-bit client have no problems connecting to a 64-bit server and vice versa. Here's a nice summary: https://mariusbancila.ro/blog/2010/11/04/32-bit-and-64-bit-com-servers/ For in-process servers (i.e. basically just a DLL) the bitness must match. https://en.wikipedia.org/wiki/Law_of_the_instrument

Don't use regsvr32 - that's for in-process servers. You can't use task manager to verify that you server is being executed (it terminates as soon as it finishes registering) but you should be able to verify if your server has been registered by looking in the registry. If you don't know where to look then you need to read some docs on msdn. COM is a nightmare if you don't understand how it works. Anyhow, try this: Run Delphi as as administrator. Enter /regserver in Run|Parameters Place a breakpoint in TComServer.Initialize (in the System.Win.ComServ unit). Run your server in the debugger. You should now be able to trace through TComServer.UpdateRegistry and verify that it ends up registering your type library and your COM classes (probably via TComObjectFactory.UpdateRegistry).

I'm assuming you have compiled amTranslationManager.exe yourself since you seem to be running it in the debugger. What source code revision are you building from (git hash or timestamp)? What version of Delphi are you using? What version of Windows are you using? The helloworld.nld filename is correct. The file is supposed to be a DLL that only contain the translated resources (i.e. no code). The NLD file type is just the ISO 639-2 language code for Dutch (Netherlands).

It actually does but since the installation process is a bit confusing it's easy to miss. After the patch has been downloaded patch2-readme.txt is opened in notepad. The readme states: Yeah. How difficult would it have been to create a simple InnoSetup installer that automated the process completely? Including registering the fact that the patch had been installed: [HKEY_CURRENT_USER\Software\Embarcadero\BDS\21.0\InstalledUpdates] "Patch 1"="Patch1 for RAD Studio 10.4 (build 9797)" "Patch 2"="Patch2 for RAD Studio 10.4" Not impressed

Spotted a copy/paste bug in CompilersDecl.inc : const RAD_Rio = 32; RAD_10_3 = 33; RAD_Tokyo = 32; RAD_10_2 = 32 Of course it can't detect capabilities that were introduced after it was written but if you are using those then you must be already using a newer version of Delphi and thus be aware that you need to update the file. I guess it depends on how and what you use it for. Contrary to many other similar version include files this one appears to be forward compatible if you use the capability or XXX_UP symbols; For example even though it doesn't explicitly contain defines for Delphi 10.4 it will define the RAD_10_3_UP correctly on Delphi 10.3 and later: {$IF CompilerVersion >= 33} {$DEFINE RAD_10_3_UP} {$DEFINE RAD_RIO_UP} {$IFEND} Many libraries still use the practice of testing directly against the VERXXX defines, with no fallback, and thus break when a new version of Delphi is released, for no other reason that the shortsightedness of the authors. For example the following is from a well know charting library: {$IFDEF VER330} // RAD Studio XE v12.0 Rio (Carnival) 2018 (v 20.0) 32bit / 64bit / OSX / iOS 32-64 FMX / Android & C++ / Linux 64bit {$DEFINE D3} {$DEFINE D4} {$DEFINE D5} {$DEFINE D6} {$DEFINE D7} {$DEFINE D8} {$DEFINE D9} {$DEFINE D10} {$DEFINE D105} {$DEFINE D11} {$DEFINE D12} {$DEFINE D14} {$DEFINE D15} {$DEFINE D16} {$DEFINE D17} {$DEFINE D18} {$DEFINE D19} {$DEFINE D20} {$DEFINE D21} {$DEFINE D22} {$DEFINE D23} {$DEFINE D24} {$DEFINE D25} {$DEFINE D26} {$ENDIF}

I wouldn't say the future looks good when you're on life support. Naturally Cobol will die for good some day, when the systems using it are finally retired, but I'm pretty sure it will outlive for example JavaScript. Of course this doesn't mean that we should all drop what we're doing and learn Cobol instead. What I meant was that this statement: appears to assume that it's the popularity among "young people" that decides if a language thrives. There's some truth in that, but it's not the whole story. It's ultimately "the grown ups" that decides what tools to use to get the job done. That's why we don't have to rewrite EVERYTHING every few years when a new shiny toy appears.

So I'm guessing the asm it generates uses indexed addressing rather that indirect addressing. Right?

I'm curious; Why would you need that information?

My experience is that in some cases indexed access can be much faster than incrementing a pointer, so I guess "it depends". I'm afraid I can't remember any specific cases.

There are more developers than there are developer jobs. Some will have to take what they can get and use the tools that the job require. That's just the way the world works. Otherwise we would all be astronauts or firemen.