Bug 1734257 - OPS 13 Horizon some panel titles are a single character
Summary: OPS 13 Horizon some panel titles are a single character
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: python-django-horizon
Version: 13.0 (Queens)
Hardware: All
OS: Unspecified
low
low
Target Milestone: ---
: ---
Assignee: Radomir Dopieralski
QA Contact: Beth White
URL:
Whiteboard:
: 1746007 1768316 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-07-30 05:42 UTC by David Sedgmen
Modified: 2020-11-12 14:01 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-11-12 14:00:18 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Launchpad 1762089 0 None None None 2019-11-27 15:33:28 UTC
Launchpad 1841617 0 None None None 2019-08-27 15:37:24 UTC
OpenStack gerrit 696321 0 'None' MERGED Fix use of ngettext in registry getName 2020-11-12 13:59:36 UTC

Description David Sedgmen 2019-07-30 05:42:39 UTC
Description of problem:
Some panel titles are a single character or truncated to a single character of the second letter in the title

For example:

Images is rendering as 'm'
Load Balancers is rendering as 'o'
Trunks is rendering as 'r'


Version-Release number of selected component (if applicable):
openstack-horizon:13.0-71.

Comment 12 Radomir Dopieralski 2019-08-27 15:33:36 UTC
*** Bug 1746007 has been marked as a duplicate of this bug. ***

Comment 13 Radomir Dopieralski 2019-11-07 02:50:32 UTC
*** Bug 1768316 has been marked as a duplicate of this bug. ***

Comment 14 Lukasz Pelczyk 2019-11-07 16:02:45 UTC
Are there any updates on this? Our clients are complaining about funny looking tabs.

Comment 16 Radomir Dopieralski 2019-11-27 13:24:32 UTC
The problem is that the code uses ngettext to get the translation, but the translations only include the singular form:

msgid "Image"
msgstr "Image"

Adding translations for the plurals fixes this issue:

msgid "Image"
msgid_plural "Images"
msgstr[0] "Image"
msgstr[1] "Images"

Comment 17 Radomir Dopieralski 2019-11-27 13:28:17 UTC
Of course manually adding the translations is not practical, we need to modify the code to make the translation templates correctly.

Comment 18 Radomir Dopieralski 2019-11-27 14:46:49 UTC
The problem is quite tricky and is only visible sometimes, but I think I have figured it out. The culprit is in this code: https://github.com/openstack/horizon/blob/3aa3cc934bf77fd656c53f160125ffa69b1e9b81/horizon/static/framework/conf/resource-type-registry.service.js#L397-L433

As you can see, the function getName() uses ngettext() to translate and return the correct singular or plural name for the given resource. There are several problems with it, however:

* it is being called with already translated strings for singular and plural, which means that most of the time it will not find a translation, and fall back to using those translated strings directly — which is fine as long as your language has only one plural form, like English does, but will break horribly in other languages, producing gibberish
* in the rare case where the translation is the same as the translated string, it will find the translation. However, since those strings have been marked for translation using gettext and not ngettext, they will have two separate translations for singular and for plural, instead of a single translation with singular and plural forms
* ngettext expects a list of translations for the different plural forms, but because the string has been marked for translation with gettext and not ngettext, that translation will be a single string instead. The way ngettext is implemented, it will still try to treat that string as a list of translations, and take the second character from it.

I am working on a fix for this, but it involves changing how setNames() is called everywhere.

Comment 19 Pierre Riteau 2020-03-13 10:16:34 UTC
This bug is known upstream as https://bugs.launchpad.net/horizon/+bug/1778189
Its source is a Django bug which was fixed in Django 3.0, but Horizon still needs to upgrade to it: https://github.com/django/django/pull/10898

In the meantime my workaround is to disable translations (for users who are happy to use Horizon in English): https://bugs.launchpad.net/horizon/+bug/1778189/comments/5
This is important even for some English-speaking users: for example UK users are impacted because their locale would be en-GB which is not the default locale.

Comment 20 Radomir Dopieralski 2020-03-13 14:17:57 UTC
@pierre thanks for your opinion, but we have actually found and fixed the source of this problem, and it was the result of using ngettext wrong. The Django bug you have linked to would change the effects of this bug, but would not fix it.

Comment 21 Pierre Riteau 2020-03-13 14:27:48 UTC
Good to know! I've now found your bug fix upstream. Do you think it could be backported?

Comment 22 Radomir Dopieralski 2020-03-16 11:26:11 UTC
It has been backported.

Comment 23 Radomir Dopieralski 2020-03-16 11:34:54 UTC
Ah, sorry, my bad.

This is difficult to backport, because the change of the code is not sufficient to fix the issue. New translations would need to be created for the version to which it is being backported.

Considering how few customers actually ever upgrade their Horizon installs, I doubt this is worth the effort.


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