Taxonomies (and generally containers) proper localization support

[orchardbot]

@Piedone created: https://orchard.codeplex.com/workitem/21239

Currently if you want to localize Taxonomies content (terms and taxonomies) it's not really supported:

If you add LocalizationPart to a taxonomy you'll be able maintain localized taxonomies, that's OK-ish.

However localizing terms won't just work: adding LocalizationPart to a term content type will allow you to create localized versions that are orphaned. Since the relationships between terms and their decorated content items are stored in records this won't be automatically added for localized versions.

I'd suggest to add the ability to completely mirror a taxonomy in multiple languages: the terms of two localized taxonomy counterparts would automatically maintain all their connections. I.e. when you translate a term its translation gets added to the translated taxonomy counterpart and all the term's connections are replicated.

Partially this is also a question about localizing container relationships (since terms and their parent terms or parent taxonomies are containers-containables). Furthermore we have a similar issue with menus.

The idea is to create a feature in Taxonomies that is Orchard.Localization-aware (or vice versa). I'm thinking about building necessary extension points into Taxonomies so the various queries and such can be modified on the fly; then by hooking into those extension points create a new feature that will load/display only terms for the item's culture and maintain relationships between terms and items (these connections are stored in records and are 1-1 connections; it would be a new feature to automatically maintain such connections for each localized version of a term).

[orchardbot]

@Piedone commented:

