Hi Guys,

Am building a sample i18n app and have opted for the two table approach.

Table <EnittyName> contains language neutral informaton and Table <EntityName>Details containts language specific information. There is 1 ..* relationship between the <EntityName> Table and the <EntityName>Details Table. The PK of the <EntityName> Table is the <EntityName>.id and the PK of the <EntityName>Details Table is a compound key that includes the <EntityName>.id and the <EntityName>Details.language attribute. So I now have a situation where I can support as many languages as I like for each <EntityName> but only have a single instance of each language

For Example:

Table Hotel { Id int (PK) Name nVarChar(255), StarRating int, CountryId int, (FK) CityId int, (FK) AreaId int (FK) }

Table HotelDetails { Id int, (PK) Language char(2), (PK) Summary nVarChar(1500), Description nText,
}

So my data might look like the following:

Table Hotel : 1 Row

id:1
Name: Hotel 1 StarRating 3 CountryId: 6 CityId: 14 AreaId: 6

Table HotelDetails : 2 Rows

Id: 1 Language: en Summary: Hotel 1 Summary Description: Hotel 1 Description

Id: 1 Language: fr Summary: Sommaire De l'Hôtel 1 Description: Description De l'Hôtel 1

So now I am trying to figure out how to use the data that is in my tables using the code generated by LLBLGENPro. And I'm a bit baffled about where to start. i.e How would I go about selecting a single hotel with all of the required language specific information?

Hope this isn't too dumb a question.

Cheers,

Peter (aka lad4bear)

My suggestion would be to have HotelDetails look like this. Then you can set your relationship between tables using the HotelId and use the relation to access a HotelDetail collection.

Table HotelDetails { Id int, (PK) HotelId int, Language char(2), Summary nVarChar(1500), Description nText, }

Hi there,

Thanks for wading through my original posting - it was a bit long!

However, I'm not sure I understand your reponse. If I was to create a HotelEntity the HotelEntity.HotelDetails property will return a HotelDetailsEntity Collection which contains all rows that match the HotelEntity.id property. What I actually want to do is return only the HotelDetailsEntities where the HotelId matches and where the language equals the selected language.

Is it possible to apply a filter / predicate / somthing else to the HotelDetailsEntity collection so I can return the single row from the HotelDetails table I am interested in?

Again, thanks for your help.

Peter (aka lad4bear)

lad4bear wrote:

Is it possible to apply a filter / predicate / somthing else to the HotelDetailsEntity collection so I can return the single row from the HotelDetails table I am interested in?

This sounds like a basic multi-entity query to me. Did you read that section of the help?

BOb

Thanks - I got something to work

Although I got something that works it seems a little awkward. I know you guys are already working extra hard on version 2.0 (something I'm very excited about) but are there plans with LLBLGENPro v 2.0 to provide support for databases that require i18n?

I guess in the general sense it would require the ability to 'flatten' a two table relationship into a single entity based on a discriminating field(s) in the * side of the relationship. In this case languageCode. Because in reality a single Product entity actually spans two tables (Hotel and HotelDetails).

I would appreciate your feedback on whether this is something we can see in the future.

And I'd also be interested to hear how other developers have used LLBLGENPRO to work with databases that require i18n.

Cheers, Pete

THere aren't plans to support in general n-table entities without inheritance. (only through inheritance).

This because we've seen multiple ways of doing this in the last couple of years, so which technique we'll pick might not match what some people want (and thus mitigate the usage of it).

The problem is that some choose to store all translations in one table, defining subtypes on that table, while others want to merge 2 or more tables over a relation (m:1).

Hi Otis,

Thanks for the feedback. Am happy to use inheritence to deal with this. Haven't used this inheritance feature yet so will have to hit the help files. Could you give any pointers i.e TargetPerEntityHierarchy vs SomeOtherOption ?

Cheers, Pete

lad4bear wrote:

Hi Otis,

Thanks for the feedback. Am happy to use inheritence to deal with this. Haven't used this inheritance feature yet so will have to hit the help files. Could you give any pointers i.e TargetPerEntityHierarchy vs SomeOtherOption ? Cheers, Pete

It will take more than that I'm afraid. Inheritance can be used to map an entity onto multiple 1:1 related tables, through inheritance, (every 1:1 related table is a subtype of the PK side) so not what you need.

Sometimes the following is done: store all translations into one table, and use the language type field as a discriminator column and define subtypes for each language in the llblgen pro designer. You can then fetch all english translations by simply doing an entity collection fetch for the english subtype.

Though I'm not sure if this fits your requirements.

Hi Otis,

Does this mean I would I have to explicitly create a sub-type for each supported language (for each i18n entity) in the designer?

Cheers,

Pete

lad4bear wrote:

Hi Otis,

Does this mean I would I have to explicitly create a sub-type for each supported language (for each i18n entity) in the designer?

Yes. Though I don't know if it's worth the effort, as you always will keep the has-a relationship: the translated description field will never become a part of the entity which is containing the description field which is translated.

What are the current recommendations for providing g11n/i18n/l10n in the persistence layer ? Has the advent of new technologies like LINQ changed the game "i18n in databases" ?

I would very much appreciate a step-by-step instruction guide which tells LLBLGen Pro users how to provide i18n in their back-ends. It should be a topic which is important enough to justify spending some time on it; so that not everybody facing the problem "i18n in databases" has to reinvent this i18n-wheel ...

IMHO, there is no fixed standard for Internationalization.

I would very much appreciate a step-by-step instruction guide which tells LLBLGen Pro users how to provide i18n in their back-ends.

You came to the right thread, please check Pete's (lad4bear) example above