A couple of places in core, a global $language_url is used:
http://api.drupal.org/api/function/l/7
http://api.drupal.org/api/function/theme_links/7
http://api.drupal.org/api/function/locale_language_url_rewrite_url/7

However, I can see nowhere in core where the *global* $language_url is ever given a value, unless it is done somehow that I can't find by grepping for the string language_url (i.e. without quotes or $) in the entire code base. That string only comes up a few other times: in function names, and also as a *local* variable in
http://api.drupal.org/api/function/locale_language_from_url/7

I am not exactly sure what these three functions are trying to do with $language_url, or which global they should be using (perhaps $language?)... Or else I'm missing something, which is entirely possible, and $language_url is being set somewhere?

CommentFileSizeAuthor
#9 globals-724504-9.patch1.58 KBplach
#3 globals-724504-3.patch988 bytesplach

Comments

plach’s picture

Status: Active » Closed (works as designed)
jhodgdon’s picture

Title: global $language_url is used but never set, I think? » global $language_url and similar globals need documentation
Component: language system » documentation
Status: Closed (works as designed) » Active

Ah, thanks! These $language_* globals need to be documented in the globals.php file.

This will make them appear on http://api.drupal.org/api/globals/7

plach’s picture

Status: Active » Needs review
StatusFileSize
new988 bytes

Attached you can find a patch for the current globals.php that adds the missing documentation. It already incorporates the changes that will get in with #282191: TF #1: Allow different interface language for the same path.

Status: Needs review » Needs work

The last submitted patch, globals-724504-3.patch, failed testing.

plach’s picture

Status: Needs work » Needs review
jhodgdon’s picture

Status: Needs review » Needs work

A note: The globals.php file is in the contributions repository, so don't worry about the fact that the patch doesn't apply.

However, it needs work. For one thing, every doc header needs to start with a one-line description of the variable, less than 80 characters, ending with a period and followed by a blank line, rather than having a clump of several lines together at the top. See http://drupal.org/node/1354 for more information.

Secondly, the description of $language_url() is not complete. It is used in more functions than just url() [see original issue report above].

Third, I think there are other globals besides these two that are initialized in drupal_language_initialize(), aren't there? Maybe not...

plach’s picture

...
See http://drupal.org/node/1354 for more information.

I should know that, just forgot it :)

Secondly, the description of $language_url() is not complete. It is used in more functions than just url() [see original issue report above].

Actually there are three places it's used in: l(), theme_links() and locale_language_url_rewrite_url(). I wouldn't list them all, I'd just say "url-related functions", as it's used the same way by all of them.

Third, I think there are other globals besides these two that are initialized in drupal_language_initialize(), aren't there? Maybe not...

No, just those three (in core). I.e. only the ones returned by http://api.drupal.org/api/function/language_types/7.

jhodgdon’s picture

OK, sounds good.

The patch still needs reformatting... I think it would also be useful to explain what "interface language", "url language", and "content language" are, and put in a link to drupal_language_initialize() (the function that sets them up).

plach’s picture

Status: Needs work » Needs review
StatusFileSize
new1.58 KB

Revised patch.

Status: Needs review » Needs work

The last submitted patch, globals-724504-9.patch, failed testing.

jhodgdon’s picture

Status: Needs work » Fixed

Looks excellent. I have applied it to the actual globals.php file in the contrib repository. Thanks!

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.