Here's the scenario:
EPiServer CMS 7.16.1
I have a a multi-lingual site, with language-branches "en" and "sv-se".
Say that I have a page, in English, called "The page", with a URLSegment of "the-page" (so the URL is /en/the-page/).
When I choose to translate that page into Swedish, the page name, and URLSegment, are the same, giving it the URL /sv-se/the-page/. If I change the name to "Sidan", the URLSegment is still "the-page", since that doesn't change unless I explicitly clears the URLSegment property.
When translating pages in EPiServer CMS 6, the Page Name proeprty was left empty, and being required, forces the editor to write a name here, and thus generating a new URLSegment.
In CMS 7.5, the Name property briefly flashes (with the same name as the master language branch), before being hidden, and unless you have a property editor for it on your page (I don't, I have a "Heading" property that falls back to the Name property if left empty), is never changed.
I've tried googleing for this, but either I'm wording it wrong, or everyine else thinks this is an acceptable behavior. (Or, and this is highly unlikely, I'm doing something wrong)
I've never worked with EPiServer CMS 6, so i don't have much knowledge of how it worked then, but it never really occured to me that this is an issue.
I think the EPiServer CMS 7 way of doing things offers more flexibility, as forcing someone to change something should be up to the developers.
There's no link between the Name property and the URLSegment property except when you create a new page, as URLSegment is required and in CMS 7 the page is saved after you give it a name and a page type.
You could add a required property editor for the URLSegment and/or Name properties on the page using PageEditing.PageIsInEditMode to only show it for editors.
Or you could set the Name and/or URLSegment based on your Heading property.
Agree with Stephan that the "new" behavior is not optimal. It's very easy to forget to translate the name field. And even if you translate the name field, the urlsegment remains the same as the original language. Editors basically have to know that they must clear the urlsegment once they have renamed the page, to get the translated value in there.
Then again, if the more common case is that you don't actually translate the urlsegment but rather keep it same on all languages, then I can understand how it works. But for SEO reasons I hope that's not the case :-|
Perhaps it could be a behavior that we could configure - whether name/urlsegment is automatically copied or not.
@Vegard: Not sure I follow you. Do you mean we should add extra properties to handle this?
No, you don't need to add extra properties. Just expose the Name and/or URL segment properties in the "On page editing" area, and require them to be changed. Or set the URL segment programatically based on another property of your choice if you don't want to expose any of these directly.
I don't think it would be feasible to avoid copying the properties, as the page is saved instantly when adding a translation and the save would fail when required properties are empty.
@Vegard, when you say "require them to be changed", how would I go about doing that? Making them mandatory/required won't do that, since they will already have values?
If the save would fail, that would prompt the editor to change the name property, and thus, the URLSegment (as it is generated from the Name property), and this is exactly what I would want, and this is how EPiServer CMS 6 worked.
You could for example write a custom validator using the IValidate<T> interface that check that the URLSegment is not the same as for the master language branch.
Something like this could work.
public class BasePageValidator : IValidate<BasePage>
IEnumerable<ValidationError> IValidate<BasePage>.Validate(BasePage page)
ErrorMessage = "URLSegment needs to be translated",
PropertyName = page.GetPropertyName(pg => pg.URLSegment),
Severity = ValidationErrorSeverity.Error,
ValidationType = ValidationErrorType.Unspecified
private bool UrlSegmentIsSameAsMasterLanguageBranch(BasePage page)
var repo = ServiceLocator.Current.GetInstance<IContentRepository>();
var masterLanguagePage =
repo.GetLanguageBranches<BasePage>(page.ContentLink).FirstOrDefault(p => p.LanguageBranch == "en" && p.LanguageBranch != page.LanguageBranch);
return masterLanguagePage != null && masterLanguagePage.URLSegment == page.URLSegment;
EDIT: Added check to avoid invalidating all saves if you are editing on the 'en' language branch.
That solves a problem by adding another one, in that url segments cannot be the same between language versions. There is a distinct difference between being the same by default, and not being able to be the same at all.
I really appreciate that you've taken time out of your day to help out, but I feel this is an issue with the CMS, and not something easily solved with workarounds. I'm sure there are cases where your solution would be acceptable, but unfortunately, not in mine, since there will be several different versions of a page, all in English, but still in different language branches.
I've filed a support issue with EPiServer, and hopefully they can come up with something :)
It seems this issue was already reported a couple of days ago?
Hmmm... it's related but not entirely the same. I think it's good to have the two. Could link to this post too to get the full context!
I can see that forcing different URLSegments can be another problem, of course.
You could set the ValidationErrorSeverity to Warning or Information I guess? I must admit I'm not certain if this allows the page to be saved or not, but I expect it should.
Yes, it's pretty much the same.
Let's upvote it to the stars!
I'm surprised it hasn't been noticed earlier.
It has been noticed before. I just haven't bothered to register it ;-)
Isn't it funny that there are events in the IContentEvents interface, for when a ContentLanguage is deleting and deleted, but not when creating and created?