Skip to content

Conversation

fsbraun
Copy link
Member

@fsbraun fsbraun commented Jul 26, 2025

Description

When adding or editing a plugin, the plugin fields are in the language of the plugin (not the admin language). This also needs to hold for the internal links. This PR adjusts the language of the internal link dropdown. (The dropdown still uses fallback languages if necessary and available.)

Additionally, the link to internal pages shown in the structure board now reflects the language that is edited (i.e., show /it/pagina/ instead of /en/page/ as a short description in the structure board when editing Italian content).

Dutch, German and French locales are updated.

Fixes #249

Tests are to be added.

@krosefield Please be invited to test.

Related resources

Checklist

  • I have opened this pull request against master
  • I have added or modified the tests when changing logic
  • I have followed the conventional commits guidelines to add meaningful information into the changelog
  • I have read the contribution guidelines and I have joined #workgroup-pr-review on
    Slack to find a “pr review buddy” who is going to review my pull request.

Copy link
Contributor

sourcery-ai bot commented Jul 26, 2025

Reviewer's Guide

Adds language awareness to internal link widgets by passing the plugin’s language through widget initialization, URL generation, form fields, and plugin form rendering.

Sequence diagram for plugin form rendering with language-aware internal links

sequenceDiagram
    participant Admin as actor Admin User
    participant PluginAdmin as PluginAdmin
    participant PluginForm as PluginForm
    participant LinkWidget as LinkWidget
    participant InternalLinkWidget as LinkAutoCompleteWidget

    Admin->>PluginAdmin: Open plugin add/edit form
    PluginAdmin->>PluginForm: get_form(request, obj)
    PluginForm->>LinkWidget: Initialize with language=plugin.language
    LinkWidget->>InternalLinkWidget: Set language attribute
    InternalLinkWidget->>InternalLinkWidget: get_url() includes ?language=plugin.language
    PluginForm-->>PluginAdmin: Return form with language-aware widgets
    PluginAdmin-->>Admin: Render form with internal links in plugin language
Loading

Class diagram for language-aware LinkWidget and related classes

classDiagram
    class LinkAutoCompleteWidget {
        +language: str | None
        +get_url()
    }
    class LinkWidget {
        +language: str | None
        +__init__(site_selector: bool | None, language: str | None)
    }
    class LinkFormField {
        +widget: LinkWidget
        +__init__(..., language: str | None)
    }
    class LinkField {
        +formfield(...)
    }
    LinkWidget --> LinkAutoCompleteWidget : uses
    LinkFormField --> LinkWidget : has
    LinkField --> LinkFormField : formfield()
Loading

File-Level Changes

Change Details Files
Add language parameter and query support to internal link autocomplete widget
  • Extend LinkAutoCompleteWidget.init to accept and store an optional language
  • Modify get_url to append ?language= when provided
djangocms_link/fields.py
Propagate language into LinkWidget and adjust site selector logic
  • Update LinkWidget.init signature to accept language
  • Assign language to internal link widget before optional site selector insertion
  • Conditionally insert site selector only if site_selector is true
djangocms_link/fields.py
Instantiate LinkFormField with language-aware widget
  • Remove class-level widget attribute from LinkFormField
  • In init, pop language from kwargs and set self.widget to LinkWidget(language=...)
djangocms_link/fields.py
Override plugin form to assign language to link widgets
  • Add get_form override in LinkPlugin
  • Determine plugin language from obj or request
  • Loop through widget.widgets and set each widget.language accordingly
djangocms_link/cms_plugins.py

Assessment against linked issues

Issue Objective Addressed Explanation
#249 Display the list of target page titles in the internal link dropdown according to the language of the page being edited, not the user's language setting.

Possibly linked issues


Tips and commands

Interacting with Sourcery

  • Trigger a new review: Comment @sourcery-ai review on the pull request.
  • Continue discussions: Reply directly to Sourcery's review comments.
  • Generate a GitHub issue from a review comment: Ask Sourcery to create an
    issue from a review comment by replying to it. You can also reply to a
    review comment with @sourcery-ai issue to create an issue from it.
  • Generate a pull request title: Write @sourcery-ai anywhere in the pull
    request title to generate a title at any time. You can also comment
    @sourcery-ai title on the pull request to (re-)generate the title at any time.
  • Generate a pull request summary: Write @sourcery-ai summary anywhere in
    the pull request body to generate a PR summary at any time exactly where you
    want it. You can also comment @sourcery-ai summary on the pull request to
    (re-)generate the summary at any time.
  • Generate reviewer's guide: Comment @sourcery-ai guide on the pull
    request to (re-)generate the reviewer's guide at any time.
  • Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
    pull request to resolve all Sourcery comments. Useful if you've already
    addressed all the comments and don't want to see them anymore.
  • Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
    request to dismiss all existing Sourcery reviews. Especially useful if you
    want to start fresh with a new review - don't forget to comment
    @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

  • Enable or disable review features such as the Sourcery-generated pull request
    summary, the reviewer's guide, and others.
  • Change the review language.
  • Add, remove or edit custom review instructions.
  • Adjust other review settings.

Getting Help

Copy link
Contributor

@sourcery-ai sourcery-ai bot left a comment

Choose a reason for hiding this comment

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

Hey @fsbraun - I've reviewed your changes and they look great!

Prompt for AI Agents
Please address the comments from this code review:
## Individual Comments

