Conversation
Appending ?language= changed the segment and period selectors but left the widgets and the reporting menu in the user's stored language, so the interface ended up half translated. Those two regions are not part of the page render: the menu comes from API.getReportPagesMetadata and each widget fetches its own content, both through AjaxHelper. AjaxHelper carries idSite, period, date and segment over to those requests but not language, so they were answered in the stored language while the page around them used the requested one. The selectors looked right only because they translate client-side from the strings the page already shipped. language now travels with the other four. It is only sent when the page asks for one, so the usual path is unchanged, and a request that sets its own language still wins.
tzi
changed the title
tzi
changed the title
tzi
changed the title
…pendent, DEV-14920 The hash-beats-query-string contract and the postParams suppression were both unasserted, and originalHref was captured at collection time, which other tests in this file leave dirty. Also drops the spec comment that restated the one in the source.
…-14920 Both map widgets build their requests with a private $.ajax wrapper rather than going through AjaxHelper, so the previous commit did not reach them. Their shell is translated, but the realtime tooltips render a server-translated referrerTypeName, and the row evolution opened from the visitor map fetches server-rendered HTML. getEnrichedRequest() now copies the language into the params baked into the page, the way it already does for the segment, which covers the realtime report since it spreads those params. The row evolution picks its params out one by one, so it needs the language named explicitly.
chippison
left a comment
chippison
left a comment
There was a problem hiding this comment.
Everything looks good.
This PR does what it says, except in Page Overlay
This will still open an untranslated page because it is javascript that builds the URL for this
Would be good to fix this as well just so this is complete
…updater screens, DEV-14920
…ettings, DEV-14920
Thanks @chippison, good catch! Page Overlay is fixed now. ✅ While checking I found two related gaps and fixed them as well:
|
chippison
left a comment
chippison
left a comment
There was a problem hiding this comment.
The revert in b0bbedbbd1 says the language selector "only reaches the installer and updater screens", but LanguagesManager\Menu::configureTopMenu also adds it to the normal reporting top menu for every anonymous user, so on an install with anonymous view access, someone on a ?language=es link who picks French gets redirected back to a referrer that still pins es, and the dropdown appears to do nothing. This PR makes that more visible rather than less: previously the AJAX-loaded widgets at least followed the newly chosen session language, and now they carry the URL one too, so nothing on the page changes. Could 02fe2bb5fb be restored? The code and its tests already look right to me.
…r anonymous users, DEV-14920
|
You're right @chippison, and my reasoning for the revert was wrong: I traced the selector only through |
2 participants
Description
Appending
?language=esto a reporting URL changed the segment and period selectors, but the widgets and the left reporting menu stayed in the user's own language, so the interface ended up half translated. Sharing a link, or switching language to check a translation, gave a mixed-language page.The whole interface now follows the language the page asks for.
issue dev-14920
Step by step tests
&language=esto the URL.👁️ The left menu, the widget titles and the widget contents are all in Spanish, along with the selectors.
👁️ Everything stays in Spanish. The parameter survives navigation.
&language=es. Hover a country on the real-time map, and open a row evolution from the visitor map.👁️ The tooltips and the row evolution popover are in Spanish too.
&language=esstill in the URL, open a Page Overlay from the Behaviour > Pages report.👁️ The overlay opens in Spanish, sidebar included. (but Heatmap infobox will stay in english since it’s not translated)
&language=esstill in the URL, open the Pages report, click the export icon under the widget, pick CSV and download it.👁️ Two things to look at: the file name, the column headers are Spanish (ex:
Visitas)Export _ Page URLs _ Tuesday, August 4, 2026.csvExportar _ URLs de página _ Martes, 4 de agosto de 2026.csv&language=esstill in the URL, go to Administration > Personal > Settings, pick French as your language and save.👁️ Two things to look at:
&language=esdisappears from the URL bar as soon as the save succeeds, and any reporting page you open next is in French, the language you just saved. Before this change the parameter stayed in the URL and kept overriding the setting, so the next page was Spanish again and the save looked like it had been ignored.anonymoususer view access to a site (Administration > System > Users), log out, open that site's dashboard with&language=es, then pick French in the language selector of the top menu.👁️ Two things to look at:
&language=esis gone from the URL, and the whole page including the widgets is in French. Before this change the redirect kept the parameter, so the page came back in Spanish and the selector looked broken. The selector only shows for anonymous users, which is why this step needs the logout.&language=esand reload.👁️ The whole interface is back in English.
languageparameter at all.👁️ Unchanged from before: your own language, and no
languagein the requests the page makes.Checklist