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
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:
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?
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.
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.
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?
@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....