Anders Melander

I'm afraid I can't answer that. Supposedly there used to be a registry key that could do the trick (HKCU\Software\Embarcadero\BDS\19.0\FormDesign\DefaultFont) but that didn't work with the embedded form designer and as far as I can tell it no longer work with the detached designer either. I guess you could create an IDE plugin that modifies the form designer but that's probably more work than it's worth. Maybe just a design time package that modifies Application.DefaultFont like above will do the trick, but that will affect the whole IDE. FWIW I understand the OCD in you that wants the form to use SegoeUI at design time but it shouldn't really matter. If you have designed it "properly" then the form should be able to display correctly with both SegoeUI and Tahoma. After all you don't know what font the end-user will be using.

I guess it's a matter of perspective. If you didn't expect the thread to start until after the constructor then I can see how the behavior would be seen as a bug. I never expected it to behave any other way so to me it was just an annoyance. A bit like FreeOnTerminate. A pretty good way to shoot one self in the foot.

That must have been around the time when I stopped reading the documentation 🙂 I can't see why it would be classed as a bug though.

Oh... You're right. It's even documented: I think I'll continue to use the create-suspended pattern anyway since it explicitly does what I wish.

I know that this isn't really what you're asking but I don't think I've ever had a case where one didn't need to create suspended. You always have to either pass some information to the thread or initialize it's data and if you don't create it suspended there will be a race between the creator and the thread for access to the thread data structures. For example: type TMyThread = class(TThread) private FData: TSomeType; protected procedure Execute; override; public construtor Create(const AValue: TSomeType); end; construtor TMyThread.Create(const AValue: TSomeType); begin inherited Create(False); // Thread starts immediately FData := AValue; // Race condition here end; procedure TMyThread.Execute; begin FData.WhatEver; // Race condition here end; var Thread: TMyThread; begin Thread := TMyThread.Create(SomeData); end;

@Vandrovnik A new version with the Duplicate View is now available: http://melander.dk/download/amTranslationManagerInstall-1.0.7254.4932.exe I had a bit of trouble getting this version up as BitDefender kept insisting that amResourceModuleBuilder.exe contained the Gen:Variant.DCry.1 ransomware. In the end I had to simply include the previous version of that file instead. Description of the Duplicate View above. I have also included the "Locate in TM action: As the hint says, the action attempts to locate the focused source/target pair. It tries to be a bit intelligent about it in case there are multiple candidates (due to sanitation/equalization) so it will give priority to exact matches, case insensitive matches, sanitized matches and equalized matches, in that order. If a match is found the TM is opened and the matching row is selected: This version also includes Copy to clipboard (as CSV) and Save to CSV. Next up is Paste and Import from CSV.

Done. The action performed on values to check for equality isn't called equalization though. It's called normalization. Internally, in the source, I call it Sanitation (i.e. I remove all the junk). Anyway, here's what I have implemented: The "duplicate view" is invoked via the popup menu: When viewing duplicates a new column is added. This column displays the sanitized value of the selected language. You can control what sanitation rules to apply. Only rows that have duplicate values are displayed in duplicate view. In case you wonder why I'm not grouping on the Duplicate column; I tried it but found that it just cluttered the user interface and made the grid too cumbersome to navigate. I'll try to get a new version with these changes released tomorrow or Tuesday. I understand the problem. The dialog is already trying to communicate too much information and has become too complex for a standard message dialog. I have already redesigned it a bit (see below) but in order to add a "Replace" action I would have to switch to using a full blown Task Dialog or even better a custom dialog. That however will have to wait. I think the best I can do in the short term is to add a "Find in TM" action. This would open the TM, try to locate the currently focused Source/Target value pair and focus the target value in the TM.

In the project file (the DPR file) I do this before the first form is created: if (CheckWin32Version(6, 0)) then begin // Application.DefaultFont is the font used when TForm.ParentFont=True. // It is Tahoma by default but should be Segoe UI on Vista and later (according to MS UI guide lines). // See InitDefFontData() in graphics.pas Application.DefaultFont.Assign(Screen.MessageFont); // DefFontData.Name specifies the default font for everything that doesn't specify a specific font. // For now we leave it as is (Tahoma). At some point it should follow the system default like above: // DefFontData.Name := Screen.MessageFont.Name; end; And then I just make sure to set all forms ParentFont=True at design time.

