Context xwiki-l10n, the RequireJS loader plugin registered by the localization webjar, resolves one query per dependent module: its load() implementation in l10n.ts calls resolver.resolve(query), and initialize only chains translators. Neither batches. Each xwiki-l10n!<keys module> dependency on a page therefore issues its own GET on /rest/wikis/<wiki>/localization/translations. Actual A standard page view already triggers several independent requests, one per consumer, for instance:
- search-suggest-messages, from searchSuggest.js
- xwiki-lightbox-messages, from lightbox.js
- xwiki-job-messages, from job.js, on the pages that load it
Every piece of front-end code that drops its Velocity-generated translations in favour of xwiki-l10n, which is the recommended direction, adds one more request. Expected The queries issued during the same tick are coalesced into a single request, so that the number of localization requests per page view does not grow with the number of front-end components. Suggested fix Batch in the resolver returned by initialize, or in the xwiki-l10n plugin itself: collect the queries of a microtask or of a short window, send the union of their keys in one REST call, then dispatch the result back to each caller. The REST resource already accepts several keys per request, and the plugin already removes the query prefix and keeps only the keys it asked for, so most of the dispatch logic is in place. Note that this also shortens the path to the first registration of anything that needs a translation before it can initialise. Related: XWIKI-24851, which moves a Flamingo skin script to xwiki-l10n and so adds one such request. |
