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.
- 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.
What are your problems with dxgettext? Or did that not make it into the "major translation tools" list? (Apart from outdated documentation, which I can't fix.)
ReplyDeleteIn my opinion dxgettext is awesome and it could be the best if there were a reliant support for FMX.
ReplyDeleteDid you ever tried https://sites.google.com/site/kryvich/localizer ?
ReplyDeleteThomas 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?
ReplyDeleteCan 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?
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.
ReplyDeletewe use sisulizer.com - Localize your software and open new markets
ReplyDeleteWhich Translates resourcestrings and DFMs. Based on Debugmappings it scans/creates entries for available strings to translate(has a GUI-tool to manage it all).
EDIT: FMX is supported, too(we don't use it yet but their site lists it)
Alexander Benikowski How do you deal with teams and concurrent work on the same forms+frames? Which SKUs of Sisulizer do you use?
ReplyDeleteLars 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).
ReplyDeleteAlexander Benikowski There are multiple, ranging from moderate to ridiculous in price. Your Help About will tell you which you use.
ReplyDeleteLars Fosdal i know i know. However i am not on the translation part here^^". Asked one to write here. he can give a more detailed description. However afaik there is a testversion for sisulizer
ReplyDeleteAlexander 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).
ReplyDeleteOnly 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.
Alexander Benikowski I know. I have been testing it a bit.
ReplyDeleteOur choice is tsilang.com - Internationalization, Localization and Globalization Components and Tool for Delphi and C++ Builder
ReplyDelete1. It has visual interface, and also has TM
2. It may store translations in separate files, or in resources
3. It may store translations in "text format" which is great for VCS. You just build binaries before delpoy
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).
ReplyDeleteI don't know about support for other platforms than VCL though, it might work, but I never tried it.
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.
ReplyDeleteI 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.
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!
ReplyDeleteIf 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.
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.
ReplyDeleteThe only one I have experience with is TsiLang and it gets really dreadful when there are tons of forms. Not sure how the others fare,
ReplyDeleteI guess you tested version 4 then?
ReplyDeleteI can only speak for 3.x which has not crashed yet.
Gregor Steinweg Yes, it was v.4. Bleeding edge is messy.
ReplyDeleteAt least they are using Eurekalog, so that I could contribute a sensible crash log.
ReplyDeleteThomas Mueller Lars Fosdal
ReplyDeleteThe 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 translatehouse.org - Expertise in community localization | Translate House for example
For TortoiseSVN we are using Transifex.com for a long time now.
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.
ReplyDeleteLooks like it boils down to :
ReplyDelete1. 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.
Uwe Raabe That is entirely true, and still a conundrum. Loved the Azure Text API and Google Translate API support in Sisulizer, though.
ReplyDeleteYou're absolutely right Uwe. We were in that situation ~10 years ago and chose gettext when we started from scratch.
ReplyDeleteThere 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.
FWIW: Gorm also supports Google Translate and also Microsoft Translator. blog.dummzeuch.de - GORM experimental release
ReplyDeleteOh sh*t, SourceForge apparently is down. I have just implemented a --no-line-numbers switch for dxgettext and wanted to commit the changes. Lübbe Onken if you are interested, an executable is available from here: http://download.dummzeuch.de/dxgettext.zip
ReplyDeleteLars Fosdal Localization isn't a problem I have to deal with, but is something like transifex.com - Localization Platform for Translating Digital Content | Transifex what you're looking for?
ReplyDelete