Language admin form: move top-level language properties to table form row

Created on 8 January 2013, over 12 years ago
Updated 22 May 2025, 10 days ago

Updated: Comment #43

D.o procid experiment

This issue would be a good case study to evaluate procid #2154143: Evaluating Procid, a tool to help the drupal community improve the consensus building process for d.o issues
You do not have to use procid to work on this issue, but if you want to, your feedback would be very helpful.

Problem/Motivation

Follow up issue from #1877338: Convert language admin form to new #type 'table'

If "Interface Translation" is enabled it provides a column in the language admin form which shows the 'translation ratio' of a language.

This column is being added through locale_form_language_admin_overview_form_alter and the language entities are therefore needed within the form_alter_hook.

This issue is about how to make languages entities available in locale_form_language_admin_overview_form_alter in a clean way (and it should therefore be renamed).

Currently the language entities are passed to locale_form_language_admin_overview_form_alter from LanguageListBuilder through $form['languages']['#languages'];

Sun states in #1877338: Convert language admin form to new #type 'table' :

it's a bit strange that they [the language entities] are added to the top-level table element [the form], instead of the corresponding table row.

Moreover:

we actually try to avoid adding raw data objects in the $form structure; contextual data objects are added and tracked in $form_state normally; i.e., $form['languages']['#languages'] becomes $form_state['languages'] and $form['languages']['#language_default'] becomes $form_state['language_default']

Proposed resolution

  1. Pass a single language entity through the according row: So far this wasn't discussed
  2. Pass the language entities through $form_state['languages']: Same as above, not discussed yet
  3. (Re)load the language entities through LanguageManager: Patch #28, needs reroll
  4. (Re)load the language entities through LanguageListBuilder by $form_state['build_info']['callback_object']->load(): Patch #33,
  5. Implementing getEntities() in DraggableListBuilder to load the cached entities by calling $form_state['build_info']['callback_object']->getEntities(): Patch #43,

Remaining tasks

  • 1) and 2) have not been discussed.
  • 3) and 4) reload the entities, these could differ from the original language entities loaded in LanguageListBuilder. How likely is that? Performance relevant?
  • 3) would need a reroll, 4) might need an interdiff?
  • 5) needs review

Decision / discussion on what to do.

User interface changes

None. The marked column in the screenshot is being added through locale_form_language_admin_overview_form_alter, which isn't the topic of this issue.

API changes

1) - 4) don't involve API changes, 5) will at least implement getEntities() in DraggableListBuilder, wider API changes might be needed to make this consistent.

Related Issues

📌 Task
Status

Postponed: needs info

Version

11.0 🔥

Component

language system

Created by

🇦🇺Australia kim.pepper 🏄‍♂️🇦🇺Sydney, Australia

Live updates comments and jobs are added and updated live.
  • Needs issue summary update

    Issue summaries save everyone time if they are kept up-to-date. See Update issue summary task instructions.

  • D8MI

    (Drupal 8 Multilingual Initiative) is the tag used by the multilingual initiative to mark core issues (and some contributed module issues). For versions other than Drupal 8, use the i18n (Internationalization) tag on issues which involve or affect multilingual / multinational support. That is preferred over Translation.

  • stale-issue-cleanup

    To track issues in the developing policy for closing stale issues, [Policy, no patch] closing older issues

Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • 🇺🇸United States smustgrave

    Thank you for creating this issue to improve Drupal.

    We are working to decide if this task is still relevant to a currently supported version of Drupal. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or is no longer relevant. Your thoughts on this will allow a decision to be made.

    Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

    Thanks!

Production build 0.71.5 2024