Sitecore multilingual site, default to non-english language even when English version exists - sitecore

I am working on a sitecore 7.1 site which in Web.config is set to a Swedish language.
<site name="SiteName" language="sv-SE" ... />
It works as expected if I go to a page which only has a Swedish version, but if an English and Swedish version of an Item exists, it prefers the English version. How can I change it so it prefers the Swedish version by default even if an English version exists.
I've read John West's post on how Sitecore language can be set here and of the five ways he mentions language can be set, I think the following 2 may be y pertinent to me, but I'm not sure:
Language cookie associated with context site: in my request, I see there is a cookie se#lang=sv-SE. First is this the site context language cookie? If yes, then language is getting set elsewhere down the pipeline.
The default language associated with the context logical site. I'm not sure how to get at this.

The site language setting should be enough, but just in case, there are some other settings you could check:
ClientLanguage: By default, this is set to 'en'.
DefaultLanguage: By default, this is set to 'en'.
The ClientLanguage should not be used for users visiting your site. From my understanding, that is used for the editing interfaces.
Also, according to my decompiler, the Sitecore 7.2 pipelines should only use the DefaultLanguage if the site language cannot be found.
I did notice that a user's cookie for language is read before it will default to the site language. Are you sure you have a fresh session when you are visiting the page with two languages and the user's default session language has not already been set?
Otherwise, as mentioned in one of the comments, do you have a fallback module installed that may have their own configurations?

I think this is more of a feature than a bug. I narrowed down the causes on my end and it appears to be caused by the following.
My browser sends a request header that it expects english content.
if a version of the content exists in the requested language, sitecore prioritizes english, per the user's preferred language, even if the site is configured to default to a different language.

Related

How to disable Sitecore's embedded language parser

I have a site that has many URL rewrites and a good portion of them contain old links that are prefixed with a country code (e.g. /fr, /de, etc). Rewrites without the prefixes work just fine but those with trigger Sitecore's embedded language URL parser which bypasses the rewrite module entirely.
Example
/fr/old-link tries to parse 'fr' as a language and fails as 'fr-FR' is the name of the French language.
Solution I need to disable Sitecore's ability to detect a language prefix in the URL so the URL rewrite module can proceed unhindered.
I can't find where it is in the pipeline that this occurs. I've gone through numerous with Reflector and come up short. I need help please.
Another pipeline to look at is the preprocessRequest pipeline. It has a StripLanguage processor that detects if the first part of the URL is a language and acts on it.
More info on how to get Sitecore to ignore the language part of the url can be found in this post http://sitecoreblog.patelyogesh.in/2013/11/sitecore-item-with-language-name.html
You will need to create a new LanguageResolver to replace the standard Sitecore one (Sitecore.Pipelines.HttpRequest.LanguageResolver). This is referenced in the <httpRequestBegin> pipeline section in web.config. Here you can handle requests beginning with fr as opposed to fr-FR etc. In the past I have done a similar thing for when we wanted to use non-ISO language codes.
EDIT
The LanguageResolver resolves language based on query string first, but will also resolve based on file path (i.e. having fr-FR in the start of your path). I think you would need to inherit from the Sitecore LanguageResolver and override the GetLanguageFromRequest method changing the else statement to use something different to Context.Data.FilePathLanguage - possibly just using regex/string manipulation to get the first folder from the URL then use that to set the context language. This should prevent the failure to resolve language which I understand is killing your URL rewrite module.

Is there any good reason to have Sitecore Media url's including tilde?

