String table in SQL database?

Andre xxxxxxx

I need to internationalize an application i am developing which UI is currently in english. I thought about putting the strings in a table in a SQL database (Sqlite) and then query the strings at runtime. Are there better options? I don't like multiple string tables in the resources or a resource DLL. I would like to be able to edit the strings side by side where a sql database is the option in my eyes. Any pros and cons? Examples? Thanks Andre

PJ Arends

There are many ways to handle the problem. Your way should work as well as any other. I like to use an ini file for my UI strings as it is an easily editable text file.

"You're obviously a superstar." - Christian Graus about me - 12 Feb '03 "Obviously ??? You're definitely a superstar!!!" - mYkel - 21 Jun '04 "There's not enough blatant self-congratulatory backslapping in the world today..." - HumblePie - 21 Jun '05 Within you lies the power for good - Use it!

Stephen Hewitt

Would this technique perform well at runtime? Unless you had some sort of caching the performance would be considerably slower then LoadString. Even with caching you would have an initial delay while the cache is primed. Steve

Andre xxxxxxx

I don't think that there will be a performance penality even if the strings are queried on the fly. Also they could be cached in a map or array.

Andre xxxxxxx

Do you have all string in one file or one file for each language? The big advantage of a table in a database would be that during development i can just append the strings in english and later i can fill the empty cells with translations. Would you use an integer or string as primary key of the table? An integer (auto increment id) would have the disadvantage that i also need an enum with the ids. I thought about something like this: CString sString = QueryString ("ID_FILE");

Stephen Hewitt

In your particular app it may not be noticeable - But I'd be willing to bet it would be slower. LoadString is a simple API optimized for the simple lookup of strings which are already in memory and SQLLite is a fully fledged database engine. In general generality always has its price. I would suggest that you make a simple app to measure and see - Nothing fancy, just load some strings in a loop and time it. Steve

Andre xxxxxxx

I think we are talking about hundreds or tenth of a second. A sql database would have the advantage that with a simple script the strings could be exported to .c files with static arrays of strings and compiled into the app.

Stephen Hewitt

A tenth of a second is a lot for a computer. You are correct in that if you have a database you have more flexibility - Such as in your example - With this technique I guess you could have the best of both worlds by compiling the strings (from the database) directly into the app via the exported C file. Still to me it seems an overly complex solution to a simple problem - although you may have compelling reason to use a database I don't know about. Steve

PJ Arends

ABuenger wrote:

Do you have all string in one file or one file for each language? The big advantage of a table in a database would be that during development i can just append the strings in english and later i can fill the empty cells with translations.

One language per file. Actually I currently have only English files, but it is simply a matter of making a copy of the file, translating it, and distributing the translated ini file with the app. Or distributing all the language files and having the installer rename the correct one for the language used. Using this method also makes it easier for me (or anyone else) to correct any spelling mistakes or ambiguities that I may have missed when writing the app without having to recompile. One thing I did do though is put all the default strings into the app's string table in English just in case the ini file can not be found or is corrupted some how.

ABuenger wrote:

Would you use an integer or string as primary key of the table? An integer (auto increment id) would have the disadvantage that i also need an enum with the ids. I thought about something like this: CString sString = QueryString ("ID_FILE");

That would be my prefered method. Makes it easier to associate strings with controls, menu items, etc. if they all have the same ID strings. Numbers just are not descriptive enough.

"You're obviously a superstar." - Christian Graus about me - 12 Feb '03 "Obviously ??? You're definitely a superstar!!!" - mYkel - 21 Jun '04 "There's not enough blatant self-congratulatory backslapping in the world today..." - HumblePie - 21 Jun '05 Within you lies the power for good - Use it!

PJ Arends

It will be slower, but we are talking about UI strings here. Most UI elements have very few strings so the impact will be the UI loading a few milliseconds slower. I doubt a user would ever notice the difference.

"You're obviously a superstar." - Christian Graus about me - 12 Feb '03 "Obviously ??? You're definitely a superstar!!!" - mYkel - 21 Jun '04 "There's not enough blatant self-congratulatory backslapping in the world today..." - HumblePie - 21 Jun '05 Within you lies the power for good - Use it!

Andre xxxxxxx

I don't think a user would notice if the creation of a window or dialog takes a tenth of a second longer. My problem is that i need the strings in a MFC project as well as in an embedded system (handheld controller) with very limited memory resources. With string tables in the resources i am bound to MFC. Also in most cases i have seen yet the string tables are missing more or less strings over the time because it is a hard task to keep them all up to date. So the options i see for me is either a sql database, XML file or some other kind of text file. In my eyes a table is less error prone because i have the columns for each language side by side and can easily find empty cells. I could even query for empty cells to find out if i have missed some.

Stephen Hewitt

If you want to generate a text file form the database (a .C file with the strings in it) perhaps XML would be a good choice, you could use XSL to do the conversion. I imagine by now with all the hype around XML there a plenty of good editors around. Steve

JonEngle

I've just gone through the same problem in a large application. We've had some problems with the strings that have had to be located in the database, namely maintenance issues (it can be a bit of a pain to add new or change existing strings). For a good 90% of the strings, we put them in XML files that are loading into hash tables at run time. I prefer this approach, but either/or are a *lot* easier than resources! Just one more piece of advise, make sure however you put the strings together that you can change the order of the parameters in the string itself. We had some developers putting in printf-style formatting, and that was a nightmare for the translators.