Skip to content

Rendering: Explicitly contextualize variation context for language fallback (closes #20350) #20587

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Merged
merged 1 commit into from
Oct 21, 2025
Merged

Rendering: Explicitly contextualize variation context for language fallback (closes #20350) #20587

merged 1 commit into from
Oct 21, 2025

Conversation

@kjac
Copy link
Contributor

@kjac kjac commented Oct 21, 2025 •
edited
Loading

Prerequisites

  • I have added steps to test this contribution in the description below

If there's an existing issue for this PR then this fixes #20350

Description

This PR addresses a regression for rendering block editor properties using language fallback under certain circumstances.

The essence is: If element types are set to vary by culture, and the containing block editor property also varies by culture, language fallback does not work. See the linked issue for additional details.

The root cause of this regression is that we do not contextualize the current rendering when performing language fallback. This means that the property value converters will continue to resolve the current rendering context as being for the requested language, rather than the active fallback language.

Following an internal discussion, we have deemed this to be wrongful behavior. This PR therefore explicitly contextualizes the fallback language (culture) before attempting to get a value for the fallback language, and reverts the contextualization after the value has been retrieved.

Testing this PR

  1. Set up at least one extra language, and configure it with fallback to the default language.
  2. Setup host header mappings that allow rendering both languages - e.g. "/en" for en-US and "/xx" for the second language.
  3. Create an element type that is set to vary by culture.
  4. Create a block list data type using this element type.
  5. Create a document type with a template, and configure it as vary by culture. It should contain two properties, both of which should vary by culture:
    • A "title" property of type text string.
    • A "blocks" property of the block list data type created above.
  6. Create and publish a document of this document type in both languages, but only with values filled out for the default language.

Using the template below, verify that fallback works for the second language.

Now fill out values in the second language, republish the document, and verify that no fallback is performed.

Template for testing

@using Umbraco.Cms.Core.Models.Blocks
@inherits Umbraco.Cms.Web.Common.Views.UmbracoViewPage
@{
    Layout = null;
}
<html>
<body>
<h1>@Model.Name</h1>
<fieldset>
    <legend>Title</legend>
    <ul>
        <li>Without fallback: <strong>@(Model.Value<string>("title"))</strong></li>
        <li>Without configured language fallback: <strong>@(Model.Value<string>("title", fallback: Fallback.ToLanguage))</strong></li>
        <li>Without default language fallback: <strong>@(Model.Value<string>("title", fallback: Fallback.ToDefaultLanguage))</strong></li>
    </ul>
</fieldset>
<fieldset>
    <legend>Blocks</legend>
    <ul>
        <li>Without fallback: <strong>@(Model.Value<BlockListModel>("blocks")?.Count ?? 0) blocks</strong></li>
        <li>Without configured language fallback: <strong>@(Model.Value<BlockListModel>("blocks", fallback: Fallback.ToLanguage)?.Count ?? 0) blocks</strong></li>
        <li>Without default language fallback: <strong>@(Model.Value<BlockListModel>("blocks", fallback: Fallback.ToDefaultLanguage)?.Count ?? 0) blocks</strong></li>
    </ul>
</fieldset>
</body>
</html>

@kjac kjac mentioned this pull request Oct 21, 2025
Closed
AndyButland
AndyButland approved these changes Oct 21, 2025
View reviewed changes
Copy link
Contributor

@AndyButland AndyButland left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All looks good to me and tests out as expected, great work @kjac.

@umbraco umbraco deleted a comment Oct 21, 2025
@AndyButland AndyButland merged commit 58068d1 into release/17.0 Oct 21, 2025
21 of 22 checks passed
@AndyButland AndyButland deleted the v17/bugfix/contextualize-variance-for-language-fallbacks branch October 21, 2025 12:41
@AndyButland AndyButland changed the title Rendering: Expliticly contextualize variation context for language fallback (closes #20350) Rendering: Explicitly contextualize variation context for language fallback (closes #20350) Oct 21, 2025
@AndyButland AndyButland mentioned this pull request Nov 3, 2025
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@AndyButland AndyButland AndyButland approved these changes

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@kjac @AndyButland