stag7824 opened a new pull request, #14163:
URL: https://github.com/apache/cloudstack/pull/14163
### Description
The Resource Limits tab (account, domain and project) shows the backup row
labelled with the
raw translation key `label.maxbackup` instead of a readable name.
`ResourceLimitTab.vue` derives the label from the resource type name
returned by
`listResourceLimits`:
```js
:label="$t('label.max' + (item.resourcetypename ?
item.resourcetypename.replace('_', '') : ''))"
```
`ResourceLimitResponse.setResourceType` fills `resourcetypename` from the
enum name, and
`Resource.ResourceType` declares `backup("backup", 12)`, so the key looked
up for that row is
`label.maxbackup`. That key exists in no locale. `en.json` has only
`label.maxbackups`, which
is a different string used by the backup *schedule* form for how many
backups to retain
(`FormSchedule.vue`), and `label.maxbackupstorage`, which is resource type
13.
i18n is configured with `fallbackLocale: 'en'` and `silentTranslationWarn:
true`, so the
missing key produces no warning and vue-i18n renders the key itself.
The same key is used for the validation message when a tagged limit exceeds
its untagged
limit, so that error currently reads `label.maxbackup` too:
```js
this.$t('message.update.resource.limit.max.untagged.error')
.replace('%x', this.$t('label.max' +
this.resourceTypeIdNames[resourcetype].replace('_', '')))
```
Adding the key is enough; nothing else changes. Backup is the only one of
the 17
`Resource.ResourceType` values whose label was missing — the other 16
already resolve.
### Types of changes
- [x] Bug fix (non-breaking change which fixes an issue)
### Feature/Enhancement Scale or Bug Severity
#### Bug Severity
- [x] Trivial
### How Has This Been Tested?
Resolved every `Resource.ResourceType` through the same expression the
template uses, against
the real `en.json` before and after the change (`$t` returns the key when it
is missing):
```
type before after
backup label.maxbackup Max. Backups <-- fixed
unchanged types: 16 of 17
```
So the one row that was broken now resolves, and no other label moves.
`en.json` still parses
(4177 keys).
Found while looking at #13944. That report attributes the problem to
resource types 15
(object_storage) and 16 (gpu), but `label.maxobjectstorage` and
`label.maxgpu` are both
present and resolve correctly, so I do not think this change closes that
issue — I have left
a note there with what I found.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
