Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-39345

Use js-modules to coordinate async loading of i18n translation bundles as part of dependant JavaScript bundle

    XMLWordPrintable

    Details

    • Epic Link:
    • Sprint:
      indian, arctic, tasman, pannonian
    • Similar Issues:

      Description

      A.K.A "translation keys instead of content keep showing up and flashing to the localised version on first load"

      Use new/extended js-modules/js-builder API delivered as part of JENKINS-39322 to automatically coordinate the async loading of i18n translations as part of the loading of a blueocean bundle that depends on the translation.

      This will allow synchronous access to the translations at runtime (because we can guarantee that they are already loaded in the browser), which in turn allows a much nicer programming model around i18n, removing the need to tie translation resource loading into react lifecycle etc (i.e. no need for e.g. react-i18next shim for react components - would need something else for non react components).

      Assigned to Tom FENNELLY for now, but should be doable by anyone if we get JENKINS-39322 right.

        Attachments

          Issue Links

            Activity

            Hide
            imeredith Ivan Meredith added a comment -

            You can see this issue in action if you set your browser to german default, then go to ci.blueocean.io/blue . The Dashboard label first shows as English then switches to german.

            Show
            imeredith Ivan Meredith added a comment - You can see this issue in action if you set your browser to german default, then go to ci.blueocean.io/blue . The Dashboard label first shows as English then switches to german.
            Hide
            jamesdumay James Dumay added a comment -

            OK good stuff. I've added this to the release-candidate queue but we need to get to some other things first. Will re-review on monday.

            Show
            jamesdumay James Dumay added a comment - OK good stuff. I've added this to the release-candidate queue but we need to get to some other things first. Will re-review on monday.
            Hide
            michaelneale Michael Neale added a comment -

            I think we should bring this forward, Tom FENNELLY is right, this one will bite (cliff is seeing it with creation flow).

            Tom - how "destructive" will these changes be? hard to say?

            Show
            michaelneale Michael Neale added a comment - I think we should bring this forward, Tom FENNELLY is right, this one will bite (cliff is seeing it with creation flow). Tom - how "destructive" will these changes be? hard to say?
            Hide
            jamesdumay James Dumay added a comment -

            ... and is there any way for us to try it before committing to master?

            Show
            jamesdumay James Dumay added a comment - ... and is there any way for us to try it before committing to master?
            Hide
            tfennelly Tom FENNELLY added a comment -

            I think we should bring this forward

            It was puzzling me how making the "Quick Language Switcher" work could have been higher priority than getting BO itself to switch language properly. So yes, bringing this forward seems consistent to me

            Tom - how "destructive" will these changes be? hard to say?

            Hmmm ... atm I don't think it will be destructive. I would expect/hope the component JavaScript code to not change at all. The plugins might have to "declare" their i18n bundles e.g. in the same yaml file as they declare Extension Points. We (the build) could auto-detect the default bundle, which atm is all any of the core BO plugins are using afaik.

            The bigger changes would be in js-modules and js-builder, building in generic hooks (so we can potentially do this for other "stuff" e.g. Keith Zantow did some work for extension decorators that would be able to use something like this too) to allow us hook into the bundle loading process i.e. to allow us inject resource loading "functions" that return a Promise that needs to be fullfilled along with the normal javascript loading stuff before the bundle can start executing.

            After that, we wire the above into blue ocean's plugin for js-builder and get it to inject resource loading for i18n resources. That resource loading would load i18next with the resource bundle it's told to load (declared by the plugin - detected by js-builder plugin etc) and would only resolve its promise once that's done, blocking the dependant/owner javascript bundle from executing.

            I'm sure there'll be kinks that need working out, but that's the general idea.

            Show
            tfennelly Tom FENNELLY added a comment - I think we should bring this forward It was puzzling me how making the "Quick Language Switcher" work could have been higher priority than getting BO itself to switch language properly. So yes, bringing this forward seems consistent to me Tom - how "destructive" will these changes be? hard to say? Hmmm ... atm I don't think it will be destructive. I would expect/hope the component JavaScript code to not change at all. The plugins might have to "declare" their i18n bundles e.g. in the same yaml file as they declare Extension Points. We (the build) could auto-detect the default bundle, which atm is all any of the core BO plugins are using afaik. The bigger changes would be in js-modules and js-builder, building in generic hooks (so we can potentially do this for other "stuff" e.g. Keith Zantow did some work for extension decorators that would be able to use something like this too) to allow us hook into the bundle loading process i.e. to allow us inject resource loading "functions" that return a Promise that needs to be fullfilled along with the normal javascript loading stuff before the bundle can start executing. After that, we wire the above into blue ocean's plugin for js-builder and get it to inject resource loading for i18n resources. That resource loading would load i18next with the resource bundle it's told to load (declared by the plugin - detected by js-builder plugin etc) and would only resolve its promise once that's done, blocking the dependant/owner javascript bundle from executing. I'm sure there'll be kinks that need working out, but that's the general idea.

              People

              • Assignee:
                tfennelly Tom FENNELLY
                Reporter:
                tfennelly Tom FENNELLY
              • Votes:
                0 Vote for this issue
                Watchers:
                5 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: