Hello,
I’m working on a site which should be able to work using two languages, while being hosted as 1 site. As far as I can gather, having a subsite is currently not a good idea, because of some templating issues.
So I’m looking at having the English version as an ‘en’ landing page, and listing all contents etc. for the English version within here.
As for the translation for misc. keywords, I’ve been using the localize functions within thymeleaf.
E.g.: data-th-text="${portal.localize({'_key=telephone-abbr'})}"
But these does not seem to consider the current page’s Language, but rather the root site.
Is this a bug?
Is there any workaround to this?
It doesn’t seem to allow dynamic variables to be thrown into the function, and translating each of these keywords backend seems like a lot of work.
If your Landing Page is set to English (“en”) this should be respected on each content you view. Try logging the set language.
If still problems, the view-function (and the controller-function) for translations support explicitly setting language. You could then send content.language into the localize function.
Something like so: data-th-text="${portal.localize({'_key=telephone-abbr', '_locale=' + language})}"
You are right - It uses the site language over local content. This is done in order to avoid “random” behaviour within a site just because an article happens to be in a different language. As Bobby mentions you should be able to force a locale by passing a parameter.
Thanks! The method Bobby suggested worked out fine
I struggle a bit to understand, why is it that the local content is overriden by the site language?
If you’re not using any type of localization, why would the language on that article have any effect? And if you are, wouldnt you want it to display what you chose explicitly?
One more thing here. Making a site with multiple languages inside is currently not best practice, as you only have one default page template mapping. Why not create subsites for each language?
Aha, I will try that out, and see how it works. Thanks for the tip.
In the meantime, I have been working on another possible solution. Optimally the finished project should have 1 structure, and duplication of articles etc. is preferably avoided as it can get cluttered and hard to keep track of in the long run. I have been working on a method of placing language params within session based cookies and GET params to add/change these cookies, so I’m not as attached to Enonics site/page based language selection. After the language is chosen I can then use the i18n lib to translate all the misc. general stuff.
The drawback here is that all the contentTypes and Parts with configurable text needs to have an additional alternative toggle for the english version of the text.
Is this even a viable solution? Seems to be working well so far
In summary you have a selector/combobox in each contenttype to define the language. That is viable. It will be one content per language. Another possibility is to embed all language in the same content using item-set and the same combobox for each set of items. A lot more scrolling for the editor, but only one content. Drawback: same URL for all contents.
I’ve only been prototyping with this so far, but I think it solves most of the templating issues, all of mine at least. But every part, page etc. has to be made with this in mind. It works just like any standard website on 1 site, just selecting which text to use by looking at the cookie. the I18n lib also just uses this cookie value directly.
It’s not perfect at all, but rather at a stage where it barely works So I need some more work before I can figure out the cookie limitations of sessions etc.
So I need some more work before I can figure out the cookie limitations of sessions etc.