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
Related
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
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).
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.
There is some precedent for search-engine-ranking-related questions on StackOverflow, so please don't close this question. It's programming-related to the extent that HTML META tags can be called "programming".
Here's the problem:
We make FogBugz, the software project planning and bug tracking suite.
Either we did a great job with our old documentation or a crummy job with our new documentation, but for most of the popular searches on FogBugz terms, documentation for our old versions comes up.
Here's an example. For context, our current FogBugz version is FogBugz 7. The top two results for that search are for FogBugz 5, which is positively ancient.
As best I can tell, there are several options for getting these results out of the top slots, but each has problems:
A NOINDEX tag, but what happens if someone is actually searching for help on an old version?
Finding the incoming links to the old documentation and placing a NOFOLLOW on them to deprive the old docs of PageRank. Problem here is that it's really fiddly to find the links to the content, rather than changing the content itself.
The unavailable_after tag, which is just a time-delayed NOINDEX, with the same problem of removal rather than demotion.
I just want these old documentation versions to stop competing with our current versions, without being completely unavailable.
An approach I used in the past (3 years ago)
Change the URL to your old documentation, and change your own links to point to the new url. e.g. abc.com/docs/fogzbugz/v5/xyz becomes abc.com/docs/fogzbugz/ancient/v5/xyz
Using the old URLs, implement a 301 redirection to your new v7 content. e.g. a request to abc.com/docs/fogzbugz/v5/GettingStarted.html is redirected to abc.com/docs/fogzbugz/v7/GettingStarted.html
In this way, existing links from external sites will take browsers to the latest documentation, and inform indexing robots that the page has moved.
Google will find the new links to your old documentation by indexing your site, but there will be no external links, thus reducing page rank.
Google will also find the new links to your new documentation, and as more sites link to it, its page rank will increase and so take priority.
This worked for me on a small scale (100 or so pages) site, and visitor attempts to view the old content rapidly dropped off.
If a user does land on a v5 page, how about the MSDN approach of explicitly stating the version that the page describes, and providing links to the equivalent topic in the v6 and v7 docs?
I would suggest that external links to older versions get redirected to the latest version - with some sort of note that if you really needed version 5 the link is here.
I think a lot of the problem deals with the fact that search engines give something a high rank if a lot of people are linking to a specific page. Unless you can get all the people linking to your old documentation, to link to your new documentation, then you are going to have a problem with the older documents being rated artificially high. In order to overcome this, you might need to change the way you handle documentation pages. One good way would be to always show the newest information on a particular topic, and then only by clicking on a link on the page, do you get to the older versions. Optimally, this would be the same page, with a different parameter, to state which version you want to get documentation for.
What about trying the MSDN approach? You assign a version tag to your pages. When this page is displayed, its version number is displayed as well. Users will be able to see immediately that this information is deprecated.
You may need to write some stubs for new version pages like "This problem has been resolved in the current version" so that the users don't have to think you didn't do anything in 5 years. Some writing work, some interlinking but it's doable for a limited number of problematic pages.