Should I store localization data for desktop application in database?

1
votes

At my office we were discussing what will be the best way of handling localization of our desktop applications.

While using resource files seemed as an obvious choice, we got an idea that we could use database for centralized localization management. Application would connect to database on start to download all required translations or it could download translations on demand as the controls are rendered.

Applications (created using C#) are deployed in highly controlled environment for internal use with help of tools that handle publication itself as well as live updates. We have a single file distribution repository and single database server to handle few satellite sites.

Would database be a viable solution for handling user interface translations in desktop application?

2
c#databaselocalizationresources
Sounds ok, but it's not the best way for everybody. It may be the best in your scenario (consider everything first). The question is why resource are bad for you? Why database? To be able quickly share updates of localizations? How often this is expected to happens? Are benefits worth drawbacks? Only you can answer those and other questions. Currently question is either too broad (if we would attempt to consider everything) or opinion based (as everyone may think about his scenario). - Sinatr
@Sinatr Well, the instigator's idea behind using database to store translations is to allow us to "centrally manage localization" to re-use translations between applications. This of course leads to issues that resource files are free of - it's network-dependent and significantly slower. I was wondering if there is a way of mitigating database drawbacks and still be able to benefit from pointed upsides. - Sebastian Kliś
You can construct own localization. I am using txt-files which are loaded on application startup and used to update static class properties via reflection. Then all you need is a simple mechanism to obtain version and to download complete translations (if version is newer than client already has). Database should do. - Sinatr

2 Answers

1
votes

There are a few points you should consider

  • Application is expected to grow significantly
  • Application might require to have special cases (client specific translations)
  • The same translation_key has a different value on different screens / windows / in different context
  • Manual management in local files is time consuming and not easy / out of the box to handle

If one ore more points from the above match the business plans for the application(s) then you should consider using a Database and a server cache

Let's suppose you start adding a new screen (form) to the Application. In this form you have 3 UI elements (element1, element2 and element3). There should be a centralized localization service (business object) which does the following

  • Read every form
  • Read every element in the form (here you might filter the relevant elements which might contain multilingual text like labels, buttons etc, and exclude panels)
  • Is the application in customer mode ? (suppose your app will have at startup / login a selection for customer - different look and feel, different texts etc)
  • Try get the translation Key from the server built cache (a dictionary based data structure containing applicationCode(or key), customerKey, translationKey and value). The translation key can be the formName.uiElementName
  • If the key is not found in the cache, try getting it from the database
  • If not found in Database (the newly added form and with its UI elements), then try adding an new entry in DB (applicationKey, customerKey, translationKey, empty value)
  • If found in Database then add the entry in the cache
  • You might want to have an Admin menu to clear that cache

Now build a centralized application to manage the localization database. Manage the texts here and you can leverage its usage for the current running apps but also future apps.

0
votes

It is extremely important to have a centralized localization service, but building a centralized application to manage the localization database can be a serious undertaking (time and money). If you are looking for a quick, easy solution and don’t mind a commercial product you could explore Passport. It provides the user management features you need (like localization) as well as other features you probably need, but don't have the time to write. These usually include:

  • Login tracking
  • Reporting (active users, registration and login reports)
  • Emailing users
  • Role based permissions
  • Single sign-on via OAuth
  • And a bunch more

It is simple to install and can successfully handle user interface translations in a desktop application. If you do anticipate significant growth and client specific translations Passport can scale with you.