Description of problem: [ALL LANG] Unexpected code and Unlocalized strings in the pop-up error messages box when registering system with 'Connect this system to Red Hat Insights'. Version-Release number of selected component (if applicable): subscription-manager-1.29.30-1.el9.x86_64 subscription-manager-cockpit-4-1.el9.noarch How reproducible: 100% Steps to Reproduce: 1. Open RHSM Cockpit Client via click Applications - System Tools - Red Hat Subscription Manager on the top menu bar from desktop or type subscription in the search field and press the Enter key. 2. Click Register button in Subscriptions dialog box. 3. Select Custom URL and input the correct URL. 4. Input the correct Username and Password. 5. Select the 'Connect this system to Red Hat Insights' checkbox. 6. Click Register button. Actual results: [ALL LANG] Unexpected code and Unlocalized strings in the pop-up error messages box when registering system with 'Connect this system to Red Hat Insights'. Expected results: 1. No such debug info and code in the error message box. 2. The strings should be localized in the error message box. Additional info: Please see the attached screen-shot.
Hmm this is the stdout/stderr of the `insights-client` command, so we simply show what is printed. Maybe running `insights-client` with a different language will give some of the messages as translated. Can you please run `insights-client` from a terminal (i.e. outside of cockpit) where the language is different than English? (check the output of `localectl`)
Link Dupont (developer of insights-client) told me that insights-client does not support localization so far. Hence, reassigning this to that component, as there is nothing the cockpit plugin of subscription-manager can do about this. Please note that the HTML code shown in the error message is simply the answer from the server, and that cannot be localized in any way.
Reproduced on latest RHEL9.2 build also.
Unlocalized message: insights-client exited with code 1
(In reply to Lijun Li from comment #4) > Reproduced on latest RHEL9.2 build also. Note that this does not need to be periodically rested: the issue here is not something more or less easily fixable, it's a structural lack of i18n in insights-client, so it will require a considerable amount of effort to be done.
(In reply to Pino Toscano from comment #6) > (In reply to Lijun Li from comment #4) > > Reproduced on latest RHEL9.2 build also. > > Note that this does not need to be periodically rested: the issue here is > not something more or less easily fixable, it's a structural lack of i18n in > insights-client, so it will require a considerable amount of effort to be > done. Sure, thanks for the info.
The risk is that if "insights-client" is not i18n'ed properly, this issue might be reported again and again. At least the result of this bug should be a ticket to get "insights-client" localized....
(In reply to Ludek Janda from comment #8) > The risk is that if "insights-client" is not i18n'ed properly, this issue > might be reported again and again. At least the result of this bug should be > a ticket to get "insights-client" localized.... Let me clarify what I said earlier: it was not meant to dismiss the work/testing, but rather point out this is not a trivial change that will happen overnight or with a 5-lines patch; because of that, it needs to scheduled, have a design on how to plug i18n in the existing architecture, be actually implemented and tested. As such, if there are updates, then definitely anything will be shared here, in terms of links to upstream changes, documents, and even calls for translations. Hence, a periodic retest on this bug, in the lack of updates, if very likely to give the same results again and again, i.e. that insights-client is not i18n'ed.
(In reply to Pino Toscano from comment #9) > (In reply to Ludek Janda from comment #8) > > The risk is that if "insights-client" is not i18n'ed properly, this issue > > might be reported again and again. At least the result of this bug should be > > a ticket to get "insights-client" localized.... > > Let me clarify what I said earlier: it was not meant to dismiss the > work/testing, but rather point out this is not a trivial change that will > happen overnight or with a 5-lines patch; because of that, it needs to > scheduled, have a design on how to plug i18n in the existing architecture, > be actually implemented and tested. As such, if there are updates, then > definitely anything will be shared here, in terms of links to upstream > changes, documents, and even calls for translations. > > Hence, a periodic retest on this bug, in the lack of updates, if very likely > to give the same results again and again, i.e. that insights-client is not > i18n'ed. No worries, I understand the complexity. However I think there should be a clear requirement for the authors of "insights-client" to get their component i18n'ed properly. Subscription manager is i18n'ed and if they want to integrate with it, this component should be i18n'ed too IMO.
Oh sorry, Pino. I can see that this ticket is already an RFE. Then it is okay.