The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Database stored GUI prompts

For maintenance and globalization purposes, I was thinking of  storing the GUI prompts in the database, and retrieve them using a function call. This has lots of benefits from a maintenance point of view, especially if we hook them up to the documentation.

However, before we go down that road, I'm just curious if anybody else has done that, or does everybody just hard code the prompts? Assuming that there aren't issues with retrieving the prompts in a timely manner, are there other non-obvious "gotchas" to look for?

Steve Hirsch Send private email
Monday, March 26, 2007
Remember to put the error messages local or when you can't contact the database you get an error that says "" "" "" "" "".
Martin Send private email
Monday, March 26, 2007
By "globalization" i'm assuming you're referring to internationalization, where you'd like to abstract the textual elements of your GUI to allow them to be presented to the user in varying languages.

A good summary with a whole host of links can be found here:

Most languages have a somewhat "standard" way of dealing with i18n.  For java, an easy tutorial can be found here:

You're idea of implementing this on your own and leveraging a database for persistance of this information doesn't sound like a great idea to me.  The language in which you're developing likely has an implementation for this and expects a certain interface (property files with a locale as part of the file name, for example).  This also eases maintenance, as you can keep track of language file updates in your version control system.  In addition to that, if you suddenly find that you're app is a hit in estonia, and you find someone who can translate from english, you can send them your english (default?) properties file and they can translate each phrase for you in the estonian version of that properties file.  re-deploy your app with this new resource and you're good to go.
brian doll
Monday, March 26, 2007
There are so many gotchas its hard to know where to start. IMO, translating (in our case English to French) ranks amongst the topmost things that people underestimate. Here are a few that come to mind:

