Drupal has a little utility function called language_default(). This uses a variable as in variable_get() to retrieve the default language. Other places save this variable when the default language is updated. The reason for having this function at all and using a variable for it were as follows:
(1) this function and the variable is available outside of locale module, so we have information on a default language even if locale module (and therefore language list) is not there
(2) there is a single place where the default language is stored, its not a flag in the database, where it seemed to be harder to ensure only one of the languages is the default (also see (1) on when no db is available)
(3) there is no quicker way to get a default language then using the variable system
There are also several problems with the variable:
(1) As @sun pointed out in #1265700: Little modernization of language_default(), its storing a whole object in a setting, not nice.
(2) Related: duplicates data from the language table, can become outdated independently, and needs some special attention to keep updated.
(3) Langauge objects do use the "default" property to cache a boolean on whether they are the default, and the load and save functions need to work with updating the variable based on that property, so data storage structure is pretty different to the objects in PHP
How can improve on this situation?
Comments
Comment #1
Gábor HojtsyTagging.
Comment #1.0
Gábor HojtsyAdd parent
Comment #2
sunThe variable value needs to be replaced with a string (language identifier).
The helper function can stay, and depending on bootstrap/installer phase, it may or may not load the information from the database.
Comment #3
Gábor Hojtsy@sun: where would you load in the object then if locale module is not enabled and language_default() returns a language code?
Comment #4
sunMisunderstanding. The variable_get() should return a language identifier. language_default() can still return an object.
Comment #5
Gábor HojtsyYes, where does it get the data for the object from if there is no language list to load from (no locale module?). We store the object in another variable (which then also needs to store the language code too? :)
Comment #6
sunThat should be the responsibility of the language.module we badly need. Until then, I'd just simply return a hard-coded object for English, and otherwise require to enable Locale module - just for the time being, to be properly fixed by language.module later on.
Comment #7
sunComment #8
Gábor HojtsyI've opened #1293304: Break up locale.module, but how? for a possible language module.
Comment #9
andypostNow we got a language.module but on early boostrap there's no ability to get defualt lanfguage
Comment #10
Gábor Hojtsy@andypost: what did language.module change? What is not possible that was possible before?
Comment #11
Gábor HojtsyTagging for base language system.
Comment #12
YesCT CreditAttribution: YesCT commentedI'm wondering, is this has been replaced by other related recent issues?
Comment #13
Gábor Hojtsy@YesCT: I don't think there is one that replaced this.
Comment #14
YesCT CreditAttribution: YesCT commentedOK. Looks like more discussion is needed? I could not identify any concrete next steps.
Comment #14.0
YesCT CreditAttribution: YesCT commentedMore verbose parent header
Comment #15
plachI think this needs at very least an issue summary update, since the current HEAD is very different now.
Comment #16
Gábor HojtsyThere has been so many changes. With storing the default language only as a language code on system.site now and the default language service, the goals of this issue are resolved.