Comments on: Multilingual data and NHibernate

By: Egor Pavlikhin

Egor Pavlikhin — Thu, 28 Apr 2011 12:07:00 +0000

Great solution! Your approach is something I used to do in the past. However, it’s not particular friendly if you don’t know beforehand which culture is going to be required. I’ve written a different solution which automatically deals with mappings, is attachable to pretty much any entity and creates rows for new cultures when appropriate: http://httputility.com/articles/internationalization-with-nhibernate-best-practice.html

By: Tambet Matiisen

Tambet Matiisen — Wed, 23 Dec 2009 18:18:03 +0000

I would rename these tables to Phrases and Translations. This makes many-to-one relationship between domain table ja Phrases table natural – Product Name is a Phrase and a Phrase can have many Translations.

But if you don’t share the translations for domain objects, then Phrases table becomes useless. It’s only there because of NHibernate. For example deleting your domain object wouldn’t cascade delete it’s translations. (Or it does in NHibernate? It certainly doesn’t at database level.)

By: Davy Brion

Davy Brion — Mon, 14 Dec 2009 11:12:20 +0000

@Geert

it’s a trade-off obviously, if you have a lot of translatable entities and a high number of concurrent edits then yeah, a single table probably won’t be the best option… a translation table per entity would avoid that problem but introduces more work. But if it’s necessary, then that is probably the better way to go in your scenario

By: Geert V

Geert V — Mon, 14 Dec 2009 10:51:18 +0000

Hi Davy,

My current project uses NHibernate and since it is my first big project, I run against a lot of questions including the multilanguage aspect.
I started with an approach similar to yours but after sitting together with a DB guy, he informed me that the single translation table might be a bad idea for scalability. Because all updates/inserts of new items that have translations lock that single table.

Currently I’m using a translation table per entity to avoid this.
What is your idea on performance?

Greets,

Geert

By: Border Crossing Stats » Multilingual data and NHibernate Davy Brion’s Blog

Tue, 11 Mar 2008 08:08:40 +0000

[...] Find more about it all here [...]

By: Peter

Peter — Sat, 02 Feb 2008 06:05:17 +0000

Thought you might be interested in this approach by way of comparison: http://www.nablasoft.com/Alkampfer/?p=41

I think the best that can be achieved using NHibernate is somewhere in the middle. A single EntityText table, with an EntityResource mapping table from the Entity tables. I don’t see a way around having to delegate to the resource bag from the property accessors.

By: Davy Brion

Davy Brion — Thu, 31 Jan 2008 07:36:58 +0000

You could use NHibernate’s Criteria API for that… i don’t have the above solution with me so i can’t experiment with it, but you can definitely do what you said in an efficient way using Criterias. Or you could use HQL… I’d basically try a few different ways, see what SQL gets generated every time and then i’d pick the most efficient one.

By: Duc H Tran

Duc H Tran — Wed, 30 Jan 2008 15:04:16 +0000

Nice approach, but how about searching on individual localized property? Said, for example, we have Product class with Name and Description localized, any idea of an efficient way when we wanted to search for products that have a specified term in Name or Description (but not both).

By: Davy Brion

Davy Brion — Mon, 28 Jan 2008 09:47:17 +0000

I haven’t used this approach in production, but it is based on some multi-lingual requirements at a previous client. On each screen where multilingual strings could be edited, they wanted to be able to edit each translation at the same time. So that’s the justification for loading all the translations into the domain object. In my POC the Translation class’ ToString() method was overridden to display the translation for the user’s current locale though to make it easy to work with for display purposes.

I also tried to get it working without a mapping table but could not find a solution that worked… the mapping table just made it really easy to use standard nhibernate approaches, and from a data integrity point of view, i think it’s probably the most ‘correct’ approach.

Looking back on my post now, i would rename my original ‘Translation’ class to MultiLingualString and have it hold a collection of Translation objects (which would be the ‘TranslationValue’ instances as they are called in the post).

By: Peter

Peter — Sun, 27 Jan 2008 20:40:09 +0000

Good post, but wouldn’t it be preferable to have the translation part invisible to the domain layer? Product.Name should just be a string, loaded from a separate table depending on the requested locale. Why load all the translations into the domain object? It’s unlikely that any one request is going to need or use those other locales at the entity level (rather, language choice is a change at the user or application level). I’m guessing this is needed to workaround the cache in the ORM — Product1(fr-FR) having the same identity as Product1(en-US). Is that the justification?