Nope. A deck is model, data, state and maybe presentation. The game is logic. A game is not a deck. A game uses a deck. Really basic OOP since we're going there. Why stop there? What about layers, filters, transformations, scanner and cloud support. Yes, let's add SOAP, REST, FTP and Kermit support in case need to transfer these images between systems. Why do we need different classes at all? We could just create a single class that does EVERYTHING. You're confusing high level ease of use with low level architecture. The difference between the VCL and f.ex. ImageMagic is that one of them has it and the other doesn't. I'm guessing you've never read through the ImageMagick source code since you use it as a reference. I have. It's written in C. That might give you an idea of the inheritance scheme it uses... No? There's really no point in me trying to explain my point further since our reference frames are obviously worlds apart. Good night and good luck.

Monolithic design... Pick up any book on software design and it will explain why that is not a good idea. I'm not going to do it here. Unnecessary coupling. The above book will explain that too, but ask instead: Why should it? Make a toolbox of individual tools that does as little as possible as good as possible and then assemble them into something larger. A swiss army knife is good to have if you're stranded on a deserted island. Besides that it's only good for impressing your 7 year old friends. Anyway, we're hijacking Foersom's thread. I'm outta here.

Here's what I have implemented for now. It's very rudimentary and applies globally:

BMP, PNG, JPEG, GIF etc. are encoding formats. The sole purpose of TPNGImage, TJPEGImage and TGIFImage is to read, write and display these formats. Their internal representation is optimized to handle the features of the file format. They are not optimized to handle image manipulation. TBitmap on the other hand implements the BMP encoding and is internally represented as a native Windows DIB or DDB. TBitmap can wrap these with a TCanvas and thus provide access to most of the functionality of the GDI through the canvas. Additionally almost all other formats can convert to and from TBitmap so there's no reason why all the other formats should duplicate the functionality in TBitmap/TCanvas/GDI. They would just have to convert to/from TBitmap internally to do so anyway. Btw, using TCanvas.Pixels is extremely slow but fine for learning and very minor drawing tasks. For anything serious you have to mess with the raw DIB data directly - or use something like Graphics32 which does that for you. When you're using Pixels to manipulate the whole bitmap then the optimizations in the code become pretty pointless and only obfuscates the algorithm.

No. But... OK. I will have to do something about that. For matches from TM the rule is that if I find an exact match in the TM then I do not equalize case (*). For example if I'm translating "Foo" and I find "Foo"->"bar" then I use "bar" as the translation. If I find "FOO"->"BAR" then I equalize "BAR" to "Bar" and use that. *) I still equalize endings and accelerators regardless of match exactness since the I consider TM data fidelity/consistency somewhat poor. I currently have the following equalization rules: If source has an accelerator then make sure target also has one. If possible use the same hot key. If source does not have an accelerator then accelerators are removed from the target. If source ends with a colon, semicolon or ellipsis then make sure the target also does so, but only add new ending if the target ends with an alphanumeric character. If source does not end with a colon, semicolon or ellipsis but the target does then remove the ending from the target. If source is surrounded with ( ), [ ], { }, " ", ' ' or < > then make sure the target also does so. If source is UPPER CASE, lower case, Title Case, Sentence case or simply Starts with an uppercase letter followed by a lowercase letter then make sure the target is too. It's implemented in the MakeAlike function in amLocalization.Utils.pas If I'm understanding you correctly then the only safe case rule between Czech and German is the UPPER CASE and maybe the Title Case rule. So if I'm making equalization configurable at what level should it be configurable. I mean I could make everything optional and all values configurable but it will be a nightmare to implement the UI for it and probably far too complex for the user to manage. I'm also guessing that the desired rules would differ between projects or even within projects, between languages. No. The "Apply new translations..." and "Apply to similar values" options controls if new translations are automatically applied to other identical or similar (via normalization) terms. For example if I translate "Foo" to "Bar" in once place, then it can automatically apply this translation to all other instances of "Foo" in the project. If the "similar" option is enabled then it will also apply the translation to "&Foo"->"&Bar", "FOO"->"BAR", "[foo]"->"[bar]" etc.

New version up now: http://melander.dk/download/amTranslationManagerInstall-1.0.7251.4.exe BTM should normalize those when they are applied. For example if you have the translation "&Foo:" = "B&ar:" in the TM and you apply it to "(foo)" then the translation automatically becomes "(bar)". I try to equalize case (upper/lower/sentence/title/etc), accelerators, format strings, surrounds ()[]{}, etc. and terminators .:?... There might be more. I can't remember right now.

