Hi,

I have the following classes (I extracted the relevant parts):

public class Text
{
...

@OneToMany(mappedBy = "text")
@MapKey(name = "locale")
@Cascade(value = CascadeType.ALL)
public Map<Locale, TextTranslation> getTranslations() {...}
}

public class TextTranslation
{
...

public Locale getLocale() {...}

@Type(type="text")
public String getTranslation() {...}

@ManyToOne
public Text getText() {...}
}

public SomeEntity
{
...

public Text getName() {...}

public Text getDescription() {...}
}


What I want is to store SomeEntity's name and description in different languages. SomeEntity may be an article for example which has several translations.
It works fine for simple cases but I have problems with HQL.

I would like to list the instances of SomeEntity with database performed ordering. For example:

SELECT name.translation,description.translation FROM SomeEntity e LEFT JOIN e.name.translations name LEFT JOIN e.description.translations description WHERE index(name)='en' AND index(description)='en' ORDERED BY name.translation, description.translation

This works (I think) but I have problem if some instances do not have the specified translation. In this case the given entity is not selected because in this case the WHERE condition is false. (For example no entity is selected which have only German translations. And no entity with NULL description is selected.)

What I would like is to write a HQL query which handles these problems: it selects some properties of SomeEntities in a specified language (like 'en' above) BUT
- if an entity does not have 'en' translation then it selects some given default translation
- the entity is selected even if some of its properties do not have value (it is null) OR for some reason it does not have default translation
I hope you understand my problem...



I would be happy if someone could provide the know-how of how I should handle these kinds of (complicated) multilanguage HQL problems. Even if it is completely different from my solution.


Best regards,
Norbi

Why do not you try propagating the localization problem to the slightly higher level and then use CustomResourceBundle. (http://java.sun.com/docs/books/tutorial ... ncept.html )
I mean that if you need localization then it is probably not limited to the translation of a particular field in a particular entity, it most likely requires locale specific labels etc.
http://java.sun.com/docs/books/tutorial ... klist.html


What I am trying to say is that the localization IMO should be more addressed on presentation layer more than at the level of entities.
Note, it does not preclude us from having all the entities related localization information in the database. We still can have translation information there and have it somehow constrained (FKs?).

What custom ResourceBundle buys us is the ability to leverage Java’s i18n related stuff. For one it will address the problem of mandatory translation: Java-s i18n always fall back to a default if there is no specific translation.

I did not mean to sound like RTFM, but sometimes we forget that Java core offers in the sea of 3rd party libraries and solutions.

PS: and custom ResourceBundle can use HQL to get the data, but it is going to be a very straightforward one with a naming convention in place.

Thanks for the reply.

My main problem is that I want to handle sorting by the database because of the lots of data. I don't see how your solution may handle this. Would you explain this?

BR,
Norbi