Remove default language
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).
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
#1 Updated by Georg Ringer about 2 months ago
- Target version set to Candidate for Major Version
- Complexity set to nightmare
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.