I'm not even sure whether it's feasible to implement support like this for Taxonomies, Blogs (it's the same with the Blog Posts-Blogs relationship), general containers and menus (maybe others as well, but those are that come to my mind).

Maybe it's not just easier but also better to just create and maintain completely separate taxonomies, menus, etc. (but all set for a specific culture for structuring), even separate widgets for them on culture-specific layers.

For a better UX maybe we could only display the editor of that Taxonomy Field when editing a content item whose Taxonomy has the same culture...

[orchardbot]

@sfmskywalker commented:

Or maybe the LocalizationPart isn't the real way to go; what if each part and field had the ability to store their data for a given culture? UI-wise the content editor could render a list of cultures to switch between. This would also solve the scenario where you have a content item where some fields you don't want localized (the SKU and Price of a product, or the vibration frequency of a vibrator for example).

A downside may be the way content part authors need to implement localized properties - they would essentially have to be getter and setter methods, accepting a culture code. Come to think of it, this may actually be a deal breaker.

Anyway, regarding the issue where a Term type has a LocalizedPart and the user creates a translation, I think the TermPartHandler could handle this be handling its Created event, and check if the newly created term has a parent Taxonomy. If not, then it will suspect it is a localized term, and check for the LocalizedPart to confirm this. Then it will know how to get the default translation and its taxonomy, and assign that to the newly created term. If parent-child relationships are implemented through ICommonAspect (or just CommonPart), then this could be handled more generically for all types using that method.

[orchardbot]

@Piedone commented:

You're getting creative with your issue-related texts Sipke :-).

I see the point but I'd rather go the opposite way: instead of making parts and fields care about storing localized versions in the same item I'd keep how LocalizationPart works but also offer an optional way to synchronize a selected set of data between localized versions.

It really depends on the use-case (to an extent of the content of that individual content item: think about images containing text that should be localized) so I think this is the was that keeps most options open (e.g. such "structural" data like container ID might be the same across localized items most of the time, but still not always: what if the structure in one culture is different?). Not to mention in the simple case developers don't need to build support for it.

[orchardbot]

pdacode commented:

I worked Drupal for a while and was able to deliver a multilanguage site without any hack!!! Although you had to make translation related changes in many places through the ui. Even projections data (Drupal Views) can be language ignored or filtered based on current cilture.

Orchard has the most powerful language behind c# (+the power of razor), one of the best ORMs, the most powerful DB (SQL).

We don't you make re-engineer a clean Business Layer + Data Layer design about supporting Content Type, Content Part, Taxonomy. Term, Menu translation?

We you keep looking for a solution with hacks and not redesign orchard translation capabilities from scratch?

I18n is a major issue for a CMS and orchard is away behind !!!

[orchardbot]

@Piedone commented:

So what would be your suggestion pdacode?

[orchardbot]

@sebastienros commented:

Let's look at what solution Drupal is using

colors (description) blue / light blue

couleur (description) bleue/ bleu ciel

Sky Content Item -> blue, red, redish

Ciel Content Item -> bleu, rouge

[orchardbot]

urbanit commented:

Drupal - 1/3

[orchardbot]

urbanit commented:

Drupal 2/3

[orchardbot]

urbanit commented:

Drupal 3/3

[orchardbot]

urbanit commented:

The logic behind, I far as I understand

Create a taxonomy (original) --> add localised versions Add term (to original taxonomy) --> add localised versions

[orchardbot]

@Piedone commented:

See Drupal's solution: https://www.drupal.org/node/1114016

[orchardbot]

pdacode commented:

Every aspect in Drupal is translatable

Content Type Taxonomy and Taxonomy Terms Menus Plain Resources

In content types the language can be neutral or specific.

Views (projections) make queries on data and retrieve all languages unless you explicit say as filter Language=Current Users language

The Translation internal options vary from item to item. In Drupal 7 they say that with the Entity Translation there is only one Base Node with an ID and all translated nodes link to this base Node ID. In other words there are no different nodes with different ids for supporting translation.

In menus i found that is working a little different. You have Budles!!! That is different menu items with different caption that are belonging to the same translation bundle (aka they represent the same menu item).

The drupal community delivered a product that really supports translation but i think because of compatibility issues with older versions they not delivered a uniform way to handle translations.

That is why i suggest the orchard team to make a design from scratch about how every aspect of orchard can be translatable in terms of selecting the best database design (different translation table? different columns on each table? complex iiner joins?) and deliver a uniform API for making LinQ queries with culture
support.

i attach some screen shots from drupal

http://screencast.com/t/qoUUIsa6d

http://screencast.com/t/Ro6FNlYQ

http://screencast.com/t/lyJsyGfysoy2

[orchardbot]

@Piedone commented:

Maybe a solution would be to to have localized versions of a content item similarly like versions: it's the same content item, under the same ID but a different snapshot... This would be probably something you mentioned pdacode.

So imagine that similarly how you retrieve a specific version of a content item you could retrieve a specific locale of it: Same numerical ID, same ContentItemRecord but a different "ContentItemVersionRecord"... Maybe we could actually build on versions?

[orchardbot]

@Piedone commented:

Duplicate: https://orchard.codeplex.com/workitem/21261

[orchardbot]

@jetski5822 commented:

See: https://orchard.codeplex.com/workitem/20428

[orchardbot]

@jersiovic commented:

I think we should divide the problem in two: On the one hand the fact that now we cannot use localization for Taxonomies. This is a critical issue in my opinion. On the other hand, to find a localization mechanism that allow us to set which parts and fields are localizable or not. This one is something to mature and not as critical as the first one.

Solution for the first problem could be started without wait for anything else don't you think? Doesn't looks feasible and reasonable what Sipke proposed?: "Anyway, regarding the issue where a Term type has a LocalizedPart and the user creates a translation, I think the TermPartHandler could handle this be handling its Created event, and check if the newly created term has a parent Taxonomy. If not, then it will suspect it is a localized term, and check for the LocalizedPart to confirm this. Then it will know how to get the default translation and its taxonomy, and assign that to the newly created term. If parent-child relationships are implemented through ICommonAspect (or just CommonPart), then this could be handled more generically for all types using that method."

Solution for the second problem don't you think can be discussed in another issue to don't delay solution to the first problem? In fact if taxonomies localization is done following Sipke solution. The solution to apply for second problem will be the same for taxonomies and for any other Orchard module because localization for taxonomies would have been similar to what it has in other Orchard modules.

[orchardbot]

@jersiovic commented:

Related with Localization is this problem https://orchard.codeplex.com/discussions/589083 which happens because taxonomy uses as internal name the TitlePart, this is also something critical to fix.

[orchardbot]

@Piedone commented:

We'll implement automatic synchronization for container relationships (i.e. ICommonPart) and the same specifically for Taxonomies. Stay tuned, will demonstrate something in a few weeks.

[orchardbot]

@jersiovic commented:

Great to hear it!

[thekaveman]

This is related to #4257

[Piedone]

Here's a possible solution, demoed on today's Community Meeting: https://github.com/urbanit/Orchard-Localization-Extensions

[ramiassi]

It is one year till now and the problem is still standing.

[BenedekFarkas]

This will be covered soon as discussed in #7352.

[MatteoPiovanelli-Laser]

We at laser actually have something working. I'll have it next week at the meet in NY.