🇮🇳India @nmudgal

Using #markup bypasses field formatters, caching, and theming, leading to inflexible, inconsistent, and unmaintainable output. As per Berdir's comment, ✨ Respect form display weights in form preview Needs work overriding buildMultiple in the MessageViewBuilder and explicitly unsetting #sorted resolves the issue.
Just attaching the patch for now (Please validate if this is the right approach/place)

Looks like it was just a fluke. Rerunning the pipeline resolved the failing test issue.

I think it's better suited as a custom solution and not something that should go into core.

Firstly, this kind of change introduces a lot of complexity. Core has to handle a wide variety of use cases, and enforcing this behavior across all entity forms and translations might create unintended side effects. For some workflows, users may actually need those non-translatable fields visible even during translation.

There are also performance concerns. Iterating through every field in a form to determine if it should be displayed or hidden based on translation settings adds overhead, particularly on complex forms with many fields. Making this a default behavior could negatively impact sites with complex content models or custom workflows that require all fields during translation.

Finally, Drupal core has to maintain flexibility, and this solution might limit that for users relying on more nuanced control. It could lead to breaking existing sites where those fields are expected to be available, potentially causing validation or data handling issues.

Example Code (Basically overriding core EntityFormBuilder in a custom module):

 public function getForm(EntityInterface $entity, $operation = 'default', array $form_state_additions = []) {
    $form = parent::getForm($entity, $operation, $form_state_additions);
  
    // Check if translation settings are enabled for the entity.
    // This allows us to manage multilingual content appropriately.
    if (\Drupal::service('content_translation.manager')->isEnabled($entity->getEntityTypeId(), $entity->bundle())) {
        $current_language = \Drupal::languageManager()->getCurrentLanguage();
  
        // Check if the entity has a translation for the current language.
        if ($entity->hasTranslation($current_language->getId())) {
            // Load the translated entity.
            // This allows us to modify the entity in the user's preferred language.
            $translated_entity = $entity->getTranslation($current_language->getId());
  
            // Get all translatable fields.
            // We need to differentiate translatable from non-translatable fields.
            $translatable_fields = array_filter($entity->getFieldDefinitions(), function ($field_definition) {
                return $field_definition->isTranslatable();
            });
  
            // This ensures the form only displays fields relevant to the current translation.
            foreach ($form as $field_name => &$field) {
                // Check if the field is defined in the entity and is non-translatable.
                if (isset($entity->getFieldDefinitions()[$field_name]) && !isset($translatable_fields[$field_name])) {
                    $field['#access'] = FALSE;
                }
            }
        }
    }
  
    return $form;
}

Just my two cents on this: The issue with rewritten links in Drupal Views showing 403 "Access Denied" pages is actually quite common and might not technically be a bug—it’s likely more of a design choice. Here’s why:

1. Flexibility in Views

Drupal Views is designed to be flexible. It allows you to rewrite fields and link to any path you choose. Because Views doesn’t inherently know what permissions are required for each custom path you add, it doesn’t automatically check user access on those links. This gives site builders the freedom to link to internal or external paths without restrictions, even if it results in access-denied pages for certain users.

2. Impact on Caching

If Views were to check access on each rewritten link, caching would become much more complex. Caching in Views is optimized for performance, assuming that the rendered content is accessible to the user requesting it. If access checks were enforced, Views would need to account for individual user permissions on each item, which could lead to different cache versions per user. This would be quite demanding and could impact performance.

3. Difference from Menus

In Drupal, menu links are subject to access checks because they’re core navigation items. In contrast, fields and custom links in Views are treated more like display elements, where access checks aren’t applied automatically. This setup keeps Views lightweight and fast, even if it occasionally means users might see 403 errors on links.

4. Possible Solutions

• Help Text: Adding help text in the Views UI could help clarify that custom links won’t behave exactly like internal menu links and could lead to access-denied pages if users lack permissions.
• Conditional Access Checks: For more control, we can add conditional fields or permissions checks in Views configurations or custom code to make links visible only when users have the right permissions.

Thanks to everyone for all the work on this thread. I’ve read through the discussion, and it seems like setting English as the default langcode for configurations could be a straightforward way to avoid language conflicts during module installs. Here’s a quick summary and a few ideas on how we might combine some of the suggestions:

1. Default Configurations to English (langcode: en):
   
   Setting langcode to English across all module configurations would help avoid conflicts and keep things consistent, especially on multilingual sites. This way, English serves as the base, with other languages applied as overrides as needed.
2. Combined Contrib Module and Migration Path for Legacy Sites:
   
   For older sites, a contrib module could help automate the migration to this new standard. It could convert non-English langcode values to English and move existing language settings into overrides. This module could also support language overrides and protect configurations during updates.
3. Temporary Workarounds (config_ignore):
   
   While config_ignore and similar modules are useful right now, moving to a standardized langcode approach would eventually make these workarounds unnecessary, simplifying language management.

Fixed failing test cases.

nmudgal → made their first commit to this issue’s fork.