This project is read-only.

A many-to-many conundrum: The localized blog and/or the localized blogpost

Topics: Administration, Core, Francais (French), General, Localization, Nederlands (Dutch), Русский (Russian)
Nov 14, 2012 at 4:17 PM

I am sure many other multi-lingual site developers out there would agree that currently Orchard's achilles heel may well be localization.

Yes, the localization part cracks a few solid nuts and has allowed me to get as far as I've come, but there is still a lot to be desired in the intuitivity and ease with which a multi-lingual site can be set up.

1. The first one that keeps my head gently banging against the wall is that of localizing a blog and/or localizing blogposts. Localizing a blog has currently my prefence, this is primarily so that each language version of the blog can have it's own localized url with the slug neatly generated. But... what if I add the localization part to a blogpost instead, I can keep all the translations nicely linked together, the original text is there when creating a new translation, etc. etc. Another advantage of localizing the blogpost is that it is easy to set up blogpost queries based on culture.

** Possible solution: Content item (Blogpost) culture should default to it's container culture (Blog) unless overriden

2. The flat structure of the admin content listview does not group translations of the same content together. The method to find the correct translation is by looking at the "other translations" field and the missing culture will be the culture for that content item. Is fantastic brain-training on a site with 6 languages.

** Possible solutions: Hierarchy in the content list view (would be great to be able to specify a "group by" dimension: Culture, MasterContentItem, Slug, etc.), a filter by culture, an alphabetical filter (he he), a clearer indication of the content item's culture.

3. When localization is enabled a content item, e.g. a page, will not display it's body unless there is a translation of that content item. Perhaps this is because the culture can not be set on the master content item.

** Possible solutions: This has the smell of a bug :-)

4. When creating a new content item, it is created under the site default culture. Strictly from a user perspective, must the master content item be of the site default culture?

5. The admin follows the culture of the site. Good fun and has tought me what "submit" is in many languages, but maybe the admin should just stick to the site default culture. Though there may be people out there requiring the opposite... All the characteristics of a new setting.

6. Localization support of gallery modules. Not much we can possibly do here other than be vigilant before using a module. But it would be great if every module takes localization into account.

7. With widgets we can go in different directions. We could use the culture filter provided by a few modules or add localization to the widget itself. Either way, the same is true for widgets as for pages in moan #2 above. How to distinguish the widget for each language when editing?

** Possible solutions: I think it may be a good idea to pull the culture filter into the localization module, it's so core to achieving a multi-lingual site. In addition, the same as #2, the widgets listview could do with an option to filter by culture.

Kudos to Binary Analysis' Multi Lingual module for making my life a bit easier. Even though some of this module is redundant or even incompatible with Orchard v1.6.0, it contains several features unmissable for a mult-language site.

Of course, there is always the option of creating a tenant for each language. I've tried it, but soon came to regrest not having all content under one roof. Even with a country-specific domain, I prefer to rewrite the url over creating a tenant or a seperate site.

With regards to all the above, which is no more than a random rant, I am eager to create a fork with some of these suggestions implemented. This discussion, however, is to understand what other experience and possible solutions are out there.

As for the moaning rights; I am running a decent number of sites, now on Orchard v1.6.0, in a multi-node, load-balanced, multi-lingual, shared-session, shared-media, distributed-cached configuration. And it was not an easy ride (in fact, the ride goes on) but well worth it. The performance is great, setup time negligable. It's been a learning curve, but Orchard rules. 



Nov 17, 2012 at 2:57 AM


For 2. you might want to look at The Tree and extend that to show translations in a meaningful way.

3. file it

6. yeah, that would be great, but well.

7. what culture filter? Orchard provides ICultureSelector, but specific implementations are left to the module and site author, because there isn't one true implementation: some prefer to detect the browser's culture, some prefer to use the culture of the document, or to have a culture picker in the UI, or who knows what?