@Hugo
- account synchronization synchronize just accounts. With listings it is too complicated.
- classifieds has different content. On wordpress/blog, you are owner of content and do not hesitate to translate it into all languages. Primary content are articles from authors.
Problem:- most users write their listings in 1 language only (I never seen user to write 1 listing in English, then switch to other locales and write same in other locales - I mean when publishing listing)
- now consider you have locale versions like site.com/en/, site.com/de/, ...
- all these listings will show
same content across different locales.
- what is SEO benefit? None ->
duplicated content ruins it all, that is what you do not want.
- you would have listings written in English on German site - that is irrelevant/mixed content here.
Solutions:- use country based subdomains ---> Problem here is that in some cases, 1 country may use 2 locales (but I am not sure how it is in these countries that i.e. DE user would never access or wanted to access NL site)
- create 1 domain per locale and split listings across them. Means to have site.com, site.de, site.sk ---> this is much more common in classifieds.
In this case listings will be separated. English ones on .com, German one on .de etc...
What you only need is to synchronize accounts across these (account synchronizer plugin), but still in most cases, .sk user will most probably ever access .de version of your site
There you got SEO benefit, because content is
NOT DUPLICATED.
For these reasons it was never considered to split content across sites, but it works on static pages (as you are author of them and you will translate them).
Examples:
https://delta.mb-themes.com/ar_SY/legal-p29https://delta.mb-themes.com/en_US/legal-p29--> problem: language swtich is not fluent and is complete after page reload (probably osclass bug)
What would you need to do for ultimate solution?
- redesign links in osclass and rewrite rules
- add new feature to osclass languages to reduce length of locale, i.e. en_US to en, ar_SY to ar, but must be able to identify i.e. if you have en_US and en_GB on site, then some workaround must be there.