Multi-Language-Multi-Site: Subdomains for countries, multi-language content management

[masslevel]

Hello PW community,

 

I hope my post fits correctly in this forum category.

 

Great to be here. Great to have found my new favorite CMS and an awesome community! I learned a lot from you guys by lurking on the forums and I hope can help someone else in the near future. I could need some advice about a very specific subdomain setup with a single PW install.

 

A multi-language multi-site setup

• 1x top-level domain but with subdomains for country specific site versions
• Some subdomains have the same language (different country), others differ
  
  
  Current setup using apeisa's Multisite module

  In Page Tree        Domain           Country              Language
  /                   www.domain.com   International site   english
  /en.domain.com/     en.domain.com    United Kingdom       english
  /de.domain.com/     de.domain.com    Germany              german
  /at.domain.com/     at.domain.com    Austria              german
  /ch.domain.com/     ch.domain.com    Switzerland          german
  /fr.domain.com/     fr.domain.com    France               french
  ...

I guess the name for something like that is "Geo-Targeted Subdomain Approach". I first wanted to do a folder-based language approach but the requirements have changed - thanks to the SEO guys *yay* :-/.

 

In advance

Since the project must be finished during the next few weeks, if anyone of you PW professionals is available short term, I would be interested in talking to you to find a solid solution to make this work.

 

The site's content will grow soon and I'm concerned how the client will be able to manage all of his different country sites (subdomains).

For example my current challenges are with managing lots of content in this environment, PageListSelect, sitemap.xml generation and more. The site is working but things are starting to get complicated and some functionality undesirable. I guess mostly of how the subdomains are set up with the Multiside Module. 

 

My question

I don't know how I can efficiently marry the multi-language features of PW and this multi-site setup with subdomains. Also there may be other solutions for the subdomain setup beside the Multiside module.

 

If any of you has an idea, did something similar or could give me some pointers in how you would approach a setup like this - that would be so awesome!

 

The Challenge and options in how to prevent a content management Massacre

• Managing multi-language content in a multi-site environment, preferable with single pages and not duplicate content
• Can it be done with LanguageSupportPageNames of PW 2.3.1/2.3.2 dev branch? I'm still not sure If I should be using the dev branch for a live production site.

Current setup

I have already set this up and it's working fine using apeisa's Multisite module - which was a real life saver, since the site had to go live very quickly in a light/base version.

 

The site content

• Company with a single product and pages like support (can be many pages), faq, forms etc in each country
• All countries (subdomains) describe the same content, but text and images can be different on subdomains in a different or same language
• All subdomains/sites have many pages in common but not every page does exist in every country.

• Most content is currently duplicated on all domains and this creates a mess as the site grows obviously.
• Have not found an efficient solution for a multi-site/multi-language page/field setup
• No PW language support is currently in use
• I already thought a lot about how to reduce complexity of my setup, created some working snippets but encountered some problems.
• Was thinking about letting the content live somewhere hidden on the site, creating my own function or by using something like this and pulling everything in with a nice and easy configuration (field to select a country etc..), which with my PHP/PW knowledge sounds insane to be build by myself.

 

I have more information, but I didn't want to spam this post - hrm *cough*, as I've done already.

 

Phew, sorry for the long post. Any feedback is much appreciated.

 

Thank you so much in advance and thanks for reading this.

 

Regards

//symb

[ryan]

It sounds like this is more multi-language/similar-site, rather than actual multi-site. You mentioned all the domains describe the same content (for the most part) so I would probably take the "multi-site" out of your thinking about it, because it's only multi-site so far as it is multi-language. I'd use the dev branch, purely because it's going to take you a lot farther on the multi-language side. It should be plenty stable, but you'll just have to use extra care when updating (i.e. test things out on your own before upgrading a live server). 

If you could, I would try to do this all on 1 domain rather than split among multiple domains, but I'll assume that's not an option. But it'll be workable either way. If using multiple domains (or subdomains), you'll only need to install the LanguageSupportPageNames module if you want to have the same pages use language-specific names. I'm guessing you'll want that. However, you'll want to set the $user->language yourself, based on the domain/subdomain, rather than any other factor. You can do that with code like this at the top of a common include/file for all site template files: 

// grab the subdomain, i.e. "en", "de", "at", etc.
list($languageName) = explode('.', $config->httpHost); 
// sanitize it just for good measure
$languageName = $sanitizer->pageName($languageName); 
$language = null;
// attempt to find a language with the same name
if($languageName) $language = $languages->get($languageName); 
// if no language matches, then we'll assume 'default' language.
if(!$language || !$language->id) $language = $languages->get('default'); 
// set the language to the user
$user->language = $language; 

The above is essentially serving as your "multi-site" code, forcing the language to match the subdomain. You'd want to remove any other multi-site solutions.

You'd want to use multi-language text fields where possible. When using multi-language textarea fields where you need rich-text editing, I suggest installing the InputfieldCKEditor module and using it in inline mode. This scales much better for multi-language environments than TinyMCE. For situations where you need different images per language, you can use the tags feature to devise your own matching method (perhaps using the language name as the tag), or you can use language alternate fields. 

For situations where you have a page available in one language and not another (or some and not others) then you can simply make them active or inactive from the checkboxes on each page's "settings" tab. 

To summarize, I would treat this site purely as a multi-language site, and would probably develop it without considering the multiple domains/subdomains. Then when it comes time to launch, point all those domains at the same site, but use the $config->httpHost trick above to set the language based on the subdomain its being accessed from. 

[masslevel]

Wow! Thanks, Ryan. Very much appreciated. Exactly the feedback I was looking for - another approach. I will try this out right now and give feedback.

[stefant]

@ryan I am working on a similar setup currently as the OP in 2013.

I'd like to try out the recommendation you gave to masslevel, but I am wondering how to override the generation of internal links to processwire pages.

Obvious example:  $page->httpUrl (here we need to get the correct host, but I guess we will always get the current host - because pw can't know which one would be the correct one)

Not so obvious example: $page->path (in case you're visiting a page on subdomain "de.domain.tld/ueber-uns" and using a language switcher - we need to reference another translation of this page then, that is "living" at another subdomain, e.g. "en.domain.tld/about-us")

Am I missing something? Do you or does someone else have a hint how this might be solved?

I already cloned the LanguageSupportPageNames.module in order to override the according functions, so they generate links with the correct host now. In general, this works. But internal page links in contents, e.g. in WYSIWYG (CKEditor) fields, are still the original ones. Any clue?