In admin/config/regional/language/list
we have the language labels be presented using both the native and the non-native form of the language:
In places like the user account edit form however, we output only the native label:
...and in the "Add language" form (in admin/config/regional/language/add
), the dropdown select uses the non-native version:
This is because the function language_list()
accepts an optional boolean $native_names
parameter, which outputs the labels either in the non-native/English version (default behaviour), or in their native version (if $native_names
is passed as TRUE
to the function).
I would like us to consistently be outputting both versions of the language labels everywhere, and I also believe that the default should be that (like in the language listing page). Since that would constitute a backwards compatibility breaking change though, I would like us to at least figure out a way to allow output of both native and non-native labels in the #options
array (if the optional $option_list
parameter is set to TRUE
), and see if we can do that in the 1.x cycle, keeping backwards compatibility and the output of the function otherwise unchanged if possible.
Recent comments
The accepted answer refers to Drupal and has weird formatting (missing capitalization at the beginning of paragraphs). Seems to me it was either copied from a Drupal post, or AI generated...
Ckeditor 5 click to activate
For the Dev meeting: I would like to discuss whether we should have a policy in the Forum that AI provided solutions should be attributed to AI and which model it is from. We have started...
October 16th 2025 Weekly Meetings
Sudipto, you may have more luck in the CiviCRM forums for this as this looks like a CiviCRM error. Many people use Stripe in Backdrop without issue, albeit it can take a bit to get setup.
Getting Error after submitting event register form By using Stripe Payment Processor