"Translating" Website for different Regions

we recently got the requirement to publish the english version of a website already translated to 5 languages (de, en, fr, it, es - currently using archetypes + linguaplone) for the us market under a different domain.

first i'll outline the requirements and possible solutions we thought about.

my key questions here are:

  • can you think of better solutions to solve these requirements?
  • has somebody already implemented something that solve the remaining contra-point of solution C)?

i can for example think of websites running shops to have similar requirements (different products, prices/taxes depending on the country of the customer)

requirements:

most of the content of the english version shall remain unchanged.
however there are some things that should be changed for the us website:

  • different portlet content (i.e. contact-portlet)
  • different UI (i.e. no language chooser)
  • some articles shall only/not be shown on us-site
  • some articles shall be replaced (i.e. list of sales partners)

to not get punished for duplicate content we gonna add additional headers for the us-website on all other translations

<link rel="alternate" href="http://mydomain.com/products" hreflang="en" />
<link rel="alternate" href="http://mydomain.de/produkte" hreflang="de" />
NEW: <link rel="alternate" href="http://mydomain.us/products" hreflang="en-US" />

possible solutions:

A) copy paste

  • creating a copy of the current zope instance

  • modify the content in the en/ folder

  • and publish it under mydomain.us

drawback:

  • lot of work to maintain mydomain.com and mydomain.us in parallel
  • not possible to automatically generate links to all translations (as the copied instance does not know about new content in the other languages)
    so we'll end up being penalized for broken hreflang links

B) Translate en to en-US

  • add another available language en_US (i guess we'd have to patch Linguaplone for this)
  • script translation of all en content to en_US

pro:

  • editors are familiar with managing translations
  • system can generate hreflang meta links
  • we can easily add / remove some articles for en_US only

drawback

  • it's still a lot of work to keep content of en and en_US in sync (but this time system can help)

C) browser-layer

while thinking about how to safe our editors from having to maintain yet another translation tree i came up with this idea:

  • rewrite mydomain.us to Plone/en (similar to mydomain.com)

  • provide different theme layers in the rewrites for these domains

    /VirtualHostBase/http/mydomain.us/++skin++site.us/Plone/en/VirtualHostRoot/$1
    /VirtualHostBase/http/mydomain.com/++skin++site.en/Plone/en/VirtualHostRoot/$1

  • custom viewlets can be registered for these theme layers

  • code a custom static-text portlet that let's editors choose which layer it shall be displayed for

  • or add an output transform that skips content in <div class="layer-site.us-only">sfadsfs</div> if the layer ist not active.

pro:

  • we'll need this for customized UI elements (i.e no language switcher) anyway

  • no additional translations for en_US needed

con:

  • currently no way to show a content item only for layer site.en or site.us

    this would require to customize the portal_globalnav, the navigation tree code.
    maybe even the search.
    (kind of simliar to what linguaplone already does by filtering for the current language)

has anybody here done something similar or can thinks of different ways to solve this problem?

[head explodes]

B seems much less risky to me, and, given how often I am forced to remember how Americans spell things differently, it makes perfect sense to consider en different from en_us!

We have used the B approach for several of our customers.

You just need to enable "show country language variations" in Plone Language Tool configuration and thus you will get 'en-us', 'en-uk', ..., 'fr-fr', 'fr-be', ...

Moreover you can use collective.linguadomains to signal Plone which languages it should provide under which domain and redirect accordingly.

We developed a custom "copier" which copies all the contents of a "language-country" to another "language-country" and have something to start working on. Similarly you can develop some subscribers to notify content-changes or whatever you need.

Some of our examples are:

http://www.ulmaconstruction.com/ as a "international site" with en and es as languages and http://www.ulmaconstruction.es/es-es a "local site for spain in spanish". It has several other language-country configurations.

http://www.ascelec.orona.be/fr-be as "french in Belgium" site with http://www.orona.eus/eu for "basque" language site.

Sometimes you need to patch the language availability vocabulary in Plone (plone.i18n.locales.languages) to create fake language-countries. For instance to create "english for France" and things like that.

In both cases all websites are handled using a single Plone site.

1 Like

This is wonderful stuff and is crying out to be a tutorial or training or documentation!

Maybe as part of this:

thanks @erral and @tkimnguyen

i was not aware of collective.linguadomains when i implemented this project in 2012. i customized the languageselector viewlet and added a traverser that corrects the domains for each content item if accessed via the wrong domain for its language and passed in the domains via http-headers. the approach with the registry looks more straight forward to me. thanks for sharing this

using linguaplone to manage yet another (combined)language is - of course - straight forward. however if you don't provide additional helpers that support or automate tedious jobs your editors have to pay the price.

i'd be very interested in examples / code snippets / packages for what you call "subscribers to notify content-changes or whatever you need".
we do have a subscriber that copies images in folderish articles when translating them.

do you have something in place to help editors to make sure that a change to en/article1 also gets applied to en-us/article1?

also your script to copy over all the contents of a "language-country" to another "language-country" would help me and others in similar situations a lot in getting started.
would you mind share some of your code/ideas @erral?

@tkimnguyen you are correct with "head explodes" :wink:
i tried to nail the problem down and came up with this question: Content for different target groups

1 Like

I had a very tough week last week and came up with the updates today...

here is our 'copier' script:

thanks for sharing this erral.

i could take your script as a basis and added a lot of addtiional features.

  • fix internal (resolveuid) links and links to images in richtextfields
  • copy all properties (not just default_page and layout)
  • collective.perseo compatibility
  • added logging/error reports
  • mirror workflow settings

i'll share the script here and hope it will help anyone having similar problems:

  • I have been thinking ab* out a 'similar use case' for education:
  • We have 'Exercises for students', that are published by a few teachers.
  • Other schools will use the same exercises, but will modify some of them to suit their needs.
  • So, instead of County A, Country B etc, we have School A, School B, etc.
  • So we want: E 'flag/logo' for each school, and fallback to Case_A, if there is no Case_A_(my school

I assume 'introducing a few new languages ( no_schoolA, no_schoolB would work) but it feels very 'wrong'

Any thoughts ?

@espen:
from a technical viewpoint there is no difference between no_SchoolA and en_NO, however this feels wrong to me too.

i'd rather prefere a solution like the on suggested in Content for different target groups.
but there seems not to be an implementation for target group content yet....

For those interested on this topic, I will talk about it on my Plone Conference 2017 talk https://2017.ploneconf.org/talks/use-case-plone-in-a-multi-country-multi-language-and-multi-domain-applications