# Problem/Motivation The dialog content is loaded as an HTMX fragment from /language-switcher-dialog/content. Every content provider builds its language switch URLs from the current route, but during that fragment request the current route is the endpoint itself, and nothing tells the endpoint which page the visitor is actually on. Verified on a clean Drupal 11.4 install with three languages, requesting the fragment the way HTMX does: curl -H "HX-Request: true" https://example.com/language-switcher-dialog/content - core_language_block: every link is /<langcode>/language-switcher-dialog/content. In a browser the ajax_page_state parameters are appended as well, because core's LanguageNegotiationUrl::getLanguageSwitchLinks() copies the request query onto the links. Following one lands on a broken page. - enhanced_links: identical, it uses the same Url::fromRouteMatch() call. - grouped_by_region: every link is the front page in the target language. This provider already reads a `destination` query parameter and falls back to Url::fromRoute('<front>') when none arrives; nothing ever sends one, so the fallback is what every visitor gets. So on a default install the switcher cannot take a visitor to the translation of the page they are on. Two of the three providers link to the AJAX endpoint, and the third silently sends everyone to the front page. The GeoIP submodule already solves exactly this: its trigger sends a destination through hx-vals and its controller builds the URL from it. The trigger dialog never got the same treatment, and RegionGroupedProvider::buildLanguageSwitchUrl() is written for a caller that does not exist. # Steps to reproduce 1. Install with two or more languages and place the Language Switcher Dialog block. 2. Visit any page other than the front page. 3. Open the dialog and hover over a language link. 4. With core_language_block or enhanced_links the link points at /<langcode>/language-switcher-dialog/content; with grouped_by_region it points at the front page. # Proposed resolution 1. Send the destination from the block, mirroring what the GeoIP hook already does: 'data-hx-vals' => 'js:{"destination": window.location.pathname + window.location.search}' 2. Add a shared helper to DialogContentProviderBase that turns the destination into a Url and falls back to <front> when it is missing or unusable. Url::fromUserInput() rejects anything not starting with /, ? or #, so the helper must catch \InvalidArgumentException: otherwise a crafted destination is an uncaught exception and a 500, which is the same trap fixed in #3610918. 3. Use that helper in CoreLanguageBlockProvider and EnhancedLinksProvider in place of Url::fromRouteMatch(). RegionGroupedProvider's existing destination branch then starts doing what it was written to do. 4. Add url.query_args to RegionGroupedProvider's cache contexts. It currently varies only by languages:language_interface and url.path, so once it uses the destination its output would be cached across different pages. The other two providers already declare it. No special handling is needed for a destination that is just a query string: Url::fromUserInput('/?utm_source=x') resolves to the <front> route and keeps the query. Because #3610918 already landed the query string handling, pagination, filters and campaign parameters survive the switch for free once a destination is actually sent. # Remaining tasks - Review and test. # User interface changes Switching language keeps the visitor on the page they were reading, instead of sending them to the AJAX endpoint or the front page. # API changes A protected helper is added to DialogContentProviderBase. Custom providers can use it but are not required to. # Data model changes None.