Task #89796
closed
Remove default language
0%
Description
In a multi site / multi language project the default language is very confusing, misleading and creates incorrect language id behaviours (sys_language_uid in Database).
For Example:
My multi site / language project has 3 Sites and 2 languages:
- Site 1
- * English
- Site 2
- * English
- * German
- Site 3
- * German
The languages added as website languages (sys_language) are: English = uid 1, German = uid 2.
The editor for Site 1 should only see 1 language (English) and for this site, it should act as default language, as it is the only language.
But if you configure the language English in the Site configuration with languageId 1, the editor can create content in the "Default"-Languagecolumn and English.
However, you don't want them to be able to create content in "Default" and "English".
You can achieve this, if you set the languageId to 0 for the English in the site configuration.
This comes with a problem: all pages / content / domain models generated in English have now the sys_language_uid 0. this is now inconsistent, as the ID for english in the sys_language table is 1.
Furthermore, you have got the same problem at Site 3 -> German should be the "default" language, but in the site configuration it has to be set as languageId = 0. this means, german and english content is in the database, both with sys_language_id 0.
I hope you can see where i'm getting with this.
I may be totally wrong here, but in my opinion the default language is not needed anymore.
Every website actually has/should have a defined "default" language (which should be related to an entry in the sys_language table). I don't see any need for an undefined default language. and with the current state of the site configuration it should be possible to drop the default language.
Also, if you have any solutions for the stated problem i'd be glad if you can help me
Updated by Georg Ringer almost 5 years ago
- Target version set to Candidate for Major Version
- Complexity set to nightmare
Hi,
thanks for creating this issue. It is totally valid but the complexity is huge. This is somehow on the roadmap but it requires to rewrite every query as the field is then changed from an integer to e.g. a locale.
Updated by Riccardo De Contardi over 1 year ago
- Related to Epic #67588: Localization with locales added
Updated by Christian Kuhn about 1 year ago
- Status changed from New to Closed
Hey.
I agree. We should get rid of the 'default' language concept at some point. This is a huge task with tons of dedicated patches and pre-patches in central areas of the system. For example, to even start thinking about this, we would probably want to have the "locale" strings (de_DE) in sys_language_uid instead of the integers. To do this, we need to get rid of sys_language_uid=-1 first, so we most likely need to turn this into a checkbox and make the DH copy the content elements. And that's just one task.
As such, this issue does not help us much at the moment, it is more just one "end goal" of adapted localization handling, and we'll have many single dedicated issues and patches before.
I hope it's ok here since this issue itself does not help us much at the moment.