Bug 703908 - Dashboard portlet names don't change locales
Dashboard portlet names don't change locales
Status: NEW
Product: RHQ Project
Classification: Other
Component: Core UI (Show other bugs)
All All
low Severity low (vote)
: ---
: ---
Assigned To: RHQ Project Maintainer
Mike Foley
Depends On:
  Show dependency treegraph
Reported: 2011-05-11 12:02 EDT by Mike Foley
Modified: 2011-10-07 15:11 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
dashboard portlet still showing japanese locale (9.15 KB, image/png)
2011-05-11 12:02 EDT, Mike Foley
no flags Details

  None (edit)
Description Mike Foley 2011-05-11 12:02:02 EDT
Created attachment 498327 [details]
dashboard portlet still showing japanese locale

Description of problem:
Dashboard portlet names don't change locales

Version-Release number of selected component (if applicable):
RHQ 4.0

How reproducible:

Deleting the Dashboard will bring a new clean one in the current language back,
but this is perhaps no option for those multilanguage users.

Steps to Reproduce:
1.  Use RHQ in Japanese locale
2.  Then use RHQ in German locale
Actual results:
Dashboard portlet names do now switch locales

Expected results:
Dashboard portlet names do switch locales.

Is RHQ persisting the portlets using their display name, rather than their locator/view name?

Additional info:
Comment 1 Jay Shaughnessy 2011-05-16 15:30:44 EDT
This may not be behavior we need to change.  Currently we store the names of global Dashboards and Portlets.  The default dashboard is set to the current locale's string for 'Default'.  Custom dashboards are set to the locale's string for 'Custom #' (where # is an incrementing number).

The global dashboard names are editable, and so presumably the value in there is the default value or the user has set it to.  Either way it can be edited and so the value should not be reset on locale change.  Note that deleting all of your global dashboards will result in a new default global dash, again using the default locale for the initial name.

The names of portlets are similarly set to the current locale's string for the specific portlet.  These names can not currently be edited, although it's conceivable that they could be edited in the future. In that case we would want to leave as is, for the same reason as the dashboard names.

But today it's true, these names are stored with the create-time locale and can not be edited. And this results in the reported behavior.

It's not clear to me how often this situation would occur but I could imagine maybe users in different locales both logging in as a common user (say, rhqadmin) and maybe being confused by this. It seems unlikely.

Also, portlets can be easily deleted and added (as can entire dashboards).  Newly added dashboard and portlets would get the current locale's name (note - any custom config would be lost).  Lastly, group and resource dashboards/ and portlets are not persisted unless customized. So, in general users would see the current locale.

So, I don't see dashboard names as getting any behavioral change.  For portlets I think we'd have to be convinced.  If we envision them being editable in the future, or if we think the scenario here is unlikely, or if we think delete/add is a reasonable workaround, then leave as is.  If we think this is a reasonable scenario then we should stop persisting the (or just ignore the persisted) portlet name, and always display the current locale.
Comment 2 Heiko W. Rupp 2011-05-18 03:00:01 EDT
We may document the current behavior and that such a user may have two dashboards - one in EN locale and the other in JA

Note You need to log in before you can comment on or make changes to this bug.