* The Business of Software

A former community discussing the business of software, from the smallest shareware operation to Microsoft. A part of Joel on Software.

We're closed, folks!

Links:

» Business of Software FAQ
» The Business of Software Conference (held every fall, usually in Boston)
» Forum guidelines (Please read before posting!)

Moderators:

Andy Brice
Successful Software

Doug Nebeker ("Doug")

Jonathan Matthews
Creator of DeepTrawl, CloudTrawl, and LeapDoc

Nicholas Hebb
BreezeTree Software

Bob Walsh
host, Startup Success Podcast author of The Web Startup Success Guide and Micro-ISV: From Vision To Reality

Patrick McKenzie
Bingo Card Creator

Translating Software

So I've been getting a few requests for my software in different languages. So far, it's a non-op, as the only way (in my mind) would be to share the source code. And that ain't gonna happen.

But perhaps there's a work-around. (Isn't there always? :)

If anyone can recommend a way to do this for the GUI only, I'd surely appreciate it. If I could just access a list of menu commands and what-not in different languages, that would certainly help... (I think?)

What do you guys do when asked to provide such a thing? Do you comply? If so, how hard was it, and was it even worth it?

Thanks!
Nicole Miller Send private email
Wednesday, June 17, 2015
 
 
One of our product's auxiliary capabilities is setup package generation. Over the years, we had the users localize our installer to half a dozen languages. We have all string constants gathered in one file that we give to one user to translate, and then give their results to another user speaking the same language natively, for verification. Worked very well so far, with the exception of German. (It turned out that Swiss German != German.)
Dmitry Leskov Send private email
Wednesday, June 17, 2015
 
 
If I ever have to have different languages, I'll just be having different language files (text) that the app reads and applies to the controls at run-time.  It's quite easy to do.
PSB136 Send private email
Wednesday, June 17, 2015
 
 
And no, you don't have to share the source code at all.  Don't believe anyone who says you do.
PSB136 Send private email
Wednesday, June 17, 2015
 
 
If you use Qt for your UI, translation is very straight forward.

You basically wrap all user visible strings in a macro, and a tool extracts them out to an xml file, along with the strings from the UI files. You can then simply send out the xml file to your translators.

After compiling the translated results in, that macro will dynamically switch out the strings for the current language.

More info here: http://doc.qt.io/qt-4.8/i18n-source-translation.html
Calvert Send private email
Wednesday, June 17, 2015
 
 
Similar to what Calvert and others said look up i8n internationalization in what ever language/framework you're using.

The basic concept is to split all your strings for the gui into its own file as a set of string constants. Then you can give that file or list of strings to a translation service to translate them for you.

It's typically the way multiple languages are handled in software.
TrippinOnIT Send private email
Wednesday, June 17, 2015
 
 
For me, the hard part isn't the conversion.  What causes me problems is providing support for non-English speakers.  The Google translator doesn't cut it.
Michael Rainey Send private email
Wednesday, June 17, 2015
 
 
Two things to note with supporting multiple languages it that some languages are right to left and not left to right. Another consideration is that the translated word or sentence may be of a very different length and not fit neatly in the control (which may have been arranged on the GUI with English originally in mind).

Not that these are major road block in supporting multiple languages, just further consideration to be made.
maxr Send private email
Thursday, June 18, 2015
 
 
> Another consideration is that the translated word or sentence may be of a very different length and not fit neatly in the control

Yep.  One of my old Microsoft books from years ago said to allow an extra 33% of space in the control for locale-aware apps.
PSB136 Send private email
Thursday, June 18, 2015
 
 
Another factor that's easily overlooked: translatable terms that come from your database, vs. terms that are derived from code.

For example, perhaps in your system the names of cities are in a table. A Spanish user may expect to see 'LONDRES' instead of 'LONDON'.

So, to be "perfectly international", you may need to isolate all of the language sensitive strings in your database, and possibly spin them out into a separate table (or something).

Also: date and currency formats, did anyone else mention that?
GregT Send private email
Thursday, June 18, 2015
 
 
Wow! Between the responses here and some posts I found in the archives, I found some terrific advice. Thanks so much. Man, this place is awesome! :-D
Nicole Miller Send private email
Thursday, June 18, 2015
 
 
It certainly is :)
Reluctantlyregistered Send private email
Thursday, June 18, 2015
 
 
I just use a local SQL CE database.
The conversion is completely table driven.
When a form loads it queries the dbs with the screen name which pulls back a dictionary of the control names and their respective labels.

Cheers -
Marcus from London Send private email
Friday, June 19, 2015
 
 
The requirement for a substantial help file with a lot of technical lingo adds to the challenge.
Michael Rainey Send private email
Friday, June 19, 2015
 
 
I strongly recommend you use a known native speaker who is familiar with your software's problem domain, or a professional technical translator with verifiable excellence (not just experience) in technical translation.

I find it very challenging to pick the right terms for menus in my own language.

Google Translate does not consistently produce quality translations. Your software will look like an amateur hour hack job if you use it for this.
Scott Send private email
Saturday, June 20, 2015
 
 
The approach depends on what language and tools you used to develop the program. Since it was not specified its hard to give an exact answer. First you definitely don't have to give up any source code. Secondly the general approach of language files is valid, where your UI text is pulled out of the files pointed to by the language determined in various ways, such as an icon selection at the top or different url. It is always easier to do this when initially developing the application but of course we don't always know,
Frank Barbato Send private email
Wednesday, June 24, 2015
 
 
Adding on to Scott's comment: a lot of people don't appreciate country and regional variations. Eg., Latin American Spanish has a lot of vocabulary that's different from Iberian Spanish.

For example, manejar (LA) vs. conducir (Spain) for 'to drive'. Even within Latin America you have issues, for example Argentina does a lot of things differently and I have a friend from Peru who says he has a lot of trouble understanding Chile.

To be really professional, your effort needs to be targeted at a particular country or even region within that country. Google Translate doesn't even try to deal with this.
GregT Send private email
Thursday, June 25, 2015
 
 
Per GregT's comment about regional variations: that's why my EULA specifically states that my apps are written only for English versions of Windows.  If non-English users don't like it, bad luck.  Maybe when I sell a million copies I'll look at professional translation.

I do note, however, that my apps have been reviewed on non-English websites anyway, so it's probably not a major concern.
PSB136 Send private email
Thursday, June 25, 2015
 
 
Well once again, I'd like to thank everyone for their valuable input. I made the decision to wait on this, because even though it may be easy to implement, it's not easy for me to do at this point and time. It's not even sensible, really.

Other, similar software programs provide translations, but after reading everything that you good folks had to say, I can only imagine how awful their renditions are (it's all automated).

So thank you again :-)
Nicole Miller Send private email
Friday, June 26, 2015
 
 
One more point, maybe I missed if someone else already mentioned it.

How often do you release you software? If you release new versions let's say once per year it's much easier to localize compared to software which has continuous releases with new features every few weeks. Will you deal with translators every time when you add single word? This can significantly slow you down or even make you think twice about adding something new.
Suka Send private email
Friday, June 26, 2015
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz