Poor man’s translation tool?
We need to do a multilingual version of a command line tool and I was thinking … yeah, I know … that is usually the first point of warning before I get into trouble. Anyways – this is what I came up with this evening.
I guess this is pretty much a brute force approach – but it appears to have some advantages – such as enforcing coverage of every language that you declare (it won’t compile if you missed a language in a translation constant), allowing you to declare the translations near where they are used, and not adding much bulk to the source code.
But – let me run this by you guys and ask – apart from the obvious reasons that there are actual translation tools out there – is there a reason that I really should not venture down this path? What are the worst traits of this approach? Note that I would use it for only three languages (English, Norwegian and Swedish).
Come on – I want opinions – so don’t hold back, but feel free to suggest alternatives as well.
Lars Fosdal the main reason you should be using a translation tool is that there are so many gotchas in translating that you really don’t want to deal with that. An obvious example is control sizes: in some languages, sentences can get much, much, much longer than in others, so you end up having – say – a message box that either goes on multiple lines or gets its text cut. Same for form captions, group box capitions, etc.It is not something you can whip up and go along with, it requires a bit of study, planning and time. Hence, it’s best left to those who do it as a job. No component package will ever be perfect, but really, it will almost always be better than whatever you can come up with simply because a lot more time has been spent on those than you did on yours. Plus, you don’t really realise how much you need a festure until you hit a brick wall. At that point, you either implement it yourself or switch to a component set which supports it and neither approach is cheap when you are already invested.
What’s wrong with dxgettext? It’s easy to add and does the job well enough. You have to be careful though with translatable GUI objects created at run time.
How would you handle the translation of accelerator keys? (E.g. Ctrl+C becomes Strg+C in German).
One disadvantage: You must recompile the program to add a new language. Other translation systems allow adding languages “on the fly” even by the users themselves.
Also, you will find it difficult to extract the strings to translate, especially from forms. And last, you won’t be able to give the strings to a professional translator in a form they can easily handle.
I should have mentioned that the tool is a command line thing and the translated content largely is text log output – but very good points on UI sizes, order and UI object / action naming.
Thomas Mueller – Adding languages will be something that is rarely done. Changing the tool happens far more often.
But yeah – dxgettext looks good.
I second dxgettext. Works fine for us with several rather large projects. I recommend Gorm for the actual translation, as it also includes some basic consistency checks. Be sure to download the sources and compile it yourself, because all the binary releases are rather outdated. It doesn’t solve the issue of differently sized texts on controls though.
The text size on controls was never a real issue for us. We translate from English to German and half a dozen other languages and I can’t remember when I had to change a controls size, because a translation wouldn’t fit. This includes Chinese, which needs more height (but less width) than western languages.
Interesting that you work with Gorm Daniela Osterhagen. I tried it 3-4 times over several years and never got warm with it. My favorite used to be poedit until about 6-8 years ago. Then I discovered Virtaal, which is a bit sluggish, but has a very useful diff and suggestion engine built in.
I made an alternative tool which can be used instead of poEdit. Look here https://plus.google.com/116383953624489412477/posts/7WN5nLFmo44
Lars Fosdal if you promise this is not something you are going to use for UI 🙂 there’s a simpler approach that you can use. You see, since not one single component/framework can do everything, every multi-language application has several techniques to deal with different things. One of the good techniques you can use is to have a table in your db with two columns: RECORD_ID and RECORD_TEXT. The RECORD_ID will be a compound field with message number and language, such as 12301 and the RECORD_TEXT will be the actual text. Since you are not trying to modify the UI, this is a simple technique which will keep you out of trouble 🙂
Lübbe Onken I like Gorm, because it’s simple to use, even for “non-technical” people like our translators. It’s also written in Delphi, so it’s easy to add features we require. I had added a central translation database to automatically fill in translations for known words phrases, which worked fine for us. (But then Thomas came along and added the translation repository feature to the official sources before my hack was ready to be submitted as a patch.)
It’s also used by some of our customers who want to change translations. They copy one of our po files and create a new “language” which they then force our program to use by setting the LANG environment variable. Sometimes we actually get the po file back with suggestions for better translations. One particular customer has done the translation for some rather obscure African language himself, because we were unable to find somebody in Germany who could do that job, they also used Gorm and said they liked it.
I think we should invite Peter Dunne in this thread if somebody’s got him in circles 🙂
A
Daniela Osterhagen I just compiled Gorm to check how it feels now. This is highly personal, but for me Gorm just leaves a bad first impression. It looks and feels like a tool that hasn’t left the hacked-together state yet. I’m probably not going to do anything about it, because for me the need isn’t there 🙂
To Keep things simple is never wrong i think. We always have to prioritize – install and kickstart the tool or do a quick working thing that will work to get things going (and maybe introduce best practices and tools later). I have used the technique suggested mainly in embedded projects but also in some web-app projects. Granted all UI considerations but sometimes the layout is such (very nice) that you do not have to mind text lengths that much.
Hmm Daniela Osterhagen thanks for mentioning http://sourceforge.net/p/dxgettext/code: yet another tool to master (:
Lübbe Onken . maybe in YOUR case it was not necessary. That however only means that in YOUR case the forms were ok. We see this on a daily basis when we have to add a translation. It really depends on the application.
Andrea Raimondi maybe its because we’re a German company and our developers design the forms so that a German text fits. This generally leaves enough space for most other languages :)