I could see blog post from 2011 recommending using "-" instead of "~".
What is the best practice to write media URL in Sitecore 6.5 on .NET 4.0/IIS7.5? Should I keep default /~/media/ or follow blog post advice using /-/media/ or while I am there, why not just use /media/?
I suspect the use of ~ is for legacy reasons. The current recommendation is to use -/media as you point out, but you could use whatever you wanted and it would work. The issue you have just using /media/ is if there is any other item with that as part of the name then it will trigger the media handler, rather than serving up your content for example.
For example, as request for /blah/blah/blah/-/media/images/logo.png will serve up the image correctly, /about/media/news/2013/12/20/sitecore.aspx should in fact serve up a page but will trigger the media handler and return a 404 just using /media/. So if you are going to use something else then make sure it is unique, you may need to enforce it since content editors can be a bit funny about remembering things like this.
Since you are currently using Sitecore 6.5 then I can assume you have existing content. Make sure you leave the existing ~/media trigger to allow your Rich Text fields to continue to work
If you update the Media.MediaLinkPrefix setting on a system that
already has some content in a database, Sitecore may not update the
values in all Rich Text Editor fields that contain values in the old
formats, including inline images and links to media items.
Sitecore Idiosyncrasies: Media URLs
I would probably go ahead and set Media.RequestExtension to an empty string so that image urls are served up with the correct media extension too.
I know this problem appear just when are you using .Net Framework 2.0
Please see next link .
If you run your website under .Net Framework 4.0 and IIS 7.5 you don't have this vulnerability.
Also this document explain a little bit about using of tilde.
Also you can check John West blog about /~/media
So the conclusion is use -/media for media files.
For projects using Sitecore 7.2, you may want to stick to using a tilde or apply the hot-fix mentioned in the following KB article.
https://kb.sitecore.net/articles/998758

Why might a sitecore presentation component produce different output dependent on domain?

As I can't post code I'm asking this as a theoretical question, but giving a scenario.
I have a "newsroom" sublayout, which staticaly binds a couple of XSLTs to list latest news and latest events. The sublayout is used on a newsroom item, the events and news items are descendants of it (though not direct child items, there are a couple of layers of folders to categorise and date items).
The subayout is in use in around 10 sites in our solution with no problem. Each site is a clone of our main site with an extra language version added. We hae succesfully used this with (amongst others) Japanese, Chinese, Russian, Polish and Czech language sites.
Our most recent clone (Turkish), however, shows no items in the event or news lists. The items exist and are published, and display as expected when browsed individually.
The presentation details for the newsroom item are identical to all other newsroom items.
Even more perplexing, the newsoom item itself, when displayed in the context of a different domain, displays correctly.
i.e.
www.mysite.com/sitecore/content/my_turkish_site/path/newsroom?sc_lang=tr-TR
shows the lists without a problem, including dates formatted according to culture, but
www.mysite.com.tr/sitecore/content/my_turkish_site/path/newsroom?sc_lang=tr-TR
shows empty lists.
The exact same problem occurs if language is switched to English (the language of the source of the clone)
Almost all of the Turkish site is working properly.
None of the presentation components are marked as cachable.
None of the presentation components have a specified data source (i.e. they all use the current item/descendants axis)
What are the possible causes of this problem, and how can I test them?
EDIT:
For Mark Ursino
This is the site definition (slightly fictionalised). I can't post that much more of the web.config...
<site name="www.mysite.com.tr" patch:after="site[#name='www.mysite.com.au']" virtualFolder="/" physicalFolder="/" rootPath="/sitecore/content/CloneData/TurkishClone" hostName="www.mysite.com.tr" startItem="/Turkey_Home" database="web" domain="extranet" allowDebug="true" cacheHtml="true" htmlCacheSize="10MB" enablePreview="true" enableWebEdit="true" enableDebugger="true" disableClientData="false" language="tr-TR" />
Some debugging shows that the XSLTs aren't matching the template when the item is viewed in the Turkish context.
This is the debug match used (the select is what we use in our for-each):
<xsl:value-of select="count(./descendant::item[#template='newsitem' and #id!=$topNewsId and sc:fld('__created',.)])"/>
It matches on the same item viewed from other domains.
Debug output shows the Turkish site thinks the template is newsıtem instead of newsitem (the i is wrong!).
I've also tested viewing the newsroom of other sites through the Turkish domain - the problem is the same.
We have the same problem with items based on the eventitem template, and apparently with an Image Spot template.
Have you tried printing out the language, culture and context item id, lang, version within your events lister and xslts?
If that shows anything unexpected you could step-in to some of the Sitecore pipeline resolvers with Reflector Pro's external assembly debugging.
Answering my own question.
Sitecore template names are converted to lower case for use in XSLT comparison, by the Sitecore XSLT extensions.
This lower case conversion hasn't been set as culturally invariant. In Turkish, forcing lower casing of a upper case I gives the lower case ı
Sitecore has replaced calls with ToLower() in the Sitecore API with ToLowerInvariant() as of 6.5 rev.110419
http://sdn.sitecore.net/Products/Sitecore%20V5/Sitecore%20CMS%206/ReleaseNotes/ChangeLog.aspx
As we're not upgrading to 6.5 quite yet we'll be using template IDs rather than names in XSLT for now.
.Net info on strings and culture, including specifically the "Turkish I problem"
http://msdn.microsoft.com/en-us/library/ms973919.aspx

