The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.#1309742: Add inline comment clarifying use of language_list() in system_date_format_save() has background.
I'm also wondering why we used enabled (0/1) instead of status for languages, status is what we use for modules, users and maybe we could standardize on that.
Comments
Comment #1
catchComment #2
catchIn this case it's not reall 'in' language_list(), it's more where the return value of language_list('enabled') is used. Which makes me wonder about possibly refactoring this some more.
Comment #3
gábor hojtsyI think it makes a lot of sense to standardise on this if we keep status/enabled a one bit field. However, in light of #1314250: Allow filtering/configuration of which languages apply to what (UI, nodes, files, etc) I'm not sure where to go. We are not sure how to make the UI work for that neither the backend (yet?)...
Comment #4
xjmWell, in the meanwhile, do we just want to add the constants?
Comment #5
gábor hojtsy@xjm: well, we are working in #1387608: Unify language_list() and locale_language_list() to remove the property argument from language_list() among other things, so the original motivation from #1309742: Add inline comment clarifying use of language_list() in system_date_format_save() should be obsolete. Now all is left are
if ($language->enabled)type of code. Not sure this is easier to understand orif ($language->enabled == LANGUAGE_ENABLED)? Also, given the above suggestion I thought the result would actually be $language->status instead of $language->enabled, to rhyme with how we use status for nodes, comments, etc. Which would dictate different constant names as well, right?It would probably help to outline the goals a bit better here.
Comment #6
gábor hojtsyTagging for base language system.
Comment #7
gábor hojtsyNot relevant anymore as per #1539072: Support for disabled languages broken, drop it.