After having looked at most of the major translation tools for Delphi, the conclusion is:

After having looked at most of the major translation tools for Delphi, the conclusion is:

– They all suck in different ways

– Those with visual tools, crash in different ways

– They are not really VCS friendly at all

– Team support is mostly not present

– Documentation is either near non-existent, incomplete, or outdated

– Prices go from “free”, to affordable to ridiculously expensive

There seems there is no bleeding edge tool here – only a lot of blood, sweat and tears – for the user of the tool.

29 thoughts on “After having looked at most of the major translation tools for Delphi, the conclusion is:

  1. Thomas Mueller I think we tried it some years ago, but at the time it wasn’t possible to compile with the current Delphi version? Something stopped the experiment, although I can’t remember what it was. Perhaps that is why it wasn’t on the list this time?

    Can it easily scan existing projects and create a translation foundation where you start working from? Does it have a translation editor? Does it support multiple embedded languages and run-time language switching?


  2. Stéphane Wierzbicki Yes – I crashed it several times, and made changes to the languages and project config – and suddenly it failed to load the translation streams, and I could not figure out how to repair it. This happened several times, and with four people fiddling with the same project through SVN – it just appears to be too unstable for team use.


  3. Lars Fosdal You don’t translate on the forms(you do translate it, but not in delphi). Sisulizer scans the project after our build is done and outputs the updated sisulizer-projectfiles. It is then possible to see new entries. Sisulizer supports translation of duplicates. Therefore if the same nativestring is used at multiple places, you need to translate it only once(except when you need distinct translations for some reasons). Not sure atm which edition we use(if there are multiple).


  4. Alexander Benikowski is right. We use Sisulizer. On our Dev machines we use Sisulizer Translator Edition and on our build machines we have Sisulizer Enterprise running (which comes with a command line tool, that scans the binaries for changed / new resource strings and creates language files).

    Only homemade problem we have is that we have a single translation project for all translated binaries. So if you translate in two separate branches you usually have a hard time merging the translation project files (SLP is XML and we don’t have a dedicated XML merging tool). This is why we usually only translate in our main branch.


  5. Lars Fosdal I think the answer is yes to all questions, but the distribution on the download page is outdated. The .po-editor Gorm, which is not part of the distribution but in the same svn repository, supports translation repositories that can be used on multiple projects. It’s pretty stable. But the support is basically nonexisting. On the other hand you have the sources of everything and it’s a standard format (.po / .mo files).

    I don’t know about support for other platforms than VCL though, it might work, but I never tried it.


  6. Thomas Mueller – I am already 100% dedicated to maintaining and developing our internal tools. I don’t need the potential maintenance load of a unsupported tool.

    I believe there is a market for a heavy duty translation tool that is designed for VCS and using cloud or deployed databases to hold translation repositories. A tool that has proper documentation, how-to’s, and starter guides. A tool where you can export / import translations in standard formats, so that you can ship them off-site to a pro translator.

    Sisulizer is almost there, but the price is ridiculous if you only want Delphi translation, but need team repository (Enterprise is 1K€ per license).

    The docs are outdated. The application is not very user friendly, and it crashes.


  7. Lars Fosdal I have been working with Sisulizer almost everyday for more than 5 years now and I haven’t seen it crash a single time. While it has its problems here and there e.g. with auto-translating, I can really recommend it!

    If the price is too high, Lars, then put the Enterprise version only on one build server and have your translations be built only on that machine.


  8. Gregor Steinweg – Perhaps I was just unlucky, because I managed to make it crash on first use. As for the price, money is not the object. Perceived value for money – is.


  9. Thomas Mueller Lars Fosdal

    The answer is yes to all your questions. We are using dxgettext for more than ten years now. Started some projects from scratch, added gettext support to a long running project later. Changed the translation base of this project from German to English using gettext tools and some python magic to swap the strings in the dfm files.

    Gettext .po files are scm friendly. We wrote a small tool (in Delphi) that removes the line numbers from the .po files in order to make them even more scm friendly.

    Our desktop tool for translations is Virtaal most of the time, poEdit is also nice. I never got warm with Gorm, but that’s just personal preference.

    There are tons of Web Services out there (also open source, if you want to run it inhouse) that allow to collaborate on translations.

    Check – Expertise in community localization | Translate House for example

    For TortoiseSVN we are using for a long time now.


  10. Lübbe Onken I also have been using it for more than 10 years for two different employers. But I’m biased, because I have write access to the repository and can therefore easily fix bugs and add features to the tools whenever it is required. Not having the line numbers in the .po files is a good idea, because they make using SCM a bit annoying. Maybe I’ll add a switch for disabling them.


  11. Looks like it boils down to :

    1. If you have got used to it, it is the best tool of all.

    2: If you have the sources and are willing to invest the time you can usually tweak it to your needs.

    3. If it cannot be tweaked you can build your process around it.

    This doesn’t make it easier when you have to choose for the first time.


  12. You’re absolutely right Uwe. We were in that situation ~10 years ago and chose gettext when we started from scratch.

    There may be better tools around right now. Our translation process is up and running, it works well and there is no reason to change it.

    I’m just sharing my experience. Even though gettext is “old”, it is also stable and reliable.


Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.