Description of problem:
Some panel titles are a single character or truncated to a single character of the second letter in the title
Images is rendering as 'm'
Load Balancers is rendering as 'o'
Trunks is rendering as 'r'
Version-Release number of selected component (if applicable):
*** Bug 1746007 has been marked as a duplicate of this bug. ***
*** Bug 1768316 has been marked as a duplicate of this bug. ***
Are there any updates on this? Our clients are complaining about funny looking tabs.
The problem is that the code uses ngettext to get the translation, but the translations only include the singular form:
Adding translations for the plurals fixes this issue:
Of course manually adding the translations is not practical, we need to modify the code to make the translation templates correctly.
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.
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.
@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.
Good to know! I've now found your bug fix upstream. Do you think it could be backported?
It has been backported.
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.