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

i18n does not changes language in Blueocean when using the Quick Language Switcher for Chrome

    Details

    • Epic Link:
    • Sprint:
      tethys
    • Similar Issues:

      Description

      The language does change when you change the language setting in Chrome's Settings (chrome://settings/ -> Advanced Settings / Languages). The problem seems to be specific to the Quick Language Switcher for Chrome and maybe other such plugins.

      Reproduce the problem:

      Spanish translation is done in BlueOcean, so it should display BlueOcean pages in Spanish.

        Attachments

          Issue Links

            Activity

            Hide
            mudak Jean-Philippe Briend added a comment -

            I did some further investigations.

            W3C states content should be delivered according to the 'accept-language' HTTP header (the Quick Language Switcher is doing this).

            Jenkins 'old' UI follows the old pattern server-client requests. Thus language is detected via the headers.
            However with React, it is detected from the browser. Thus the code may not have easily access to this HTTP header.
            The code is looking at the browser's locale:

            exports.default = {
              name: 'navigator',
            
              lookup: function lookup(options) {
                var found = [];
            
                if (typeof navigator !== 'undefined') {
                  if (navigator.languages) {
                    // chrome only; not an array, so can't use .push.apply instead of iterating
                    for (var i = 0; i < navigator.languages.length; i++) {
                      found.push(navigator.languages[i]);
                    }
                  }
                  if (navigator.userLanguage) {
                    found.push(navigator.userLanguage);
                  }
                  if (navigator.language) {
                    found.push(navigator.language);
                  }
                }
            
                return found.length > 0 ? found : undefined;
              }
            };
            

            Some additional explanations can be found here (especially difference between server and browser locale detection).

            The current implementation seems to be correct for the current usage until somebody will its OS language different from its browser's language (check previous link for explanation).

            The only solution I see would be to handle the language detection from the server and send this information back to the React code.

            Tom FENNELLY With this additional data, maybe this issue is not a bug but an enhancement to have a better behaviour. WDYT ? It could be merged in the story that will implement language selection ?

            Show
            mudak Jean-Philippe Briend added a comment - I did some further investigations. W3C states content should be delivered according to the 'accept-language' HTTP header (the Quick Language Switcher is doing this). Jenkins 'old' UI follows the old pattern server-client requests. Thus language is detected via the headers. However with React, it is detected from the browser. Thus the code may not have easily access to this HTTP header. The code is looking at the browser's locale: exports. default = { name: 'navigator' , lookup: function lookup(options) { var found = []; if (typeof navigator !== 'undefined' ) { if (navigator.languages) { // chrome only; not an array, so can't use .push.apply instead of iterating for ( var i = 0; i < navigator.languages.length; i++) { found.push(navigator.languages[i]); } } if (navigator.userLanguage) { found.push(navigator.userLanguage); } if (navigator.language) { found.push(navigator.language); } } return found.length > 0 ? found : undefined; } }; Some additional explanations can be found here (especially difference between server and browser locale detection). The current implementation seems to be correct for the current usage until somebody will its OS language different from its browser's language (check previous link for explanation). The only solution I see would be to handle the language detection from the server and send this information back to the React code. Tom FENNELLY With this additional data, maybe this issue is not a bug but an enhancement to have a better behaviour. WDYT ? It could be merged in the story that will implement language selection ?
            Hide
            tfennelly Tom FENNELLY added a comment -

            Hi Jean-Philippe Briend. Yeah, sounds like Quick Language Switcher just can't work with the client-side approach that's there atm. It's not really anything to do with React btw, but that's secondary.

            Maybe we should also be setting the locale in the page skeleton returned on page load and have i18Next detect that before doing its thing. You're saying something along those lines too I think.

            Show
            tfennelly Tom FENNELLY added a comment - Hi Jean-Philippe Briend . Yeah, sounds like Quick Language Switcher just can't work with the client-side approach that's there atm. It's not really anything to do with React btw, but that's secondary. Maybe we should also be setting the locale in the page skeleton returned on page load and have i18Next detect that before doing its thing. You're saying something along those lines too I think.
            Show
            tfennelly Tom FENNELLY added a comment - PR: https://github.com/jenkinsci/blueocean-plugin/pull/714
            Hide
            tfennelly Tom FENNELLY added a comment -

            Fyi ... switching language is a bit glitchy atm because if the async nature of how translations are loaded and the difficulties of refreshing all components in a clean way once that happens. See JENKINS-39345.

            Show
            tfennelly Tom FENNELLY added a comment - Fyi ... switching language is a bit glitchy atm because if the async nature of how translations are loaded and the difficulties of refreshing all components in a clean way once that happens. See JENKINS-39345 .

              People

              • Assignee:
                tfennelly Tom FENNELLY
                Reporter:
                mudak Jean-Philippe Briend
              • Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: