spring localized message persistence

Question

I would ask if know some "standard" way how to persist messages, that are to be localized later. Note, that this includes also the message parameters. For example, I have message with code "msg1" and 1 parameter in resource bundle:

msg1 = Hello {0}

and I want to associate the message with an object, persist it. Than, later, different clients will ask the object with different language settings.

obj.setDisplayMsg(msgSource.getMessage("msg1", "World", locale))

I can imagine:

1. to store message as top-level object with message code and parameters. I am afraid of performance - having separate object in separate table seems to me much worse than single varchar column in case of simple error messages without translation.
2. to encode message code and its parameters in string representation and use some hibernate custom type mapping
3. But, isn't it already solved (preferably in spring) so I don't have to do it again?

Thanks

Update: currently, we do some half-way - we are storing message as Serialized message object in single column, within the mapped table. I'm still to fully satisfied - viewing data directly in database is not possible.

Answer 1

I don't think yours is a very common need, so there's probably nothing available out there. Pretty sure that nothing comes with Spring out of the box. So, option 3 is discarded.

The decision between 1 and 2 is mainly a business one. Imagine the message format changes after it is persisted (e.g. due to some mistake). What do you want to get now? Probably the corrected one, which can only be obtained with option 1.

On the other hand, if you want to save it as a proof of what the application said to the user, both 1 and 2 can be used (but in the first case, you'll need to save message format instead of its code).

In my opinion, the first option is the best. You wouldn't be so worried about its performance, because it's probably not a bottleneck in your application. Maybe a many to many (instead one to many) relation between a message and parameters can be good and can save you some memory, but it isn't is main purpose. In parameter table you can store some extra information, such as the kind of parameter. This way you can search easily, for example, all messages of type msg1 or messages where user Jakub is printed (because you stored that parameter as of the user kind).

Finally, never save serialized objects in your database. They are language dependent, you can't search for them, versioning problems can occur... and most importantly, at least in this case, you don't need it, since in the end all parameters must be transformed into strings.

Answer 2

The only use case to store i18n messages in database I see is when you'd like to have a UI in your application to edit them. Otherwise I see no point in complicating things and would advise using files instead.

First of all you should not ask the underlying storage (DB or file) every time you want to resolve a message. They change very rarely and are read very often, so it's a great use case for caching.

Next if you want message parameters to be localized, than simply keep them as separate messages in your storage and get the value of the parameter first and than pass it on when retrieveing the actual message.

So by now you're probably wondering how can I make my application see the changes I do to my messages? Well, just use a ReloadableResourceBundleMessageSource. It does caching for you too! But remember to put the files outside of the application archive (JAR, WAR, EAR, whatever)! It's a good practice to hold your configurations separated from code anyway. So yeah, ofcourse Spring has already sloved that!

But if for some reason you still want to use DB to store messages, you'll have to implement your own MessageSource. I'd store the parameters in the same table. And remember to use cache, and invalidate it when data in DB changes.

Answer 3

AFAIK Spring does not support storing i18n messages in the DB OOTB. However, you can create your own ResourceBundle that will fetch them from the DB.

There are many examples on the on how to achieve this: http://forum.springsource.org/showthread.php?15223-AbstractMessageSource-using-DB-table-instead-of-props-file

Database backed i18n for java web-app