I asked about locale translation here Magento: how to translate action tag content?. At the same time magento has translation themes:
app/design/frontend/default/default/
app/design/frontend/default/french/
app/design/frontend/default/german/
If we can do translation in locale files what are design folders for then? (In case we have the same theme for each language). Or is it implied that I should use design folders only when I have different themes?
Actually, a single theme can contain multiple translation locales. The following would be perfectly possible (though obviously not advised):
app/design/frontend/default/french/locale/de_DE/translate.csv
Storeviews are often used for switching between languages, because it is quite easy to set a locale on store-view configuration scope from the backend.
To answer your question more direct, I would suggest that you:
Install an initial language in app/locale/(code).
Anything that deviates from this 'core' locale, to be put in app/design/frontend/(your_package)/default/locale/(code)/translate.csv.
This leaves you room to do overrides in non-default themes at any later point.
Related
I am trying to limit the languages to only English. We have not yet translated any of our content, so having Liferay able to change it's language isn't helpful, and has caused some issues when user's accidentally stumble across URLs that have an alternate language in them.
So we want to limit the language to only English. I have set the following in portal-ext.properties:
locales.enabled=en_US
However, if I then access with a different language in the url ('iw' for example), the page is still translated.
So, am I not understanding what this setting does? Does it only limit the languages available in the language picker or something? I would appreciate any suggestions as this has become a frequent occurrence for our users as Google has also indexed some of our pages in different languages.
We are using Liferay 7 GA 7.
Thanks!
I have tested this on my liferay-ce-portal-tomcat-7.3.5-ga6-20200930172312275 server:
I used these properties in my portal-ext.properties file:
locales=en_US
locales.enabled=en_US
locale.prepend.friendly.url.style=0
When the portal started up, I visited these sites and indeed the pages were not translated as you requested:
http://localhost:8080/iw
http://localhost:8080/de
Please let me know if you had another use case in mind
Some useful resources:
https://issues.liferay.com/browse/LPS-65042
https://docs.liferay.com/portal/7.3-latest/propertiesdoc/portal.properties.html
for me helped adding
locales=en_US
locales.enabled=en_US
to this path bundles/portal-setup-wizard.properties, bundles/portal-ext.properties
I look for a tutorial, help or an example that tells me what I have to do to write a grid element like 2-colums in basic typo3 (v9) with fluid but no other extension like gridelements, DCE, Templa Voila, etc. I want the same gridelements can do but I dont want to be depended to this extention and move it in my own site extention.
I tried the same with normal content elements (CE) like here:
https://docs.typo3.org/c/typo3/cms-fluid-styled-content/9.5/en-us/AddingYourOwnContentElements/Index.html
But how can I nest a CE in a CE? And how can I do this by drag&drop in the backend?
You can't. The page module doesn't support nesting
You can't nest CEs in a CE. On database level this would mean that you have to make a tt_content record a subrecord of a parent tt_content record. You run into several problems, basically the multilanguage support will be broken and the shortcut element does not function as you will expect it to. That is why the extensions "gridelements" and "mask" exist.
I integrated the gridelements configuration into my sitepackage. So I do not need to bother anymore with it.
Just for your info:
There is now an initiative that works on integrating this functionality into the core (Structured Content Initiative, https://typo3.org/article/a-structured-content-initiative/). Stay tuned to it.
There is nothing special about providing Gridelements via external files, since it's based on TSconfig, TypoScript and Fluid. That's why there is not that much about it in the documentation, since it's the same thing you would do with any other kind of sitepackage. The TSconfig and TypoScript parameters are already explained there, while the Fluid would be up to you anyway.
To have a kind of kickstarter just take any extensions providing Gridelements layouts as an example. A very popular one would be bootstrap_grids, which can be found in the TER or here: https://github.com/laxap/bootstrap_grids
You don't necessarily need the flexform controller of that extension, but the Configuration and Resources folders, show you how to configure stuff and you can see how that is included via ext_localconf.php
There are even comments i.e. in the TSconfig files to explain what is possible there and how to handle i.e. mixed environments with record and file based setups. Although it would be recommended to go for files.
You would at least have to add the necessary backend rendering methods to a draw item hook, that will modify the preview of the container element.
So basically you would have to rewrite everything that DCE, Flux, Gridelements or other similar extensions already do.
Which brings us to the question, why you want to avoid those extensions, since especially those three are well known, widely spread, well supported and available for currently supported TYPO3 versions.
I'm trying to setup proper solution for multilingual website generated using Jekyll. I checked some plugins and tricks without plugin. But still not sure how to achieve it. I found that it's possible to generate output of every language into subfolder. Eg.:
/en/ contains English version of website
/cz/ contains Czech version of website
But in my case every language will be published on own domain (example.com, example.cz). And this is the moment where I'm getting some troubles with the implementation. When I'll have every language in own folder (/en/, /cz/) this means that also {{page.url}} and parmalinks will contain that /en/... or /cz/... part.
Could you help me to find the trick I need to use? What is correct setup in this case?
Note: The only solution which is close to my situation is this https://frozenfractal.com/blog/2016/5/13/building-a-multilingual-website-in-jekyll/ Here is not possible to implement language switcher because solution excludes all files in alternative languages. (When I'll be on www.example.com/contact I need to be able to switch to Czech alternative www.example.cz/kontakt.)
Two different urls makes sense to me. Google will have a different page rank for your sites, but that is the only downside I can think of. I would set the language and set alternate tags. You can use your page front matter to fill the alternate tags. If you succeed in building them from one repo, you might be able to automatically match the different language versions of your pages with an english page identifier (for your alternate tags). Source
Am i correct in assuming that i need a nav webpart for each language with the correct corresponding culture code set?
I have on cms:CMSListMenu in my .Master page, and i'm going to be starting the french version of the site.
Your assumption is NOT correct. Kentico is made to use a single template and/or webpart for multiple languages. You do have the opportunity to use different templates per language but unless you need it for something very specific, it's not needed.
The webparts are smart enough to use the current language which has been selected/set on the website. There are some additional configuration options you can set like mixing the default culture with the current culture. What this means is if you are viewing the site in French and have a page in English but not French, it will display the English version and in place of the missing French version.
I'd suggest starting out with the Kentico localization documentation if you haven't already.
I can't agree with you assumption. You can specify culture for you control, so it will always use that culture, otherwise it should be using current culture.
Does anybody know, if in Liferay is possibility to use default value in ui message ? I mean I have two files .properties with translations, for example: en.properties:
welecome=Hallo everybody
someKey=
,and default.properites
welecome=Hallo everybody
someKey=value of some key
I want to achieve, that if I use:
<liferay-ui:message key="welcome" />
<liferay-ui:message key="someKey" />
with English language (where there is no translation for key 'someKey'), the displayed value will be:
Hallo everybody
value of some key
I mean, when there is no translation for some key, liferay portlet will use value from default properties file.
regards
With the standard naming conventions, you typically have files like Language.properties and Language_en.properties. When english language is displayed, but the entry is not contained in Language_en.properties, I expect the value from Language.properties to be shown.
However, in your case you define someKey as an empty value, which means that it's defined as exactly this.
Moreover, Liferay offers a "Language Builder" tool that you can run during development time (in the plugins-sdk just run ant build-lang. It will create configured language files automatically, automatically copying the values from the original file if they are not yet contained in the translated file.
If you have api credentials for bing, it can also use these to get an automatically translated value for various languages, but I'm not a big fan of these. Actually, I'm quite annoyed by automatic translations.