views:

115

answers:

1

I have a Hibernate model that (simplified) looks like this:

public class CoverageLine {
  private Long id;
  private String coverageText;
  private boolean coveragePresetTo = true;
  private OnNewPolicy onNewPolicy = OnNewPolicy.SHOW;
}

I need coverageText to be translatable (by the end-user) into arbitrarily many languages, but using the same ID, such that I can request a policy (to which the lines are added) in either English or German, and have the relevant version of the text returned by getCoverageText(). The other fields are not translatable in the database, they are translated using resource files, so multiple versions of the object in the DB isn't desirable.

My tentative plan is to make a JSON clob field, and store all the values in that ([{"lang":"en","value","...."}],[{"lang":"de" ...}]), set the language as a transient field, and manipulate the JSON using the get/set methods, but that doesn't really have the feel of a best practice. Alternatively, to have a second table with line-id, language and string, but that has the potential of inflating my data-model considerably for little more than having more SQL-y data.

Any suggestions?

+2  A: 

Sending all the choices down to the UI would not be my first choice.

One way would be to store the verbiage in a table. The Coverage table would have a language column foreign key to pick out which language you were dealing with. The value would be loaded into the object and you'd be done.

The downside is that a locale change would require a round trip to the server, database, and back.

Spring accomplishes this with locale-dependent views. Maybe you can try that as well.

duffymo