How to get multiple language sites set up in Sitecore?

I am just starting to add support for multiple languages on my site... having a spot of trouble. Here are the steps I've taken so far:
In Control Panel -> Globalization, added a new language (German)
Added a new <site> definition in Web.config with hostName="localGerman.com" and language="de". Also added an alias in my hosts file for localgerman.com to point to localhost and added the host header in IIS.
Went to an item in my tree and added a new version for German. Published whole site.
Now, the host/site setup seems to work OK. When to go to http://localgerman.com/ I get my home page, with lots of missing data... there is no German version... so seems to be using the correct language.
However... when I go to the item I've added a German version of, I still get blank data. In the debugger, I can see that Sitecore.Context.Item is the German version... but all the fields are blank. Item["Content"] returns an empty string. If I manually set the language to "en" on the URL (http://localgerman.com/myitem.aspx?sc_lang=en), then I get the English version with data.
What am I missing here?
Also... when loading the German home page... my menu is blank. Presumably because the items which generate this content do not have German versions. I was under the assumption that when a language-specific version for a given item could not be loaded, then the default language version is used? But this does not seem to be the case. Am I wrong?
OK, looks like I just had the language code wrong. Setting the site language to "de-DE" instead of just "de" worked.
This is a little confusing because the default sites use language="en" instead of en-US.
You added a German version of an item, but did you fill in the fields in German ? Any localizable fields (non-shared) will be empty by default when a new version is created. It sounds like you did the other parts correctly.
The menu being blank is expected: When you try to get an language version of an item that doesn't exist, Sitecore will return null.

Sitecore set/change default language from 'en'

Can anyone recommend the best way to change the default language in Sitecore 6.1. On a fresh install, the typical language for all items is 'en' English, witha nice little USA flag and all.
However, we are setting up a system which is targeting en-AU and en-NZ. When I rename the main 'en' language item in any database, every other item is left without a version in the "correct" language. I recall in the past that renaming this item causes an update across the whole system, but that didn't seem to be the case when I tried it today.
Is there an easy "Sitecore" way to convert all default items to the primary language en-AU? I've considered running a sql update script over the database, but am hoping there is a neater way of doing it.
I don't think that changing anything about the en-language is a good idea. A lot of internal Sitecore objects are based on that language and you could risk loosing labels and help texts in the Sitecore UI.
We usually create all templates, renderings and layouts in the en-language and then create the content items for each language.
Instead you should set the language property in web.config for your site.
Here is an example that we are using from one of our multi-language solutions:
<site name="website_no" hostName="www.site.no|site.no" language="no" />
<site name="website_en" hostName="www.site.com|site.com" language="en" />
<site name="website" language="sv" />
The last line catches all requests not caught by the two first ones.
Couldn't get a site to use Danish as default language for backend UI based on value language="da" in <site...> tag. Changed it to da-DK, which made it work. Don't know if this is expected behaviour, but one might use the fully qualified ISO code to make sure, things are good.