Language changes backend translation on pages
Hey,
While Markus is having trouble with translated buttons (http://www.sitefinity.com/devnet/forums/sitefinity-4-x/bugs-issues/translation-changes-backend-language-on-pages.aspx) I thought I'd copy his title to address a problem I'm having with v4.3.1873/1885 with regards to backend languages.
I have a multi-lingual site, Backend [EN], FrontEnd [EN (default), NL, SK]. I've created numerous pages in EN and translated some to NL and SK. Today I logged in to the Backend, went to Administration >> Settings >> Languages and set the default language for public content to NL. I added Dutch as a language for the Backend system and set it as Default. Clicked Save changes. Imported the new Dutch language pack and logged off.
After I logged in again, all my single language pages (previously EN) are now marked as being NL!
All my English pages have disappeared and all content has been marked as Dutch. If I click and edit a 'NL' page, I'm seeing my English page, with the English page url/name. If I click on 'EN' or 'SK' it asks me to give a page name/url and asks if I want to synchronize from NL.
Relogged, recycled and even rebooted but the entire site switched to NL. Just to confirm I'm not stupid, I've looked up an old screenshot I used on a support ticket last week. (1st screenshot last week, 2nd screenshot today)
---
Clearly the desired behaviour of selecting a default Backend language is that the language chosen represents the interface being default and not previously created content switching languages?
I've got the idea that because initially I had just 1 Backend language, none was set to default.
Then when I added a language and selected it as default (before saving changes) Sitefinity just looked and said, oh default is NL, so all pages that have no 'default-language tag' are Dutch and then went to work and created the necessary changes.
And by doing so totally ruining the entire site because now 'NL' pages have 'EN' url's, 'EN' pagenames and 'EN' content and are marked as the language to synchronize from...
Hi Jochem,
Thank you for contacting us.
1) Changing the default back-end language should not have any effect on your existing pages. It only affects localized labels and messages. This is not used for localization of data items at all.
2) Changing default front-end language must keep your current pages. Just change the path prefixes. For example on my test site in Sitefinity 4.3 I have 2 front-end languages EN-GB and BG. The default culture is set to EN-BG and my home page url for this culture is /home. The url for BG culture is /bg/home-BG as my page has different title. Upon changing the default frontend culture Sitefinity makes the BG home page default so now my site automatically displays the Bulgarian version when I access the site and the English version is available under /en-gb/home.
This is true for pages that have translations. However for pages that are not translated, the situation is a little bit different. In order to support changing cultures from the UI we need to keep the default language version for an item in the invariant culture. Only when you create a translation (split or sync) we start using the other cultures. What happened on your project is that pages that were not translated stay in the invariant culture and shown under the default language. To resolve this set your language settings to their original settings (EN default for front-end), then translate the pages to NL and then move to NL as default language.
Best wishes,
Radoslav Georgiev
the Telerik team
Hi,
I think that there is some misinterpretation of the use of the invariant culture. When you create pages for any single (monolingual) FE language (be it Dutch, Bulgarian or English) there is no explicit culture set for LStrings (invariant culture). The only difference when you set a monolingual FE language is that the current thread's UI culture is set to the FE language. Now when you change the monolingual default language there are no problems with your content. As opposed in 3.x where a default culture change would require running SQL scripts to change the culture ids for items. This is not good in terms of maintenance.
When you enable more than one language a change happens to the database. We upgrade the tables in order to support the additional values for different cultures. The procedure for changing the default culture when you are not in monolingual mode is that you need to create translations before hand if you want to get the results you expect.
Kind regards,
Radoslav Georgiev
the Telerik team
Hey Radoslav,
You're right, definitely some misinterpretation on my part... Because I'm seeing monolingual FE language pages created in anything but English as not invariant.
As I've tried to demonstrate, Monolingual EN pages are invariant, but Monolingual NL pages are not. (see the sfv442117---frontend---default-EN---NL-secondary.PNG screenshot).
---
For me, the bugging issue with this as follows:
If I start building a site with monolingual EN and later add a 2nd language and make that language the default language, all my pages will be in the 2nd (default) language.
If I start building a site with monolingual NL and later add a 2nd language and make that language the default language, all my pages remain NL.
To me that doesn't sound like consistent nor desired behavior...
Jochem.
Hello,
The problem is not in your interpretation. The design of the multilingual feature is rather complex and it requires better explanation in our documentation (this is already in our pipeline). What happens here when you set a single NL language before creating the first item on your website is the same as when you have already created the website on English and then switch the default language. The process is the same, however since there is no data on the site you cannot notice it.
With a risk of repeating myself, I will mention once more that in order to have the behavior that you expect we need to go through all the data upon a language change and change its culture. This is not scalable at all and we are avoiding it by having the current design of the multilingual feature.
We will revise our multilingual documentation to provide a more in-depth explanation of the multilingual feature, to avoid pitfalls like this one. On the other hand when a multilingual site is created we need to take into consideration that it will be multilingual and set it up from the beginning (at least set the default single language not to be English, it later on it is going to be changed).
All the best,
Radoslav Georgiev
the Telerik team
Dear Radoslav
Dear Jochem
Could it make sense upon installation/setup to define the langues you want to use.
My dream would be
1) Select front-end languages and set default
2) Select back-end languages and set default
- Selecting back-end languages would import/setup the language files
- Selecting back-end languages would add spellcheck files as well add the spellcheck option to the radEditor
It's kind of having the SMTP setting right on the setup (with test and skip option)
Markus
Hey Radoslav,
First of all, you shouldn't apologize while I'm the one who should because to be honest, I've never read the documentation. You guys have managed to make Sitefinity so intuitive that I've become to lazy to bother with the first rule of IT: RTFM :)
Before I'll shut up and go read up on the documentation, I just want to share my two cents as what I (from an administrator and not developer) perspective consider the expected behavior should be:
Hello,
Thank you both for the suggestions. They are logged for revision by team. If we decide to implement them, they will be announced on our road map.
Greetings,
Radoslav Georgiev
the Telerik team