Forum
Multi-language site questions
I like the idea of using the branching technique for a multi-language website.
Pages
The branching method makes sense when using pages.
- en
- page-1
- sub-page-1
- sub-page-2
- page-2
- page-3
- page-1
- de
- page-1
- sub-page-1
- sub-page-2
- page-2
- page-3
- page-1
- es
- page-1
- sub-page-1
- sub-page-2
- page-2
- page-3
- page-1
- fr
- page-1
- sub-page-1
- sub-page-2
- page-2
- page-3
- page-1
I can see this being easy to manage as the number of pages grows.
Blog and Collections
What's the best way of handling multiple languages for collections and blog?
- I'm thinking for
blogI'd use the multiple blog feature, a different blog per language - For
collectionsI guess I'd take the same approach. I'd create a different collection per language.
Is this the recommended way to handle multiple languages?
Categories
For any content that needs categories, (I'm thinking blog and collections) I'd create a set of categories in English, then duplicate them in different languages. Is that right?
Templates
My template folder structure would look like this:
templates
- blog
- en
- de
- es
- fr
- categories
- en
- de
- es
- fr
- content
- en
- de
- es
- fr
- layout
- en
- de
- es
- fr
- pages
- en
- de
- es
- fr
Is considered the best way to structure a multi-language site?
- blog
Hi, Drew/Rachel
Does this structure make sense?
Any Gotchas I need to be aware of when developing a multi-language website?
I've not built any multi-language sites, so you're best taking advice from those who have.
Hello,
I haven't used Runway yet, but built more multilingual websites using the 'A region for each language' strategy – as referenced in docs, in all cases. When each language has basically the same pages, and regions, to me it makes more sense, and has a lot of maintenance benefits:
• No need for page multiplication per language.
• No need for template multiplication per language (if default English labeling is ok).
• Multiple-item regions are still 'branched' per language, which is often enough for simple websites.
• Language-specific html tags and attributes like
lang=""can still be modified dynamically, if necessary. (I'm not sure how it works with search engines though.)I've tested the above with websites up to four languages, and it worked well. Sometimes it was a bit too busy in the admin, when there were a lot of Perch regions on a page. I'd only use 'Branched site' strategy, if content varied greatly per language. Of course, it depends on the level of control you'd like the content editor to have too.
If there'll be more content editors for each language, you can even create user roles for each, and assign to the according language's regions, creating a cleaner editing experience.
HI Stephen,
I think you have identified the best method for your needs. I have use the $lang switch technique - which I find quite good. My site only had three languages and an average of 7 field or areas per page. I do like the URL simplicity. And in terms of SEO I think this makes a more manageable site. Also most importantly dates, times and addresses don't require translation. The switch technique just passes these through without the $lang filter. My site has about 8 pages and relies heavily on collections for sorted content. I would make decisions based on the backend usability, SEO and php render-time in both approaches.
Thanks Márton and Ian, some useful insights.
Hello,
Let me add some infos to my post, I researched yesterday.
I'm now building a website, that's important to be SEO-optimized for each language. I searched how search engines handle multilingual websites, where site languages are managed by cookies – so that there are no separate URLs for each. It turned out, that many websites, and docs issued by Google suggested not to use this method, if SEO matters.
I've reconsidered my above suggestion in terms of SEO, and will go the 'branched site' method this time, as I can't risk my website to only be indexed in its default language.