| Summary: | RFE: Make udpater notifier for Windows localizable by design | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | jiri vanek <jvanek> |
| Component: | java-1.8.0-openjdk | Assignee: | Alex Kashchenko <akashche> |
| Status: | CLOSED WONTFIX | QA Contact: | zzambers |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 7.4 | CC: | akashche, dbhole, jvanek |
| Target Milestone: | rc | Keywords: | FutureFeature, Reopened |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Windows | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2021-01-15 07:28:53 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
(In reply to jiri vanek from comment #0) > - no localization by design possible That is also currently true for the whole MSI. I'd rather not try to add ad-hoc hooks for possible subsequent localization (how probable is it?) until the general requirements for such localization will be clear. > Also the versio should be parameter to each string. Not copypasted. It will be build-time (generation-time) parameter. The msi have (at least I have (literally) faith to it) possibility to become localized. This tool do not have. But your point is valid. It have no reason to localize update_check before MSI. But vice versa will be necessary. And the bug is about principle. Having this message in json file... I killing nay localizations evenbefore it starts. If MSI cant have localization, this bug canbe closses ad nto a bug. MSI framework itself has facilities for localization - https://msdn.microsoft.com/en-us/library/windows/desktop/aa369769%28v=vs.85%29.aspx , but current build process doesn't use these features. We need to have at least some business requirements about localized builds to even start discussing possible approaches to localization. I agree on this. Still the utility should be prepared for this time to come. Form the updater bugs, this one is definitely the last to fix anyway... Citing Deepak's email: On 12/01/2016 10:21 PM, Deepak Bhole wrote: > We do not have any localization requirements tbh, but if it is possible > to keep the door open from the start (while only supporting en_US), I > think that would be best. The "door is open" for build-time localization (separate localized binaries, similar to these ones - https://www.mozilla.org/en-US/firefox/all/ ), run-time localization currently doesn't seem feasible. (In reply to Alex Kashchenko from comment #6) > Citing Deepak's email: > > On 12/01/2016 10:21 PM, Deepak Bhole wrote: > > We do not have any localization requirements tbh, but if it is possible > > to keep the door open from the start (while only supporting en_US), I > > think that would be best. > > The "door is open" for build-time localization (separate localized binaries, > similar to these ones - https://www.mozilla.org/en-US/firefox/all/ ), > run-time localization currently doesn't seem feasible. Thats pretty bad idea, isnt it? Localization usually works like one binary + localized messages. Then locale is then identified on user's machine, and set accordingly. Firefox is bad example - as it do not behave like this. I can set locale as I wish, and firefox will localize correctly. So the doors are clsoed. Maybe you can do the updater properly? Heaving the messages in application. and suing en-us as Deepak himself is suggesting? (In reply to jiri vanek from comment #8) Sorry, I am not ready to continue this discussion given the following: On 12/01/2016 10:21 PM, Deepak Bhole wrote: > We do not have any localization requirements This issue is "wontfix" until some requirements will appear. (In reply to Alex Kashchenko from comment #9) > (In reply to jiri vanek from comment #8) > > Sorry, I am not ready to continue this discussion given the following: > > On 12/01/2016 10:21 PM, Deepak Bhole wrote: > > We do not have any localization requirements > Yeah that's fair. It wasn't part of our requirements so blocking release over it is not worthwhile. > This issue is "wontfix" until some requirements will appear. If you meant closing this as WONTFIX, I am opposed to that. Rather, we should treat this as a feature request for the new iteration. Please leave it open, but I think it is a wrong idea to discuss localization as a "bug for current release", so I don't want to answer directly to Jiri's technical questions until some requirements will appear. I have updated the summary. Since we do not have version tagging yet (discussing this with bz admins now), we'll leave this as is for the time being, with changed summary. This request was revoked by development with excuse "no will to make it properly, so lets break it in feature and do it second time" Please once this happen, try to leave your QE out of loop. After evaluating this issue, there are no plans to address it further or fix it in an upcoming release. Therefore, it is being closed. If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened. |
The text, as shown to user in balloon popup or in sequential window is send by version.json: ... "ui_balloon_text": "OpenJDK version 1.8.0.111-2.b15 is available for download.", "ui_update_header": "OpenJDK version 1.8.0.111-2.b15 is available for download", "ui_update_text": "This version contains a number of security fixes.\n\nTo proceed with download and installation please follow a link above, download page will be opened inside your web-browser.\n\nTo change a schedule of this notification please see 'RedHat_jdk_update_checker' and 'RedHat_jdk_update_notifier' tasks in 'Task Scheduler'.\n\nTo disable this notification permanently please select the installed application in 'Programs and Features' with a right-click, choose 'Change' and disable 'Update Notifier' installation feature." However useful this is (to have the ui messgae controlled by every release), this approach have several disadvantages - no doc review - no localization - no localization by design possible (include localizations into this json file may be even more tryfying) ... and it is the only real customer facing part... Also the versio should be parameter to each string. Not copypasted.