7

So we're looking at the possibility of porting our software to support multiple languages and one of the areas we're going to have to deal with is error messages and other notifications.

These obviously have to be reported to the users in their own language. Our team (largely) only speak English and even if we were all multi-lingual we're looking at selling to a wide range of countries and could never expect to have a reasonable number of people speaking all languages (we're a small company).

The obvious way to get round the language issue when errors or other messages we may get asked about which are being reported is error numbers which would be consistent across language. While these are going to exist in the backend (if only as key on the error message), I'd really rather not throw them at users if we don't have to but I don't have any other solution.

Anyone have any useful suggestions for alternatives?

Improve this question
6
  • 1
    What technology is being used on the front end? Is this a .NET application? Web application? Was localization not taken into account at the application level from the start?
    – Aaron McIver
    Jan 17, 2011 at 22:05
  • Great question! I wondered about this (in the abstract) myself. I am curious how MSFT did it for the MS Office product. Actually, I bet they catch a stack trace without any logging. I like your idea with error numbers. In addition to keeping a local log, you could keep an English one as well at all time ... or have an additional "international" log, where the message is stored as something like date + level + "0023,My Account,Picture0001.png", and the database knows how to convert 23 into a locale-specific format string. Store it as Unicode - hopefully it is not that hard. Just a thought.
    – Job
    Jan 17, 2011 at 22:09
  • @Aaron - Java, multiple interfaces (web and forms). Wasn't considered at the start as the original product is/was specific to the country we're based in and internationalisation would have added a lot of work for no benefit.
    – Jon Hopkins
    Jan 18, 2011 at 11:42
  • @Job WinForms and WPF have tools and best practices for dealing with I18N; which make use of .resx files within the framework.
    – Aaron McIver
    Jan 18, 2011 at 14:40
  • @Jon Added answer based on that knowledge...
    – Aaron McIver
    Jan 18, 2011 at 14:51

4 Answers 4

Reset to default
4

In applications I have done that needed to be multi-lingual we use a table type approach to hold each language set of strings. Access to the table is via an enumeration. This plus error codes that are universal would allow the end user to see your error message while retaining a code value to help the development team. As others have said the end user would prefer to view errors in their native language rather than yours.

Improve this answer
2

If you have the translations in your database, then you have the ability to translate them back to English. After a while you will be fluent in globalized error messages :)

My suggestion is to not worry about that and focus on being user friendly.

Please keep in mind that non english speakers will really appreciate when errors are displyed in their language.

Be sure to have the correct translations, that would be my concern.

Improve this answer
1
  • This is true. I remember trying to debug Word macro problems in Germany (not speaking German) and eventually you just know the relevant stuff without actually knowing how.
    – Jon Hopkins
    Jan 18, 2011 at 14:11
1

Would it be possible to have the program generate an error log file that the user can send you? Better yet if there's a separate crash-reporting tool (which would of course have to be translated to other languages, but that's probaly easier than translating all the messages themselves) that will send all the error data to a special mailbox on your side. That way even if they don't understand the message very well, they can send you the error log and you can dissect it in detail. I know the error number is not your preferred method, but this or the error file sound like they will work.

Improve this answer
1

Since I18N was not taken into account at the start you are going to suffer more problems then simply dealing with error codes.

The layout of UI elements with regard to sentence structure and the growth that can take place when a new language is introduced is one of the most common. In addition dynamically forming sentences or other textual representation on the fly and then tying that result within varying UI elements is another caveat.

My point is that the error messaging presentation would ultimately be the easiest portion to address since they are generally isolated to a dialog; whereas other textual representation within your application is not.

The approach I would recommend is making use of language packs and thus implementing a packing structure for the textual representation of the product. This would allow you to have a .zip or other structure that could be loaded and used at runtime.

When you want to switch languages you could drop the language pack that is desired and restart the application. The language pack would consist of all textual data needed throughout the application. As an error surfaces from the back end a code is used which is product specific between the client and server and is not intended to surface to the user. This code is then mapped to a given client side error which is also static and does not change. The value which that error contains on the client side will be the dynamic portion which was pulled from the language pack at startup. You can then build a proxy between the pulled in data from the language pack and the referenced values within code; allowing strong typing to be used throughout the product but giving the dynamic capability that you seek with regards to different languages.

Improve this answer
2
  • Aware of that but I wanted to keep the question focused on one area at a time... I have many many more potential questions about elements of it coming up.
    – Jon Hopkins
    Jan 18, 2011 at 15:13
  • @Jon Fair enough...make sure to take the entire problem into account before you start implementing a partial solution only to have it needing modification later...
    – Aaron McIver
    Jan 18, 2011 at 15:42

Not the answer you're looking for? Browse other questions tagged or ask your own question.