Combining Languages with 'Locales'

[prestoav]

Hi folks,

A lovely client of mine is looking to extend their PW site to include region or 'locale' specific content (e.g. a differently laid out home page, local product prices etc.) for certain world regions. These would be chosen by the user from a header menu and the choice retained for a sensible amount of time.

The site already has languages presented using the native PW language functionality so their current URLs are in the form mysite.com/fr (using French as an example).

We have discussed some different ways of handling the locales. We have ruled out out subdomains for obvious maintenance and SEO reasons. The next thought was browser cookies. However, if possible I'd like to handle the locale specific content server side if possible, rather then sending it all to the browser and using JS or similar to show the content for that locale.

One question they have asked is 'can we use and additional URL segment to achieve this'?  This would enable direct linking to a specific page / language / locale. For example, French speakers in Canada could use 'mysite.com/fr/ca' or 'mysite.com/ca/fr' (we don't mind what order the language / locale appear if that matters).

Has anyone come across / found a solution for this type of question? If so, how did you handle it?

Or, is there an alternative solution for this that I'm missing?

As always, any and all suggestions / thoughts welcomed and appreciated!

[gebeer]

1 hour ago, prestoav said:

One question they have asked is 'can we use and additional URL segment to achieve this'?

Yes, this is what I would go for. Sth like domain.com/fr/market1/, domain.com/fr/market2/ etc. so you have segments /language/market/

You can either

1. reflect this in your page tree

-home
--market1
---page
--market2
---page

2. use URL segments. This would make the routing more complex.

3. You could also use URL hooks with named arguments and do your routing from there.

For 2 and 3 you need to make sure that the URLs with market segments resolve to a 404 without segments/hooks in place.

I've done something like this at https://www.ziehm.com/en/products/ and https://www.ziehm.com/en/us/product-portfolio/ where /us/ is the market segment. In this case we solved it through the page tree structure. Drawback is that similar pages under default market (no market segment) and us market need to be maintained seperately.

EDIT: to avoid maintaining duplicate pages for different markets, you can have a markets parent with markets as children with templates markets and market respectively:
Market pages:

-markets
--europe
--asia
--africa

Then have a page reference field that allows selection of 1 or more markets. Now you use this field in combination with prices or other things. In the rendering logic you can get the price for market by URL segment.

You'd need to have the market chooser direct to the respective market segments of the page. In said project we have a market selector page for each market with the languages to choose from https://www.ziehm.com/en/us/market-selector/

If you have those market pages in the tree, you can also link markets to available languages for that market.

It was fun and challenging to work that out for said project.

[prestoav]

2 hours ago, gebeer said:

Yes, this is what I would go for. Sth like domain.com/fr/market1/, domain.com/fr/market2/ etc. so you have segments /language/market/

You can either

1. reflect this in your page tree

-home
--market1
---page
--market2
---page

2. use URL segments. This would make the routing more complex.

3. You could also use URL hooks with named arguments and do your routing from there.

For 2 and 3 you need to make sure that the URLs with market segments resolve to a 404 without segments/hooks in place.

I've done something like this at https://www.ziehm.com/en/products/ and https://www.ziehm.com/en/us/product-portfolio/ where /us/ is the market segment. In this case we solved it through the page tree structure. Drawback is that similar pages under default market (no market segment) and us market need to be maintained seperately.

Many thanks @gebeer for this. Some of what is needed could certainly be handled by the page tree. I hadn't tough of that. However, I think I'll also look through the URL hooks idea as that might be the only way to handle some of the more complex issues.

[bernhard]

This is a quite common problem, but I haven't seen a good solution for it. Probably there is none, because the problem is not the technical solution, the problem is the problem itself. Does that make sense? We have different languages and we have different regions, so we have a multidemensional thing to show an a single-dimensional website. Even if we had a technical solution (like url segments or page tree) the problem is still a problem in my opinion, because content get's tedious to manage.

But I'd be curious if anybody has found a good solution for it, as I've once talked to someone looking for something similar and he said PW would not be a good solution for this task. I don't think that this is true, but maybe my feeling is wrong and there are other platforms that already solve that challenge properly? Please let me know if you know any.

---

I think if I'd had to build this I'd go with the page tree for regions and a global "data-pages" section for pages that can be shared as needed by the region pages. But it depends on the priorities of the specific project. Maybe reusing content is more important, maybe something else...

What I could think of would look like this:

-- home
	-- content
		-- foo
		-- bar
		-- baz
		-- about us
	-- europe
		-- about us
	-- asia
		-- foo
		-- bar
		-- about us
	-- america
		-- baz

so all content would go into /content and all the regions would be reflected in the tree and only reference those content pages. Routing would be easy and all regions would support all language, eg /en/europe/about-us

Think of it similar to a menu builder. Editing would get a little more complex, but I think that's a small price to pay and I can't think of an easier solution to this multi-dimensional problem 🙂 

[gebeer]

On 4/30/2024 at 10:01 PM, bernhard said:

I can't think of an easier solution to this multi-dimensional problem

Yes, that is why we went with the page tree option. Less headache for developing. Definitely more work, but also more flexibility for the editors.

[poljpocket]

Just adding my two cents about experiences with this sort of thing: No matter how many times you discuss things with clients to create beautiful solutions to exactly these problems, there will always be a point where you run into flexibility problems if you start combining things and creating complex dependencies too much. Yes, usually this means more work for content management but also, this usually costs less in the long run because of exactly that reason. It is always easier to use said page tree option and for us, after many many projects which needed adjustment down the road - or even a rework to finally use the page tree option, we just never think about this anymore at all.

[bernhard]

1 minute ago, poljpocket said:

It is always easier to use said page tree option and for us, after many many projects which needed adjustment down the road - or even a rework to finally use the page tree option, we just never think about this anymore at all.

What exactly do you mean? A page tree with references to global data pages like I mentioned or a simpler approach where editors just copy over content?

[poljpocket]

Just now, bernhard said:

What exactly do you mean? A page tree with references to global data pages like I mentioned or a simpler approach where editors just copy over content?

Sorry if that wasn't clear: Simple approach with as little inter-dependencies as possible and editors will copy over content if needed.