Uploaded image for project: 'Jira Data Center'
  1. Jira Data Center
  2. JRASERVER-28392

The language translation got mixed up in the dashboard after choosing a default language other than the chosen one from initialization

XMLWordPrintable

      NOTE: This bug report is for JIRA Server. Using JIRA Cloud? See the corresponding bug report.

      Steps to reproduce (Scenario A)

      • Setup a fresh installation of JIRA
      • At the first step of the set up wizard, choose a language pack other than English such as German
      • Finish the setup and create issues
      • Go to the general configuration page and change the default language to English
      • (BUG) The dashboard will still be mixed with both English and German language see screenshot

      How to reproduce (Scenario B)

      • Start JIRA from a clean instance
      • Create two users: One with the default language and one with a different locale than the system default (For example: Japanese or Spanish)
      • Make sure that the system default locale is set to English(UK)
      • Shutdown Jira and Restart
      • Login into jira with the Japanese user
      • Go to the dashboard. Make sure that the assigned to me gadget shows no issues assigned
      • Login again with the default language user
      • (BUG) Go to the dashboard, you will see the "No issues assigned" text in Japanese.

      Workaround

      • Restart JIRA, or in JIRA Administration "Refresh Client Resources" (System> User Interface > Look and Feel) and make sure that the language of the first user to browse the JIRA dashboard gadgets is the same as the system's default language.

      Root Cause Analysis

      This is caused by the way JIRA includes web-resources into the gadget's XML specification.

      Currently, when JIRA is started all gadget specifications available in gadget plugin modules are retrieved, then we proceed to resolve a number of Atlassian specific directives (see https://developer.atlassian.com/display/GADGETS/Using+Substitution+Variables+and+Directives+in+your+Gadget) and then the transformed xml specification is validated and cached for later use.

      At this stage, web resources are included via two of these directives, specifically #requireResource and #includeResources. This happens at GadgetProcessorImpl.processIncludeResources and web resource urls are generated per each included resource. The URl needs to include the locale as part of the resource to fetch, so since this is done at start-up this will be the system default language at that moment.

      This is the wrong time to do this as:

      1. All users will then get the cached transformed copy of the gadget spec xml which will specify inclusion of resources using the default language.
      2. If the language of the first user to request a gadget is not the system default language (used to resolve the urls to the included resources) any call to AJS.getText() or soy's getText function will be done under the current user's language, which will then cause the included resources for the default language to be cached with i18n strings in the wrong language.

      The second problem is more severe as it will affect any part of the UI that makes use of the resources corrupted with the i18n messages in the wrong language.

        1. dashboard.png
          167 kB
          Sultan Maiyaki
        2. jirababel.png
          120 kB
          Marcel R. Ackermann
        3. activitystream.jpg
          11 kB
          Thomas Heidenreich
        4. kiki.txt
          0.0 kB
          Hans Maurer

            [JRASERVER-28392] The language translation got mixed up in the dashboard after choosing a default language other than the chosen one from initialization

            Abdoulaye Kindy Diallo (Inactive) added a comment -

            Latest raised bug here: https://jira.atlassian.com/browse/JRA-42361

            Abdoulaye Kindy Diallo (Inactive) added a comment - Latest raised bug here: https://jira.atlassian.com/browse/JRA-42361

            Dieter Greiner added a comment -

            We had expected this for 6.3.5
            Why was it removed?

            Dieter Greiner added a comment - We had expected this for 6.3.5 Why was it removed?

            Matt Quail (Inactive) added a comment -

            My recollection is this: those mistranslations come from poisoned caches of JS web resources in the webresource manager. They are poisoned because we create highly cacheable urls, and the locale forms part of the url. But when you go fetch a JS web resource, we use the locale of the "current user", not the locale we might be able to see in the URL. This leads to cache poisoning where (say) a user who's locale is "Germany" fetches a resource with "English" in the url. When other "English" people fetch that resource, they are getting the cached "Germany" version.

            In normal use of the web resource system, this poisoning doesn't occur, because we generate urls to resources in an ad-hoc lazy way. When we generate a page for a user, all the urls to JS on that page contain the correct locale, and their browser will fetch them immediately using the same user session hence the same locale.

            However, with gadgets, the urls to JS resources are generated way in advance. And then when the first user comes along, their locale is used to fill the cache for those urls. Every use of AJS.getText() in that JS or getText() in Soy will have the translations for the locale of the first user.

            We are probably seeing this problem occur now because we are using AJS.getText() and Soy more often.

            Matt Quail (Inactive) added a comment - My recollection is this: those mistranslations come from poisoned caches of JS web resources in the webresource manager. They are poisoned because we create highly cacheable urls, and the locale forms part of the url. But when you go fetch a JS web resource, we use the locale of the "current user", not the locale we might be able to see in the URL. This leads to cache poisoning where (say) a user who's locale is "Germany" fetches a resource with "English" in the url. When other "English" people fetch that resource, they are getting the cached "Germany" version. In normal use of the web resource system, this poisoning doesn't occur, because we generate urls to resources in an ad-hoc lazy way. When we generate a page for a user, all the urls to JS on that page contain the correct locale, and their browser will fetch them immediately using the same user session hence the same locale. However, with gadgets, the urls to JS resources are generated way in advance. And then when the first user comes along, their locale is used to fill the cache for those urls. Every use of AJS.getText() in that JS or getText() in Soy will have the translations for the locale of the first user. We are probably seeing this problem occur now because we are using AJS.getText() and Soy more often.

            Luis Miranda (Inactive) added a comment -

            mquail I have a feeling you know what causes this. Can we get a brain dump?

            Luis Miranda (Inactive) added a comment - mquail I have a feeling you know what causes this. Can we get a brain dump?

            Trevor Campbell (Inactive) added a comment -

            My fix was only for the specific filter gadget. There is a more widespread problem that a commonly used method of getting i18n strings, i.e. AJS.I18n.getText("some.i18n.key"), does not work reliably in gadgets, but gets random recently used language. I don't know if that is the actual problem here or not.

            Trevor Campbell (Inactive) added a comment - My fix was only for the specific filter gadget. There is a more widespread problem that a commonly used method of getting i18n strings, i.e. AJS.I18n.getText("some.i18n.key"), does not work reliably in gadgets, but gets random recently used language. I don't know if that is the actual problem here or not.

            Stefan Höhn added a comment -

            Why? You could just DELIVER it that way or what sideeffect would that have if I configured it this way?

            -Duser.language=en -Duser.country=UK

            I have a system which is accessed world-wide using multiple language, ie. it is not only used in english. Can I still configure it like mentioned above or would the other languages not work anymore consistently?

            Stefan Höhn added a comment - Why? You could just DELIVER it that way or what sideeffect would that have if I configured it this way? -Duser.language=en -Duser.country=UK I have a system which is accessed world-wide using multiple language, ie. it is not only used in english. Can I still configure it like mentioned above or would the other languages not work anymore consistently?

            Eric Dalgliesh added a comment -

            shoehn2, that would require JIRA to trigger a restart of itself, which is not a problem that we've solved yet.

            Eric Dalgliesh added a comment - shoehn2 , that would require JIRA to trigger a restart of itself, which is not a problem that we've solved yet.

            Stefan Höhn added a comment -

            If that solves the problem, why isn't Jira delivered that way in its startup scripts?

            Stefan Höhn added a comment - If that solves the problem, why isn't Jira delivered that way in its startup scripts?

            Dave C added a comment -

            We have a KB on a similar behaviour that may address this problem - please take a look through JIRA Displays a Mixture of Different Languages for further information.

            Dave C added a comment - We have a KB on a similar behaviour that may address this problem - please take a look through JIRA Displays a Mixture of Different Languages for further information.

            Stefan Höhn added a comment -

            Can you please fix the bugs in the JIRA before you implement new features, thanks.

            Stefan Höhn added a comment - Can you please fix the bugs in the JIRA before you implement new features, thanks.

              pbugalski Pawel Bugalski (Inactive)
              smaiyaki Sultan Maiyaki (Inactive)
              Affected customers:
              14 This affects my team
              Watchers:
              35 Start watching this issue

                Created:
                Updated:
                Resolved: