I've investigated this a bit and found out the following:
For some properties in this form, we have custom translation keys.
For all other properties, we just use the pretty name.
While the pretty name uses translations, those translations aren't defined so even before the recent change, those names weren't translated.
We have the template provider administration that displays the same properties. It has custom translation keys for them like xe.templateprovider.name.
I see the following options:
Display the existing translations from the template provider administration instead of the property's pretty name.
Advantages: translations exist already, no duplicate translation work.
Disadvantages: re-using translation keys isn't really a best practice, and the translations might not match the hints below them
Add new custom translation keys for AWM for all properties that currently don't have one.
Advantages: matches the fact that we already have custom translations for the hints and the other properties
Disadvantages: no re-use of existing translation values and every other UI that displays those properties has the same issue again
Add new translation keys to administration UI that provides the template provider class for the pretty names of the properties
Advantages: solves the issue without any code change in AWM and for all further uses of these properties
Disadvantages: duplicates the keys in the administration UI, we could deprecate the old keys, though, and copy their translations and also use the standard pretty name in the template provider's sheet
I think the second option would be the simplest fix that is most consistent with what we already have, while the third option is the one that would "clean up" the translations the most, but I'm not sure if it is desired as it could be possible that in AWM we want to name or describe things differently than in the template provider administration.
Michael Hamann on 18/Jun/25 12:47
I've investigated this a bit and found out the following: * For some properties in this form, we have custom translation keys. * For all other properties, we just use the pretty name. * While the pretty name uses translations, those translations aren't defined so even before the recent change, those names weren't translated. * We have the template provider administration that displays the same properties. It has custom translation keys for them like {{{}xe.templateprovider.name{}}}.
I see the following options: # Display the existing translations from the template provider administration instead of the property's pretty name. ** Advantages: translations exist already, no duplicate translation work. ** Disadvantages: re-using translation keys isn't really a best practice, and the translations might not match the hints below them # Add new custom translation keys for AWM for all properties that currently don't have one. ** Advantages: matches the fact that we already have custom translations for the hints and the other properties ** Disadvantages: no re-use of existing translation values and every other UI that displays those properties has the same issue again # Add new translation keys for the pretty names of the properties to the administration UI that provides the template provider class for the pretty names of the properties ** Advantages: solves the issue without any code change in AWM and for all further uses of these properties ** Disadvantages: duplicates the keys in the administration UI, we could deprecate the old keys, though, and copy their translations and also use the standard pretty name in the template provider's sheet
I think the second option would be the simplest fix that is most consistent with what we already have, while the third option is the one that would "clean up" the translations the most, but I'm not sure if it is desired as it could be possible that in AWM we want to name or describe things differently than in the template provider administration.
This message was sent by Atlassian Jira (v9.3.0#930000-sha1:287aeb6)
If image attachments aren't displayed, see this article.
