Use default locale without language prefix
Closed this issue · 42 comments
Is it possible to set up the module to use the default locale when there is no language prefix?
For example, if I enter mysite.com/page/, and the default locale is en_US, it would display mysite.com/en_US/page.
Hope you understand what I need, since it's important for SEO.
Thanks,
Ivan
Not at the moment, that is: only for the homepage.
Could you explain why that would be important for SEO? I would have thought that having both mysite.com/page and mysite.com/en_US/page displaying the same content would be seen as duplicate content, which doesn't improve ranking...
Or is it because you need to support 'old' urls known by Google (in which case permanent redirects would be the better option I think)?
Well, I wouldn't have both pages displayed, all the links would lead to mysite.com/page, which is better for ranking than displaying every page as it is in folder.
Ok, I see. At the moment this is not possible. I'm not sure if this is something others would want also..?
OK, I'll try to figure a way and get back to you if I have a solution. Thanks.
I did this by using a redirect in my nginx config to send anything without a prefix to /uk/
Agree that it might be useful to have a "default". I'm not sure I agree that its that important from Googles perspective: https://sites.google.com/site/webmasterhelpforum/en/faq-internationalisation#q1
On 25 Sep 2013, at 13:37, C10ne notifications@github.com wrote:
OK, I'll try to figure a way and get back to you if I have a solution. Thanks.
—
Reply to this email directly or view it on GitHub.
Has there been any additional attempts at this? I, also would really love to have a url structure like this:
/contact-us
/fr/contactez-nous
all english content is within the root like this /
all french content is under /fr
I think, if you can, the best solution may be to do what I did, ie. Configure a redirect with your http server.
Did you redirect /foo to /en/foo or rewrite /foo (so ss would see /en/foo) ?
Is there a good solution for this problem? I have two languages configured, and since Swedish is the main language, and the English version of the site just as a bonus, I would like the default language pages to use URLs without a language prefix.
Is there some other module that manages to solve this?
I don't know about any other modules that would support this. I was hoping someone would come up with a good starting point for this, because unfortunately at this moment I don't have the time available to delve into this...
Also I'm not quite convinced - can someone please explain to me why this would be a good thing?
In my case, the Swedish version is the main version. Probably 95% of all visitors will want to access the Swedish version. Therefore, it's convenient and a better user experience to have URLs without the language code. It's shorter, easier to remember individual URLs. And it's cleaner. Basically I would like the Swedish version of the site to behave like just any normal Silverstripe site when it comes to URLs and have the English version below /en.
With the most recent build of silverstripe and translatable module, it
already appears to do this out of the box. Unique urls, without any
language prefix at all.
On Fri, May 8, 2015 at 12:15 PM, Andreas Lindahl notifications@github.com
wrote:
In my case, the Swedish version is the main version. Probably 95% of all
visitors will want to access the Swedish version. Therefore, it's
convenient and a better user experience to have URLs without the language
code. It's shorter, easier to remember individual URLs. And it's cleaner.
Basically I would like the Swedish version of the site to behave like just
any normal Silverstripe site when it comes to URLs and have the English
version below /en.—
Reply to this email directly or view it on GitHub
#7 (comment)
.
I'm not sure if I understand you correctly but in Translatable it has always been possible to have multiple languages without using prefixes. The languageprefix module was created for people that wanted to use them...
Which build are you referring to? The build I'm using adds the locale to the end of the URLSegment
I may be assuming url . it adds the locale as a query string param to the
end of the url in the admin only. But not in the front end of the site.
I am using "silverstripe/cms": "3.1.12", "silverstripe/translatable":
"2.0.*"
I have ditched the silverstripe-languageprefix module altogether.
On Fri, May 8, 2015 at 12:30 PM, Andreas Lindahl notifications@github.com
wrote:
Which build are you referring to? The build I'm using adds the locale to
the end of the URLSegment—
Reply to this email directly or view it on GitHub
#7 (comment)
.
So what URLs do you get on the front end site?
I browse to /about-us and see the site tree menu for all pages set as
english.
I browse to /a-propos-de-nous and see the site tree for all french pages.
On Fri, May 8, 2015 at 12:37 PM, Andreas Lindahl notifications@github.com
wrote:
So what URLs do you get on the front end site?
—
Reply to this email directly or view it on GitHub
#7 (comment)
.
Ah, ok. The thing is I would like to have the French version at /fr/a-propos-de-nous instead, while the english version will be located at /about-us.
Yep. that is what i wanted, also. And i never found a good way to do that.
I opted to explain to clients that we simply did not need the /fr in front,
seeing as all the urls were unique anyways. On the home page for french, I
simply made the url segment "fr". So you hit /fr and it goes to french
home. Every other page was just a regular page with french urls. I now see
no added benefit of adding /fr in front of the main url :)
On Fri, May 8, 2015 at 12:42 PM, Andreas Lindahl notifications@github.com
wrote:
Ah, ok. The thing is I would like to have the French version at
/fr/a-propos-de-nous instead, while the english version will be located at
/about-us.—
Reply to this email directly or view it on GitHub
#7 (comment)
.
@quinnmerio - as I said: no reason to use it if you do not need it. Ditch doesn't sound very nice though :(
@andreaslindahl - it would have to be a bit of a rewrite, because the module expects the prefix (see PrefixModelAsControler ~ #34.
It would have to be optional, because links would either have to be generated with or without prefix for the default language...
I'll try and have a look on monday to see if it's at least feasible.
That would be awesome! :)
Perhaps ditch isn't the right word.. ;-) .. opted to not use.
On Fri, May 8, 2015 at 12:56 PM, Andreas Lindahl notifications@github.com
wrote:
That would be awesome! :)
—
Reply to this email directly or view it on GitHub
#7 (comment)
.
I've set up a test branch called 'no-prefix-for-default'. By adding the following config setting in /languageprefix/_config/languageprefix.yml (and flush):
prefixconfig:
...
disable_prefix_for_default_lang: true
It should: skip the prefix for the Default Translatable locale, perform a permanent redirect for links that still use it, and update the links in the CMS URLSegment field. The alternative links in the header also work.
I would appreciate it if you would test this (think forms, images, etc)
Martine
Great! I will give it a try ASAP!
Hi
Form actions don't seem to work. I get a 404...
Yes I see - it is harder then I thought: basically this testversion doesn't support subpages nor actions, so it is sort of useless so far :(
I would have to subclass the ContentController to change the request handler, and that is not an option at this point. I'll think about another way, but for now - sorry...
No problem! I'm glad you gave it a try!
I've uploaded a new version of the 'no-prefix-for-default' branch. It is a bit of a rewrite, because the original version could not be persuaded to do this. So it definitely needs testing, especially with the subsites module.
@andreaslindahl: If you are still interested, please let me know if you can do some of the testing?
I would be happy to test it!
well, it's ready for download, just not for production yet. Let me know :)
Yup, I downloaded and have tested it. So far everything seems to work as it should, including forms. :)
Well, that's a start :) basically now it's about what should happen with all kinds of urls. For instance if you disable the prefix for the default language 'en', links that have /en/ in them get 301 redirected to the links without prefix. But there can be all kinds of other options.
For instance what happens the other way around, what happens with older links, what happens to, say, french pages called without prefix, etc. Easy to just generate 404's, but what kind of support for 'wrong' or older links would be necessary from a SEO point of view? These are serious questions :)
Hi again :)
Found a bug. BaseLinkForLocale() doesn't seem to work. I believe the reason is this line (#203):
$prefix = LanguagePrefix::get_prefix();
Changed it to
$prefix = LanguagePrefix::get_prefix($this->owner->Locale);
and got it working
Yes I can see that this is a bug, because it will always set the BaseLinkForLocale to the default locale. Thanks for spotting it! Care to create a pull request?
Thanks, merged.
Have you found this version working as it should otherwise? I'd like to make this the master branch, and I don't see any problems myself, but as it's a substantial rewrite, I'd like to be as sure as possible :)
So far it seems to work perfectly. You should perhaps get someone else to test it as well, however. I have only used it on a very small website, with just two languages, so far.
I don't think having two or ten languages, nor two or a hundred pages would really make a difference - the basics are the same. Further more it's alle about page urls. My only worries were things like forms and homepages, but they seem to work fine now.
Other problems might be caused by modules that extend the Link functionality in a non-standard way, but I think that's outside the scope of this module.
Would be nice if other people would test it too, but unfortunately I can't reach out to people other then asking it here :) And I don't really know how big the target audience for this mod is anyway, that's another thing...
But thanks for pointing out bug(s) :)
Cheers, Martine
can you merge this to master and tag it?
seems to work here very welll.
I've moved the current version to a separate branche 2.0, and tagged it as 2.0.0. I'm doing some final tests on the new version after upgrading to PSR-2 and I will shortly release it as v3.0.0
The new version is now released as v3.0.0