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
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 would like your support in order to get some help in customizing the search component in Liferay DXP 7.0 Enterprise.
I have reviewed all the available documentation but although I have found many articles about the issue, the step by step is not so clear for me.
I need to customize the native search component:
Change the input component to give suggestions while the user is typing the search terms
Change the search result page look and feel.
Anyone ever implemented anything like this?
I know this is an old thread, but StackOverflow keeps showing it as the first open question when I am navigation this particular tag...So here are some pointers, as this is a pretty broad topic...
The search is really confusing for adding customization. Mainly you have to provide some of them as contributors, using the asset framework. following the regular steps to build an asset for the asset publisher you will hit the best place to find documentation about the search contributors.
About the search page, best is to create a new page, besides the default one for extra freedom. As long you use the friendly URL /search it will a basic replacement. In this page you can add everything you need, except for translations for the friendly URL - not great. Another option is to keep the default page (which will not be visible in the build area 7.1.x, but you can edit after you search something and fall inside it).
I was wondering what would be the best way to achieve a multi-language template based website. So say I want to offer my website in Englisch and German there are some different methods. My interest is mainly about SEO, so which would be the best way for search engines.
The first way that I often see is using different directories for each language, for example www.example.com for English and www.example.com/de/ for the German translation. The disadvantage of this is: when changing a file, ist has to be changed in every directory manually. And for search engines the two directories would be concerned as duplicate content, wouldnt they?
The second way I know is just using some GET value like www.example.com?lang=de and then setting a cookie. But this way search engines probably wont even find the different languages.
So is there another way or which one is the best?
I worked on internationalised websites until this year. The advice we always had from SEO gurus was to discriminate language based on URL - so, www.example.com/en and www.example.com/de.
I think this is also better for users; if i bookmark a page in German, then when i come back to it, i get a page in German even if my cookies have expired. Similarly, i can do things like post the URL on Facebook, and have my German-speaking friends click on it and get a site in German.
Note that if your site serves multiple countries, you should handle those along with language - so, you might have example.com/de-DE, example.com/en-GB, example.com/en-IE, etc.
However, this should not involve duplication. Instead, you should set your application up to process the URL, extract the locale information, and then forward the request internally to a locale-independent page. So, a request for example.com/de-DE/info and a request for example.com/en-IE/info should both be passed to /info.jsp (or i'm guessing info.php in your case). That page should then be coded to emit text in the appropriate language, using a page-level localisation mechanism.
Things are a bit trickier if you want the URLs themselves to be localised (eg example.org/de-DE/anmelden vs example.org/en-IE/sign-in). However, the same principle applies: extract the locale, then forward to a common page. The difference is that there must be more sophistication in figuring out what the page is from the URL; you will need a mapping from natural language in the URL to the page filename.
I am creating a Multilingual web site and I use a resource manager for each language.
when user select a language all pages use the selected resource bondles.
as entire sites only is available in one language,how search engines crawl the other languages ?
or does search engine crawl optional provided languages ?
As you know, when you have a static multilingual website that has separate page for each language, you don't have any problem with search engines. Whereas, each page has an unique url.
But in dynamic applications, you don't have separate page for each language and have to use resource instead, you can add a new language or remove an already existing language and so on.
Therefore, we have to use Url Rewriter/Routing for generating unique url for each language. Check the following example out.
Suppose we have a webform in the following url and our application supports two languages (e.g. English United States en-US, English Great Britain en-GB).
www.domain.com/home.aspx
There are some problems, we have permanent url for all of languages. Thus, search engines will be index the default language anyway. The solution is simple, you have to generate separate url for each language by using Url Rewriter/Routing as follows.
www.domain.com/{country}/{language}/home.aspx
Afterwards, you have to inference the specified culture name from the above url and set the current Culture and UICulture properties. Thus, the requested page will be shown in desired language.
The sitemap should be generate programmatically and uses the same way as above, in this case.
www.domain.com/{country}/{language}/sitemap.xml
You have to inference the specified culture from the above url and generate sitemap dependent on culture. To introduce available sitemaps to the search engines you have to use robots.txt that should be generate programmatically as well.
you might be using cookies/sessions for remembering selected language, right?
Neither of them affects search engine. They simply ignore cookies. However, If u rely on session variable for remembering selected language, in the absence of cookies each time new session will be created canceling the language selection.
Ankit