Bloody hell! The 7234 release was an early beta. This has happened before. From time to time my web hosting provider messes up and replaces new files with old files. I can see that the new files are gone and only the old file are left. I guess this means that everybody has been downloading obsolete versions. Please stop everything until I have resolved this problem. So you understand all those languages? Anyway I understand the use case now. I'll see if I can cook up a good UI for it.

No not yet. The plan is to have support for multiple TM files and per project TMs. For now you can only change the TM via the registry: HKCU\Software\Melander\TranslationManager\Providers\TranslationMemory\Filename Actually I just realized that you should have (*) been able to use the "portable mode" to get per-project TM. If you copy amTranslationManager.exe to the project folder and then start with the -portable switch then BTM will look for the TM in the project folder. Just make sure that the above registry key value contains the value "%DATA%\TranslationMemory.dat" so the portable config file is initialized with the correct default value. *) Unfortunately it seems I managed to break portable mode just before release so I'll have to get a new version released before that solution can be used. I'll get that done this week end.

No not yet. The plan is to have support for multiple TM files and per project TMs. For now you can only change the TM via the registry: HKCU\Software\Melander\TranslationManager\Providers\TranslationMemory\Filename No. The file can be saved anywhere. Inside the xlat file (it's an XML file) there should be a reference to the source application and this should contain a relative filename. Like this: <xlat> <project sourcefile=".\Win32\Debug\HelloWorld.exe" stringsymbolfile=".\HelloWorld.drc" language="1033"> ... The sourcefile value is relative to the xlat file. The stringsymbolfile is relative to the source file. There was a bug in an earlier version that broke relative file names but they should work in the latest release (v1.0.7241.65070). Yes. I can add something like that. I already do duplicate detection when adding terms from the translation editor, but I don't do anything when importing translations in bulk (e.g. from TMX).

No. The Microsoft Translator Text service only support a single translation per language. That sucks. I guess they're not dogfooding this API. The strange thing is that they claim it powers Bing translate which can find multiple translations per source value.

Just use the [Delete] key...

Sure it's possible. Translations are always associated with a context, the context being the module (form), the component and the property. If you're doing automatic translation (i.e. machine translation), then the context is not used, only the source language and source text. However if you have more than one translation of a term/text in your Translation Memory, then BTM will prompt you to choose a translation for each of the different source terms. You can choose to use the same for all or use a different one for each of them. For example here I have added the three different Czech translations of the term "Volume" to my Translation Memory (forgive me if I mistranslated - I don't speak Czech 🙂 ): If I now perform a machine translation from Translation Memory then I will be prompted: If doing manual translation then BTM will indicate to you that it already know these translations (even if you haven't added them to the Translation Memory) so they can be easily reused. For example the grid will mark the terms that has known translations and display them as a hint: and during manual edit you can choose from these translations in a drop down list: The principle is the same if I perform machine translation using one of the web services. For example here's the prompt I get when using Microsoft Terminology Service: Strangely, if I use Microsoft Translation Service then I only get one term back: "Objem". but that might be caused by a misconfiguration on my part. I'll investigate.

Amen! https://killedbygoogle.com/

Thanks. I had a feeling I might end up having to script my way out of it.

Well yes, but there's the existing installer types and components to take into account. I mean I currently have the default three Types: Full, Compact and Custom. I don't mind getting rid of Compact but if I must chose between Full and Custom then it's Full that goes. Anyway, let's say I go with your suggestion: Normal and Portable, both of which will probably then install the Full component set. Now I then need to copy some files into {userappdata}\foo in Portable mode but into {app}\bar in Normal mode. How do I do that without having to duplicate the [files] entries? And then there's the [Icons] section. I should probably not create any shortcuts in Portable mode but as fare as I can see it's not possible to control [Icons] based on Type - only based on Components.

It's no problem creating a separate installer for portable mode. I could even just zip the files and leave it at that. The problem is getting the existing installer to have a "portable mode" option.

The application would do this for you automagically, so you wouldn't notice that it's using the registry internally. Anyway I just finished implementing it. It's available in version 1.0.7241.65070 You can now run in portable mode either by specifying it with a command line switch: "amTranslationManager.exe -portable" or by placing a file named "portable" in the application folder. The application settings dialog can also do this for you. When in portable mode, settings are read from and written to a "amTranslationManager.portable" file located in the same folder as the application. Application data files (Translation Memory, user spell check dictionaries, etc.) are also stored in or under that directory. One problem that I haven't solved is how to get the Inno Setup installer to create a portable installation.