Customize Preference Leaf Node Names

[planger]

Hi,

at the moment, we only support specifying custom (or internationalized) names for non-leaf nodes in preferences using the label property. For leaf nodes, however, the label property is not effective.

The label is computed with the PreferenceTreeLabelProvider. This checks for a label property.

However, the PreferenceTreeGenerator does not transfer the label property of preferences into the leaf nodes, which is why this property is essentially ignored for leaf nodes.

Is there a particular reason for that? Or would you be in favor of the following change in the PreferenceTreeGenerator:

    protected createLeafNode(property: string, preferencesGroup: Preference.CompositeTreeNode, data: PreferenceDataProperty): Preference.LeafNode {
        const { group } = Preference.TreeNode.getGroupAndIdFromNodeId(preferencesGroup.id);
        const newNode: Preference.LeafNode = {
            id: `${group}@${property}`,
            preferenceId: property,
            parent: preferencesGroup,
            preference: { data },
            label: data.label, // <- transfer the label to enable nls'ing and customizing the leaf preference nodes?
            depth: Preference.TreeNode.isTopLevel(preferencesGroup) ? 1 : 2
        };
        this._idCache.set(property, newNode.id);
        CompositeTreeNode.addChild(preferencesGroup, newNode);
        return newNode;
    }

Happy to open a PR if you agree! Thanks!

[msujew]

Hey @planger,

at first glance this sounds pretty reasonable. I don't think that should break anything, so please go ahead and file a PR :)

[planger]

Excellent, thank you for the lightning fast feedback!

[planger]

Maybe on a second thought, while this allows to translate custom properties, this doesn't enable translating all core preferences. So I'm wondering whether we should pass this through nls at some point to give adopters a chance to translate also core preference names? What do you think? If you agree, would the label provider be a good place?