autoroute and localization

Topics: Localization
Jan 22, 2015 at 6:47 AM
Is there any manner to have an autoroute pattern that can be localized for a given culture?

For example, say the default culture is English and a content type has an autoroute pattern like:


What I'm looking for is a manner to specify a localized autoroute pattern that reflects the current culture (for use when translating). For example if the translated culture is 'ES-es' then I'd like the autoroute to use the pattern


So far I can't find a way to do this but maybe it exists and I can't find it?
Jan 22, 2015 at 7:12 PM
It occured to me I can enter alternative patterns, one for each culture. It will create numerous unused aliases but it will work (unless someone has an alternative solution)

It would however be a nice feature to have a pattern that can be generated based on the content-item's culture and have the url empty when opening a new translation. That would give a workflow of just

'new translation' -> translate title -> publish -> done

instead of

'new translation' -> translate title -> delete previous culture url -> publish -> done

and often :)

'new translation' -> translate title -> publish -> "Permalinks in conflict. "X" is already set for a previously created Page so now it has the slug "X-2" -> delete url -> publish
Jan 23, 2015 at 1:48 AM
And no that doesn't work. I was under the impression that having three patterns would create three aliases/routes to the same content-item. It appears it only generated a route to the default pattern. Suggestions?

End of the day I'd like an end user to be able to translate a page and have that translated page (with title) use a generated url that fits the culture.
Jan 29, 2015 at 11:19 PM
What branch are you using?

Is there not a token for the Autoroute part to do this? I would expect something like /{Content.Culture}/{Content.Slug} - if its not there, can you raise an issue and put the issue ID here., I will then look in to adding it for you.
Feb 7, 2015 at 6:45 PM
I'm on very close to tip.

Content.Culture is a different issue, although it is just as missing in terms of internationalization functionality as the autoroute. So I'll comment on both and divide the issues. If Orchard had both a Content.Culture token and a slightly modified autoroute implementation, it would fill a big gap in creating truly internationalized sites.

Content.Culture Token

There has never been a Content.Culture although there are some very old pull requests to add one. There is Site.Culture but that is the default language of the site, not the content being created.

Orchard still requires the user to manually prefix autoroute paths with the language culture string when creating new content-items. i.e. manually enter => "/es-ES/[some url]" which then of course wrecks the auto-creation of the autoroute from the title (slugified) or tokens. This creates a very error poor work flow and requires the autoroute to be editable (i.e. cannot make it uneditable for general users creating content).

Autoroute part culture-ization

The original design of the autoroute was intended to have a default selectable autoroute and the other entries are supposed to be selectable in the UI when creating a content item with an autoroute part. The code is there commented-out to do most of it minus the UI. While this design sort of works, it still requires the user to correctly select the autoroute that matches the culture of the content item being created and for 'general users' it would still be a poor workflow and be error prone.

What I would purpose is to extend the autoroute part with both a culture and a selectable default for each culture. So if I have a es-ES, fr-FR and en-US site, there can be (one or more) entries for each culture, with path strings that can be manually entered for that culture. Here "Culture" could be optional or just default to the site culture if not specified.

For example

Default Culture Pattern
  x            en-US     /{Content.Culture}/some-area/{Content.Slug}
                en-US    /{Content.Slug}

  x            es-ES     /{Content.Culture}/saber/{Content.Slug}
                es-ES     /{Content.Slug}

  x            es-ES     /{Content.Culture}/je-ne-sais-pas-français/{Content.Slug}
                es-ES     /{Content.Slug}
Then when a content item is created, the system selects the default autoroute matching the content's selected translation (culture) It should be possible to code this without breaking the existing autoroute since it would just fall back to the existing default entry.

On a side note, this implementation could cludge the lack of Content.Culture token temporarily, since the user could add the culture as a string. i.e.

Default Culture Pattern
  x            en-US     /en-US/some-area/{Content.Slug}
                en-US    /{Content.Slug}

  x            es-ES     /es-ES/saber/{Content.Slug}
                es-ES     /{Content.Slug}

  x            fr-FR     /fr-FR/je-ne-sais-pas-français/{Content.Slug}
                fr-FR     /{Content.Slug}
I'll open two issues and reference them back here and put the ID here as well.
Feb 7, 2015 at 7:02 PM
Feb 18, 2015 at 3:52 PM
Culture tokens are now in 1.x - Please give them a go - they are part of the 1.x branch
Mar 2, 2015 at 4:17 PM
Here is so far what I did this week-end with this Autoroute patterns localization feature.
The UI is working, I still need to make the default pattern for each culture to get applied.
Looking at how it was thinked at first ; I'm wondering if we should not provide a checkbox for autogenerating those patterns automatically all the time instead of making users select a single pattern. We could want to have multiple Alias for getting to a blog post article for SEO purposes for example.
And the not implemented code in this module is the part where the user should be able to select it's pattern from the content item edition/creation page wich to me seems a little complicated for most content editors. Though if it would be implemented I would just switch the default pattern to the selected one for navigation purposes. But then should/would we need to change it for each content item. That's a nice feature but would it be reliable performance wise to have that ?
Leave me your thoughts on this.

Mar 5, 2015 at 7:26 PM
Edited Mar 5, 2015 at 7:31 PM
The feature is done in here and only missing a migration path.
If you want I can demo it. I tested it against a fresh install from 1.x branch and also from an existing website using old patterns from 1.x branch. Both works. The only thing missing is providing a way to migrate old patterns into new ones. Maybe I could hard code it but I would prefer a migration procedure.