1. Transaction-specific text within messages where the position varies depending on the language (eg. 'Your account is overdrawn $100', might translate to 'Your $100 overdrawn is', you get the idea.

2. Text that when translated is 10x longer than it was in English and screws up all your GUI layouts.

3. Date and currency formatting conventions.

4. Stuff that Windows handles nicely for you (eg. #2 above), vs. stuff you run for the same users off non-Windows boxes.

5. Accented characters and difficulty of handling same, esp. when you mix environments (eg. #3 above).

6. Differentiating between translating for Users of your app, vs. Customers of the user (eg. if you are printing invoices, chances are you want the invoice to be in French even if the guy doing the printing is English, but the same does not hold true for internal reports).

That's all I can think of right now, but there are zillions more.
Greg Send private email
Monday, March 26, 2007
Most of the programming world uses the term "localization" for what you're talking about. Even MS is moving away from the term "globalization" in its more recent .NET docs, perhaps suggesting that they recognize the value of common terminology.

I would use your language's built-in localization features, or a heavily used third party localization library if your language doesn't support it directly. The big problem I see with putting the messages in the database is that it makes it harder to search the code for the source of a particular message. In a typical localized application, that's a two-step process:

1. Grep the entire codebase for the message. Find it in the appropriate localization file.
2. Grep the entire codebase for the matching symbol.

The problem with putting the strings in the database is that it's much harder to search for all SQL queries that will return a particular row than to search for a fixed symbol. That's assuming that everyone understands your localization strategy. A maintenance programmer who doesn't realize that messages are stored in the database will be completely lost.
Monday, March 26, 2007
I'm going to speak up and say it's not necessarily bad to roll your own localization.

Here's an example of when it might be okay:

Let's suppose you can't live with what the language's built in tools say about localization.  For example, many languages tend towards the idea that localization is done by the same type of people as the developers, using similar type tools, i.e. early in build process, tools orientated towards knowledgeable computer users, etc.

If you want your end-users to do translation, then rolling your own solution may be reasonable solution.  However go into it with your eyes open: localization may encompass more than simply changing prompts, e.g. foreign characters, Right to Left, currency symbols, number punctuation symbols, etc.  As well as in some apps different graphics, etc.

In one of my apps, I had to roll my own solution for this reason. Mine was not a database app. But the coding style of the API might be similar.

Most of my code was scattered with code something like (not actual code but similar):

string mystring = GetLocalizedString( IDS_MESSAGE_YOU_PRESSED_THE_WRONG_BUTTON )  ;

string mystring = GetLocalizedString( IDS_MESSAGE_TELL_USER_I_LIKE_CHEESE )  ;

Which was not that different from if I had used the built-in localization tools.  I deliberately made my API similar as possible.

The clever bit in my app was all inside GetLocalizedString.  It of course cached the message strings, etc.
S. Tanna
Monday, March 26, 2007
As my app was translatable by end-users with no knowledge of computers, and the translation tools were included with the app:

There are now more translations of that app - and more up to date - than any other software I have ever worked on.  Including software were a big name computer company who licensed the software had a whole staff of professional translators.
S. Tanna
Monday, March 26, 2007
"However go into it with your eyes open: localization may encompass more than simply changing prompts, e.g. foreign characters, Right to Left, currency symbols, number punctuation symbols, etc.  As well as in some apps different graphics, etc."

I think this alone is a good reason not to place such strings in the database until you're very comfortable with the commonly encountered potential problems.

For example, even Microsoft has problems with formatting large numbers, dates and times according to regional tastes. Skim through the comments to this blog posting...

Some code is going to be required and unless you knew ahead of time what you'll need to deal with, it's hard to write a single routine that can read the correct string from a database. With localization libraries, much of the hard work is already done for you.
Monday, March 26, 2007
I prefer to write a "translator" class to encapsulate this kind of functionality. I'm currently keeping translations in XML files that are loaded when the app runs. But it really doesn't matter how you do it. The biggest issue is getting the context of each prompt. The same prompt can be used in different contexts which may cause a slightly different translation. For example, you might put "Customer Number" on a prompt but need to shorten it to "Cust Num." if placed as a column header.

What I hope you don't mean is that you intend to store the actual state machine itself in a database. I've worked with several "prompting" systems that attempted to tablize the state machine and prompting rules and they have all been colosal failures. I get the feeling that you are talking about localization so I won't go into any more details. But if you intend to try and store the state machine in the database then please reconsider. I'll give you more details if you need another perspective.
dood mcdoogle
Monday, March 26, 2007
Sounds like storing the prompts in the RDB itself is a bad idea. Gotta chew on this some more.

I do like the idea of the end users being able to do their own prompt translations. We put out an incredibly configurable product as is, our users are pretty sophisticated, so I think that they can handle it.
Steve Hirsch Send private email
Tuesday, March 27, 2007
The two main ways that I've seen this done are with "literals" and with "translations". Both are similar but have slightly different implementations.

Literals are what you appear to be describing. Each piece of text on every screen is a separate literal and can be changed by the user. For example, if the word "Customer" appears on three different screens then it would be represented by three different literals. The upside is that you have complete control over every single text field in the application. The downside is that this control comes at a pretty steep price when developing. Programmers typically have to specifically call a literal object to perform the translation passing some literal ID for each and every text field. Also, users may end up having to configure the same string many times. For example, if the word "Customer" appears 100 times in my app then the user is required to change 100 literal entries to convert it to the word "Client".

Translations work much like a dictionary. You have a single entry for each string in the application. The upside is that this is easier to implement and can be centralized. When a form is shown you can run through the translator to change all labels or column headers. The user also only has to change a specific translation once (say from "Customer" to "Client"). The downside is that you don't have the fine grained configurability that literals provide. If a user wants to use the word "Customer" on one screen but "Client" on the next, they are out of luck. Finally, the sheer volume of configuration data is typically much less with translations. With literals, every single new label or string added to the application makes the configuration requirements grow. With translations, adding a new label or string that has been used before in the application doesn't cost anything.

Also, keep in mind that translations do not have to be done to support regionalizing the app for foreign language support. A client might still want to use English but might simply want to change a couple of labels to match their internal documentation/usage. The case I gave above with converting "Customer" to "Client" is one such example.

So as I said earlier I have decided to go with the translation approach instead of literals. I've used the literal approach in the past and it just gets too bulky as the application grows. I provide the ability to translate into different languages and even customize the English equivalents of most of the prompts in the system. It's certainly not perfect but it goes on under the covers most of the time.
dood mcdoogle
Tuesday, March 27, 2007
The more I think of this, the more complex it gets. We're an application development environment; on top of that, we have eaten our own cooking and used our environment to create an end user application.

In other words, there're two levels of prompts: one for our base product, and one for the applications created using the base product.

Hmmm. I hear what you're saying Dood. Creating a glossary sounds good.

The real question is, it'll be a large cost. Don't know what the ROI would be.
Steve Hirsch Send private email
Tuesday, March 27, 2007
"Localizers" are one of the software types that lots of microISV's are offering.  They're generally inexpensive, and there are almost certainly multiple choices for whatever dev environment you're using. 

Here's one for Delphi, for example:

But you can locate others just by typing name of your dev environment and 'localizer' into Google or Yahoo.
Herbert Sitz Send private email
Wednesday, March 28, 2007

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

Other recent topics Other recent topics
Powered by FogBugz