I'm posting this on behalf of a client and am unfamiliar with Kentico and .NET so please bear with me.
The issue
Our client has a website in two languages, let's say English and German.
URLs are currently outputting like this:
example.com
example.com/home (when they try to redirect this to the root,
they get a loop)
example.com?lang=de
example.com/home?lang=de
example.com/cat-l1/page
example.com/cat-l2/page?lang=de
Even with canonicalization, the above is very untidy and bad for SEO purposes.
My client has tried to implement multilingual prefixes for URLs in Kentico 8, but wound up with something like:
example.com/en
example.com/de
example.com/en/page
example.com/de/seite
This is better, but I neither want to redirect the root domain nor have the superfluous /en/ subdirectory.
I've gone through Kentico support forums and tried to source documentation, but this information doesn't appear to be readily available.
What I require
I would like to use multilingual prefixes ONLY for alternate languages (not the default). For instance:
example.com/
example.com/de
example.com/page
example.com/de/seite
Can someone please let me know:
What CMS settings need to be set in order to get the required URL
structure to work?
If some kind of custom URL rewriting handler
is required, what needs to be done? (I'll update this as I go, but don't even know where to look/start)
If understand correctly you want default (English) with no prefix, and other langs with prefix. You can do it purely with Kenitco settings (I had the same set up on one of my web sites). Go to settings-> URLs and SEO -> SEO - Cultures.
You need to check the last 2 (Use language prefix for URLs and Allow URLs without language prefixes). Here is the documentation Also take a look at how to configure prefixes
Also make sure that in sites -> your site name -> culture Default content culture is set to English. I know you can do with routes, i.e. you will have /home for english and /de/home for German, but I don't think you can do it with standard URLs. Essentially you will have to switch to routes the whole site (if your site is not big you can do it manually).
P.S. When you adding a new route you need to restart the app in order for route to work (especially in 8).
Related
Let's say I have a website that has 2 languages, one uses Latin and the second one Cyrillic transcriptions in URLs.
For example:
example.com/link
example.com/ссылка
My question is which is more user and SEO friendly, if I leave them as is or if I add the language prefix, so they'd become
example.com/en/link
example.com/ru/ссылка
I understand that such subdirectories should be used if I have languages that are similar and then the user wouldn't be confused, but does that also apply in my case?
It's better to use the second one for better SEO results.
example.com/en/link
example.com/ru/ссылка
Google likes the tree-like structure. Of course you can use the main language without prefix.
Also it's better to have all languages in one domain:
domain.com/en
domain.com/ru
not on subdomains like this
en.domain.com
ru.domain.com
Wish you luck.
What is considered the best strategy for URLs of translated websites? Something I see happen frequently is:
http://example.com/english-slug.html
http://example.com/de/english-slug.html
http://example.com/fr/english-slug.html
This has the (minor) advantage that a user can manually switch to another language by modifying the URL. The disadvantage seems to be that the URL consists of a slug in the wrong language for every page not in the default language. That would cause a SEO penalty, I think.
The alternative would be to translate the slugs as well and optionally omit the language identifier as well:
http://example.com/english-slug.html
http://example.com/deutscher-slug.html
http://example.com/slug-francois.html
Some languages do not really lend themselves to be 'sluggified', such as Russian, Chinese and Arab. You'll end up with transliterations that make little sense.
I think you should use language tags and translated slugs:
http://example.com/en/hello-world
http://example.com/de/hallo-welt
Why language tags? To avoid collisions.
Sometimes you might want to have the same slug for different languages (for example, "team" in English as well as in German).
Why translated paths? For better usability.
Not all users understand the "default" language, and depending on its script, they might not even be able to type/remember/dictate the slug. (It doesn’t make sense in the first place to use human-readable slugs that only part of your users are able to understand.)
Yes, it would be a "(minor) advantage that a user can manually switch to another language by modifying the URL". But it’s unlikely that users or search engines would expect this to work (see my related answer on Webmasters). So you would gain little (URL hacking for advanced users) and lose much (bad usability for users using the non-default language).
That said, it would still be possible to enable this URL hacking feature in most cases: When users change the language tag de (in /de/hallo-welt) to en (/en/hallo-welt), you could check if it exists (if yes, show it), and if not, check if there exists a slug "hallo-welt" in any language, find its English translation and redirect to it (from /en/hallo-welt to /en/hello-world).
Another way is setting the language as a query string parameter, such as:
http://example.com/hello-world?hl=en
http://example.com/hallo-welt?hl=de
for example Google Flights web site uses this method.
The best solution, if you can afford it, is to send the document with the right name, that means, using the right word on each language.
Of course each document should be sent with the respective language setting on the headers.
For storing them, you can use folders and let the web server choose the right document according to the language preference; or you can use server side technology, like PHP, perl, etc to send the document and adjust the URL.
In any case, you have to have a default language to be sent when you don't have the requested language.
If you can't or don't want to send document with the right name, using subdomains is the best next option. This option, is not as common as adding the language after the domain, and that means, that people may not be used to it, although, it has some advantages, for instance;
Each language behaves like a whole new URL/site (almost).
People feel like visiting a dedicated site, not a subsection where the second language is relegated and may fail at any moment (some content may not be translated).
Some people are not familiar with their two letter representation of language, but everybody knows how his language is called and spelled.
It generates cleaner URL's.
It is believed that having subdomains increases appearance on SERPs (I don't have knowledge of this and it may have changed).
It's easier to have different layouts if you want to.
It's easier to set different servers according to language.
Of course subdomains have some disadvantages, like:
A bit more work to set properly from the server perspective.
Less collaboration from the part towards high ranking.
Some people may not expect it but expect a subfolder.
Next would be the subfolder option, as you show on the question. This is the recommended way if your main perspective is SEO since all the relevance of the domain stays on that same domain and each language helps to a common "pot" of ranking.
My perspective when choosing a solution, is never SEO, under any circumstance. Whatever ranking I get is due to the content itself and the best use I can give to technology. But I understand that my point ov view is not the most common.
One thing to consider also, is that you should provide some kind of explanation or help the user so he can take actions to change to the preferred language. It may be using icons, a tooltip, or any other method that works for your design and verbosity.
One thing to avoid, and you didn't ask for it, but is related; is using language autodetection. Lots of times, the user is in a different country or using a version of a browser that has a different language from what he can understand and the autodetction just makes a big mess. Offer the default version and a clear way to change it.
Why do so many Ruby on Rails apps have missing trailing slashes in their URLs? One example is http://basecamphq.com/tour. AFAIK this goes against Web standards. Is it something to do with the way RoR is set up?
It's not against Web standards. http://basecamphq.com/tour is considered a file, http://basecamphq.com/tour/ would be a directory (Note: both URLs aren't equal, although some webservers - e.g. Apache - will check the other if one doesn't exist). As both are kind of virtual, it's mainly up to the developer to decide (this is independent of used programming languages or frameworks).
I don't think it has something to do with caching (as mentioned by nilamo) as there are enough HTTP headers for cache control - might be that some reverse proxies have different default behavior though.
Your argument is invalid:
w3c's url spec doesn't enforce trailing slashes on urls.
This is what it says about slashes:
The path is interpreted in a manner
dependent on the scheme being used.
Generally, the reserved slash "/"
character (ASCII 2F hex) denotes a
level in a hierarchical structure, the
higher level part to the left of
the slash.
Rails adheres quite well to this directive.
My hair is a bird!
Because trailing slash denotes a directory, and you are not accessing directories in Rails, but pages. It's like tour.html in your example, except that .html can be ignored as it is the default.
I'd venture to say that since in RoR, the URL you type usually does not map to a static file in a directory, but is resolved dynamically by the routes.rb file, ending the path with a trailing slash doesn't make much sense.
Some like slashes, some don't. Impassioned arguments can be made for both sides.
Rails uses slashes as parameter token separators, and a route like
/post/:year/:page
matches by default both, /post/2012/a-title and /post/2012/a-title/, unless you do some magic. This has nothing to do with web standards.
From the point of view of the browser, these two paths are very different when it comes to deal with relative resources. In a response to the above with <img src="image.png"/> the browser will send a second query to the server for: /post/2012/image.png (first case) or /post/2012/a-title/image.png (second case), because the browser uses the trailing slash to resolve paths as if they were directories.
However, Rails developers usually don't care because they don't write URLs explicitly when rendering content! They have at their disposal URL helpers which hide this logic from them... unless you don't use the helpers to generate content, then you care.
This is a form of URL Re-writing. It is not against web standard and actually does a lot for usability and has been proven to help your search engine rankings. Think of it this way.
You are telling your friend about this cool post you seen on someone's blog. Which URL is easier to tell your friend:
http://www.coolwebsite.com/post.aspx?id=aebe6ca7-6c65-4b5c-bac8-9849faa0a467
OR
http://www.coolwebsite.com/cool-ideas-for-posts/
I am making a RoR site that is delivered in several languages, and want to change a part of the url by its language.
ex.
http://xxxx/en/index.html
http://xxxx/fr/index.html
I know I can do this via the route.rb
map.locale ':lang/index.html'
and designate the language when calling this in view. However, there is an exception
to this, when in the default language of the site, I want the url to be without the language identifier,
http://xxxx/index.html
as so.
Currently I cannot find a way to git rid of the / after the language identifier,
http://xxxx//index.html
is there a better way to do this?
It's not (yet) possible.
But you'll find some solution on this stackoverflow question.
I'm a student of web development (and college), so my apologies if this comes off sounding naive and offensive, I certainly don't mean it that way. My experience has been with PHP and with a smallish project on the horizon (a glorified shift calendar) I hoped to learn one of the higher level frameworks to ease the code burden. So far, I looked at CakePHP Symfony Django and Rails.
With PHP, the URLs mapped very simply to the files, and it "just worked". It was quick for the server, and intuitive. But with all of these frameworks, there is this inclination to "pretty up" the URLs by making them map to different functions and route the parameters to different variables in different files.
"The Rails Way" book that I'm reading admits that this is dog slow and is the cause of most performance pains on largish projects. My question is "why have it in the first place?"? Is there a specific point in the url-maps-to-a-file paradigm (or mod_rewrite to a single file) that necessitates regexes and complicated routing schemes? Am I missing out on something by not using them?
Thanks in advance!
URLs should be easy to remember and say. And the user should know what to expect when she see that URL. Mapping URL directly to file doesn't always allow that.
You might want to use diffrent URLs for the same, or at least similar, information displayed. If your server forces you to use 1 url <-> 1 file mapping, you need to create additional files with all their function being to redirect to other file. Or you use stuff like mod_rewrite which isn't easier then Rails' url mappings.
In one of my applications I use URL that looks like http://www.example.com/username/some additional stuff/. This can be also made with mod_rewrite, but at least for me it's easier to configure urls in django project then in every apache instance I run application at.
just my 2 cents...
Most of it has already been covered, but nobody has mentioned SEO yet. Google puts alot of weight on the URL itself, if that url is widgets.com/browse.php?17, that is not very SEO friendly. If your URL is widgets.com/products/buttons/ that will have a positive impact on your page rank for buttons
Storing application code in the document tree of the web server is a security concern.
a misconfiguration might accidentally reveal source code to visitors
files injected through a security vulnerability are immediately executable by HTTP requests
backup files (created e.g. by text editors) may reveal code or be executable in case of misconfiguration
old files which the administrator has failed to delete can reveal unintended functionality
requests to library files must be explicitly denied
URLs reveal implementation details (which language/framework was used)
Note that all of the above are not a problem as long as other things don't go wrong (and some of these mistakes would be serious even alone). But something always goes wrong, and extra lines of defense are good to have.
Django URLs are also very customizable. With PHP frameworks like Code Igniter (I'm not sure about Rails) your forced into the /class/method/extra/ URL structure. While this may be good for small projects and apps, as soon as you try and make it larger/more dynamic you run into problems and have to rewrite some of the framework code to handle it.
Also, routers are like mod_rewrite, but much more flexible. They are not regular expression-bound, and thus, have more options for different types of routes.
Depends on how big your application is. We've got a fairly large app (50+ models) and it isn't causing us any problems. When it does, we'll worry about it then.