Problem/Motivation
(From #1234848: language_list() doc is missing return value).
In system_date_format_save(), language_list() is used as follows:
$languages = language_list('enabled');
$languages = $languages[1];
This is confusing and does not make sense without reading the code of language_list() (or, hopefully, the improved documentation from #1234848: language_list() doc is missing return value).
Details
The reason for this is that language_list() returns an array keyed by the value of the field it received as an argument; so, in this case, 1 corresponds to the value of enabled. When enabled is used, language_list() returns an array of language objects for each key:
if (in_array($field, array('enabled', 'weight'))) {
$languages[$field][$lang->$field][$lang->language] = $lang;
}
// ...
return $languages[$field];
So, key 1 of the return value from language_list('enabled'); is an array of language objects for enabled languages.
Proposed resolution
Add inline comments to system_date_format_save() (updated from #4):
// Retrieve an array of language objects for enabled languages.
$languages = language_list('enabled');
// This list is keyed off the value of $language->enabled; we want the ones that are enabled (value of 1).
$languages = language_list[1];
Remaining tasks
Create a patch adding the inline comments. This is a good novice issue.
User interface changes
None.
API changes
None.
| Comment | File | Size | Author |
|---|---|---|---|
| #10 | language_list-1309742-d7-10.patch | 606 bytes | albert volkman |
| #5 | language-list-1309742-5.patch | 626 bytes | drupal_was_my_past |
Comments
Comment #0.0
xjmAdded an additional comment suggestion.
Comment #1
jhodgdonThis proposed comment actually doesn't make the code that much clearer for me.
Comment #2
xjmHmm, maybe it needs multiple lines of explanation. :) How about something like:
NB: no idea where 80 chars is in this; whoever writes the patch should be sure to wrap the lines properly.
However, I'm now wondering: should we have a constant
LANGUAGE_ENABLED? That would be a lot more self-documenting and get away from the magic-number-ishness. We have two similar constants:http://api.drupal.org/api/search/7/enabled
Comment #3
jhodgdonHow about just changing the code to say
$languages = language_list('enabled');
$languages = $languages['enabled'];
(or even combining this into one line)?
Then the comment would probably not be necessary?
Comment #4
jhodgdonWait, that #3 idea is WRONG.
How about
Comment #4.0
jhodgdonUpdated issue summary.
Comment #5
drupal_was_my_past commentedPatch attached and ready for review.
Comment #6
xjmThanks @rocket_nova. Do you want to look into adding
LANGUAGE_ENABLEDandLANGUAGE_DISABLEDconstants as well?Comment #7
jhodgdonLet's just get this in... will hit retest button to make sure the bot still agrees.
Comment #8
jhodgdon#5: language-list-1309742-5.patch queued for re-testing.
Comment #9
catchI'm fine with committing this without the constants, but without reading the issue it took me about three reads of the patch to figure out what was going on (I'd assume that language_list('enabled'); gives you a list of enabled languages, more fool me).
Also wonder whether we shouldn't use 'status' for languages same as we do for other things.
Opened #1365680: Add enabled/disabled constants and use them in language_list() for the follow-up. Committed/pushed to 8.x.
Comment #10
albert volkman commentedD7 backport.
Comment #11
gábor hojtsyFYI Drupal 8 is about to remove the property argument on language_list() making it much easier to understand. See #1387608: Unify language_list() and locale_language_list() for ongoing work. That does not have any effect on the D7 backport of this patch that is still needed. Just noting the API is getting better in D8 (once that patch is committed, that is :).
Comment #12
albert volkman commentedVery cool.
Comment #13
xjmComment #14
webchickCommitted and pushed to 7.x. Thanks!
Comment #15.0
(not verified) commentedUpdated issue summary.