### Comment 1
<location> `djangocms_link/cms_plugins.py:63` </location>
<code_context>
+            language = getattr(obj, "language", None)
+        else:
+            language = request.GET.get("plugin_language", None)
+        for widget in self.fields["link"].widget.widgets:
+            widget.language = language
+        return form
</code_context>

<issue_to_address>
Directly mutating widget.language may cause issues if widgets are shared across forms.

Mutating shared widget instances can cause side effects. Ensure each form uses unique widget instances or clone them before modifying the language attribute.
</issue_to_address>

### Comment 2
<location> `djangocms_link/fields.py:375` </location>
<code_context>
         super().__init__(*args, **kwargs)

     def formfield(self, **kwargs):
+        print("LinkField.formfield", kwargs)
         kwargs.setdefault("form_class", LinkFormField)
         return super().formfield(**kwargs)
</code_context>

<issue_to_address>
Debug print statement left in production code.

Please remove this print statement before merging to avoid unnecessary console output and potential information exposure.
</issue_to_address>

### Comment 3
<location> `djangocms_link/fields.py:255` </location>
<code_context>
-                    },
-                ),
-            )  # Site selector
+            widgets[index].language = language  # Pass on language to the internal link widget
+            if site_selector:
+                widgets.insert(
</code_context>

<issue_to_address>
Assigning language directly to widget may not propagate as expected if widgets are reused.

Directly setting the language on shared widget instances can lead to side effects. Ensure each form uses unique widget instances or use a safer way to handle language context.
</issue_to_address>

### Comment 4
<location> `djangocms_link/fields.py:310` </location>
<code_context>
         kwargs.setdefault("initial", {})
         kwargs.pop("encoder", None)  # Passed from LinkField's JSONField parent class
         kwargs.pop("decoder", None)  # but not needed
+        self.widget = LinkWidget(language=kwargs.pop("language", None))
         super().__init__(*args, **kwargs)
         if isinstance(self.initial, dict):
</code_context>

<issue_to_address>
Overriding self.widget in __init__ may break expected widget customization via kwargs.

Setting self.widget here ignores any widget provided in kwargs. To preserve customization, check for a widget in kwargs before assigning a default.
</issue_to_address>

Sourcery is free for open source - if you like our reviews please consider sharing them ✨
Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.

Copy link

codecov bot commented Jul 26, 2025

Codecov Report

❌ Patch coverage is 90.56604% with 5 lines in your changes missing coverage. Please review.
✅ Project coverage is 95.91%. Comparing base (1586b8a) to head (6927e74).

Files with missing lines Patch % Lines
djangocms_link/admin.py 72.72% 1 Missing and 2 partials ⚠️
djangocms_link/fields.py 92.00% 0 Missing and 2 partials ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##           master     #250      +/-   ##
==========================================
- Coverage   96.31%   95.91%   -0.40%     
==========================================
  Files          28       28              
  Lines         706      735      +29     
  Branches       98      104       +6     
==========================================
+ Hits          680      705      +25     
- Misses          9       10       +1     
- Partials       17       20       +3     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@krosefield
Copy link

Thank you, Fabian!

We've tested it and it looks great!

Adding a link on a German page:
Bildschirmfoto 2025-07-28 um 12 08 44
=> Page titles are displayed in German! ✅

Adding a Link to a French page:
Bildschirmfoto 2025-07-28 um 12 07 48
=> Page titles are displayed in French! ✅

One thing that we've noticed:
When a page is not available in the same language as the page on which you are placing the link, the page title is left blank. You can see this in the 2nd screenshot where the page "Nur in Deutsch" (s. 1st screenshot) would have been.
A suggested behavior could be to display the page title in italics like it is handled in the administration view of the page tree:

Bildschirmfoto 2025-07-29 um 14 27 03

@fsbraun
Copy link
Member Author

fsbraun commented Jul 29, 2025

@krosefield Fallback languages still active? If no, the gap probably should go away. If yes, the fallback title should be shown.

@krosefield
Copy link

I'm sorry for the delay!
We've tested the latest branch.

Test-setup:

A website with three languages (de/en/fr).

Fallback language is active and set to English.

I've created three pages that are only available in de, en or fr:
Bildschirmfoto 2025-09-02 um 10 05 57
Bildschirmfoto 2025-09-02 um 10 06 06
Bildschirmfoto 2025-09-02 um 10 06 17

Creating a link on a German webpage, I see the following pages in the page tree selector:
Bildschirmfoto 2025-09-02 um 10 07 27
Result: Only the English page is shown in the page tree selector.
Expected behavior: German and English pages are shown.

Creating a link on a English webpage, I see the following pages:
Bildschirmfoto 2025-09-02 um 10 08 20
Result: Only the English page is shown in the page tree selector.
Expected behavior: as the result above

Creating a link on a French webpage, I see the following pages:
Bildschirmfoto 2025-09-02 um 10 09 17
Result: Only the English page is shown in the page tree selector.
Expected behavior: French and English pages are shown.

When it comes to a page that is actually available in different languages, everything works fine:

  • If the target page is available in the same language as the page on which the links is being placed (the "source page"), the target page is listed in the source page language within the page tree selector. Example: I create a link on a German page and see the German name of the target page.
  • If the target page of the link is not available in the same language as source page but in the fallback language, the target page is listed in the fallback language within the page tree selector. Example: I create a link on a French page and see the English name of the target page (with "English" configured as the fallback language).

I hope this is understandable... and somehow some helpful information . :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

feat: Adjust language of drop down content to the language of the object edited
2 participants