This is how I would do it
So some example of EPiServer language codes could be: uk-en, fr-en, ca-en, ca-fr, africa-en.
You could skip the iso language code for regions that never will have more than one language if you want.
1) Can't really say anything regarding the SEO. But language code on the html-element (if that's what you mean) should definitely be the actual language on the site (ex: en).
2) Take a look at the Replacement language and Fallback language features. And if that doesn't fit your needs, you can create a custom tool that copies a part of the page tree structure to a new language. I've created such tool for some projects. Whenever a new region/market/country/language should be created, we base it on one of the existing language branches.
3) Yes. But my personal opinion is that you shouldn't force the user to a specific language branch. It has happend that germans travel to UK (and actually want the german version) :-). It's also not unusual that large corporate networks have a single point to internet, meaning that employees all over the world could have a US public ip.
Hope this helps
Erik
Thank you for your response Eric, much appreciated and very helpful!
Cheers
Adam
...and if you have different domains for the different regions the language branch will not be part of the url.
...and of course I meant en-ca, fr-ca, en-africa etc. (lang-region) :-). You should stick to the regular iso-codes as much as possible. For the non-iso language branches you might need to set the Asp.Net culture yourself.
Regarding #2. If you use EPiServer Languages plugin, you can create a new language branch for a page by duplicating content from another language branch. This will not help when you update content, but will help you when the page is created.
You could also hook into published event and copy properties from one language to another. Or as you say, when the property is null, fetch it from another language. This shouldn't have that big performance impact since EPiServer caches GetPage etc.
I would probably have a discussion with the editors how they would want to work and then implement it in a small scale and test it.
Hi all,
We're just started a project that has some quite unique requirements around languages/regions that I'm looking for some advice on.
Their business has a concept of Regions which are the UK, France, Germany, Europe, Asia, Australia and New Zealand, Africa, Canada, Canada (in French) and the USA. Apart from Canada (in French) they will all be written in English. These regions don't all naturally link up to a language and language code.
I have a couple of questions around this in relation to how Google will understand the site:
1) If the French version of the site, indicated by /fr/ in the url, is still written in English is there anything from an SEO point of view we should be concerned with? Should we perhaps use /fr/ in the url but still set the language code as en-gb?
2) On some of their pages, most of the properties will be CultureSpecific. The only slight annoyance with this is that between en-gb and en-us 99% of the content on the page will remain the same, they might want to just change the meta title or meta description – on other pages they would need to translate all properties, hence most properties would still need to be marked as CultureSpecific. By default in EPiServer whenever you Translate a page you are prompted to re-enter all of the content in the CultureSpecific properties - is there a way of retrieving a property for a page and if it's null try getting it from the Master Language version, that doesn’t have a massive detrimental impact on performance?
3) If a user comes into the site from a result on Google which is from the German site, /de/, but they are in the UK how does EPiServer deal with this? As I understand it EPiServer will not redirect them to the German version of the page? The only way I can think of doing this is by using the Locations built into visitor groups, but that would mean checking the users location on every page?
Any help or guidance would be greatly appreciated.
Many thanks
Adam