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?

Parent issue

#1260488: META: Introduce real language APIs

Comments

Gábor Hojtsy’s picture

Issue tags: +D8MI

Tagging.

Gábor Hojtsy’s picture

Issue summary: View changes

Add parent

sun’s picture

The 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.

Gábor Hojtsy’s picture

@sun: where would you load in the object then if locale module is not enabled and language_default() returns a language code?

sun’s picture

Misunderstanding. The variable_get() should return a language identifier. language_default() can still return an object.

Gábor Hojtsy’s picture

Yes, 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? :)

sun’s picture

That 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.

sun’s picture

Issue tags: +API clean-up
Gábor Hojtsy’s picture

I've opened #1293304: Break up locale.module, but how? for a possible language module.

andypost’s picture

Now we got a language.module but on early boostrap there's no ability to get defualt lanfguage

Gábor Hojtsy’s picture

@andypost: what did language.module change? What is not possible that was possible before?

Gábor Hojtsy’s picture

Issue tags: +language-base

Tagging for base language system.

YesCT’s picture

I'm wondering, is this has been replaced by other related recent issues?

Gábor Hojtsy’s picture

@YesCT: I don't think there is one that replaced this.

YesCT’s picture

OK. Looks like more discussion is needed? I could not identify any concrete next steps.

YesCT’s picture

Issue summary: View changes

More verbose parent header

plach’s picture

I think this needs at very least an issue summary update, since the current HEAD is very different now.

Gábor Hojtsy’s picture

Status: Active » Closed (duplicate)

There 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.