I, too, have implemented a single Text table with textid/iso as the key, but without the mapping table. In my case, we made the unique key by concatenation: type/id/property, and references it from the entity table. I’m puzzling through how to replicate this using NHibernate. Have you had a chance to use this in production? Is so, any thoughts on the implementation?

By: Davy Brion

Davy Brion — Sun, 09 Dec 2007 15:40:59 +0000

yeah, setting the ‘cascade’ attribute to ‘all’ in Product’s many-to-one mapping to Translation should do the trick

By: Hassan

Hassan — Sat, 08 Dec 2007 22:16:26 +0000

Hi,
Nice Idea, I am wondering if you can do this without calling “session.Save(product.Name);”, is it possible to make mapping handle calling save for translation objects automatically?

Thanks

By: Davy Brion

Davy Brion — Tue, 23 Oct 2007 06:26:09 +0000

well, the easiest solution that comes to mind is to provide a CurrentLanguage property setter on your Translation class, and a TranslatedValueInCurrentLanguage (or a shorter name ) property getter. The TranslatedValueInCurrentLanguage would simply return the specific translation based on what you set the CurrentLanguage property to. You can then simply use DynamicComparer and use “TranslatedValueInCurrentLanguage” as the sort expression.

I haven’t tried this out yet, but it should work

By: Bergius

Bergius — Mon, 22 Oct 2007 16:22:20 +0000

Any ideas regarding how to get a sorted collection of your products based on a specific translation of the names? I really don’t enjoy i18n…

By: Davy Brion

Davy Brion — Sun, 21 Oct 2007 15:47:06 +0000

i haven’t really thought about using a one-to-one for it to be honest, i just always use many-to-ones to map foreign keys. Technically, it does make it possible to share the same translation in multiple places although i don’t really make sure that they are indeed shared instead of duplicated. That would definitely be an interesting approach though.

By: bryan

bryan — Thu, 18 Oct 2007 14:55:16 +0000

why the relationship: “many-to-one from your domain table to your translation table” and not a one-to-one? is this only so that records may share the same translation or is there something else i’m missing?

By: Davy Brion

Davy Brion — Mon, 30 Jul 2007 13:08:41 +0000

in your situation i’d simply replace the TranslationID with a TranslationGUID column but keep everything else the same. The most important part is being able to define a many-to-one from your domain table to your translation table, and a one-to-many from the translation identifier (be it a numeric id or a GUID) to its values.

I tried a couple of different approaches, but the Translations-TranslationValues table combination was by far the easiest one and the cleanest one to get working properly. So i’d definitely keep those 2 tables around.

By: Simon Jones

Simon Jones — Mon, 30 Jul 2007 12:48:49 +0000

Thanks! Some time ago I was looking for a good approach for multilingual NHibernate data but the project was put on hold. I’ve now come back to this and your approach is the best I’ve seen.

However, I don’t have the luxury of being able to change the schema of my domain tables (changing nvarchars to int pointers). Since each of my domain tables uses a GUID as the PK, I’m thinking I can probably avoid the need for the TranslationID column.

CREATE TABLE translations
(
objectid uniqueidentifier NOT NULL PRIMARY KEY,
property nvarchar(100) NOT NULL
);

Just wondered if you have any thoughts on this before I embark on a POC?

By: Davy Brion

Davy Brion — Fri, 29 Jun 2007 08:22:15 +0000

Yup, definitely a valid question… I’d certainly avoid doing it in the default constructor because that’s the one NHibernate uses to create the persistent instances as well. So for every product you’d load from the database a new Translation object would be instantiated, only to have it overwritten with the instance that NHibernate retrieves from the database moments later. Obviously, the performance penalty of this is minimal but i always prefer to avoid unnecessary object instantiation.

The coolest solution would be if your inversion of control container would simply inject a new translation object through setter dependency injection. That way, objects that are instantiated by NHibernate don’t unnecessarily create new translation instances and the developer wouldn’t have to worry about creating the translation instance either. And it would also be completely configurable without touching code.

By: den ben

den ben — Fri, 29 Jun 2007 07:44:42 +0000

Pretty nice implementation! Good data model too. The key difference in (uhum..) most data model implementations I have had to work with in the past is the fact that there _is_ a table ‘translations’ (I would ommit the s at the end of the name though). Most people, even the ‘Most Valuable ™’ ones tend to forget there is such a thing and just use a duplicate key in the translationvalue table with languageid and some TRanslationID out of the blue.

Your code would be even better if you didn’t have to instantiate product.Name yourself. I assume a product always has a name…

This just leaves the question of who/what is responsible for instantiating this product.Name. EntityFactory?, Product Constructor?, …