Enable the ContentObject provider to work with translated referrers

[dantleech]

Q	A
Bug fix?	no
New feature?	yes
BC breaks?	no
Deprecations?	no
Tests pass?	yes
Fixed tickets	#54
License	MIT
Doc PR

This PR is to make the ContentObjectProvider multilang aware. So that when a ContentObject provider is used in the chain, and a translated content object is persisted, the route provided by the ContentObject provider will correspond to locale of the persisted content object.

Note that this PR currently only introduces basic support, where by

1. Category has auto path `/en/category-1` and `/fr/categorie`
2. Persist article `ceci-est-une-article` with locale `fr`
3. New article will be `/fr/categorie/ceci-est-une-article`

However persisting an article in es would require persisting a new AutoRoute for category with the locale es, which I am not sure how best to do.

The default behavior when persisting a content which has a ContentObject provider providing an object not available in the locale of the content should be to take the fallback. This would result in an inaccurate prefix, e.g. /en/category/ceci-est-une-article-francais but well, voilà.

[dantleech]

Note that this does not support fallback yet, it should do before this PR is done.

[dbu]

for translated urls, i think there are 2 viable strategies:

• create the routes in all locales, from the first save on. when a content is translated, update the route of the additional language (would happen automatically i think, as updating things like the title will adjust the url and leave a redirect in the old place). the persist would be a special case now, as you create routes in all locales, while on update you only want to update the route of the current locale.
• only create routes in the current locale, even on persist. meaning as long as the content is not translated, you don't get a translated url. that only makes sense if the webside disabled language fallback for that content - otherwise we would generate urls that change the language of the website, which is worse than staying in the language but seeing a content of a different language.

ideally, we could support both, if not we should clearly explain which one we do, and maybe explain in the doc what the approach would be to do the other approach.

[dbu]

should this not go into a logfile, at a high level? an exception could break a running website, which is probably too much.

[dantleech]

I think it depends on if this would ever happen, and under what circumstances it would happen. It shouldn't happen I think, so I would prefer to bail rather than risk the website acting in unexpected ways.

[dbu]

okay

[dantleech]

Just to recap, the problem here is how to, when a content is persisted in a new locale, ensure that the content object is consistent with the new locale.

As @dbu says we could persist in all the locales each time, but I think this would be inflexible, I am not sure I understand his second point.

For me the optimum would be to explicitly reprocess the content object when the new locale is persisted. Note also that this is only necessary because a content object might have a dynamic "locale" element - e.g. en, fr in the component.

[dantleech]

Hmm. this is tricky. The easiest way to accomplish this would indeed to persist all the locales each time - this would just be modifying a line of code, at quite a cost to write performance.

But really, all of this is necessary simply so that if the Locale provider is used in a related content object, then it will show "/en/english-category/article-francais" instead of "/fr/english-category/article-francais". So I wonder if we shouldn't be just doing some kind of token replacement instead.

[dantleech]

ok. Had a good think about this. I think the best thing to do would simply be to remove the ContentObject provider.

If we take a use case of having a Blog document route in the route of a Post, then the user can simply implement a getBlogName method to construct the path "/fr/my-blog/posts/article-1" path, constructing the URL in full instead of retrieving the blog route and appending to that.

I think this is better. So remove ContentObject? @wouterj @dbu

[dbu]

i am not 100% sure to understand everything, but if we find a way to simplify things whitout making everybody having to write the same code all the time, it would be a good thing to remove unneeded things.

[dantleech]

Will be fixed by #72