Attribute Localization with Type-Safety

[softworkz]

Hi,

in the recent history, the C# language has seen many great enhancements to improve type-safety and reduce the need for using string literals in code.

Summary

A major and unfortunate plot hole still exists when it comes to localizing attribute values. The problem is that attribute parameter types are limited and provided values need to be constant.
This makes it impossible for an attribute to reference a localized resource string in a type-safe way.

Background

A typical way of localization involves using a resource file (like Resources.resx) for which a strongly typed Resources class is generated with public static property accessors to retrieve the localized strings. That's all fine and there are multiple way for accessing localized resources in an application.

The officially advised way for attribute localization suggests the creation of descendant attribute classes which handle the localization and load the resource string using the actual string value as a resource key.

This causes two problems:

1. From where to load the resources?

How can the attribute implementation know which resource class to use for retrieving the resource strings?

• It could either be hard-coded into the descendant attribute
  => but then it wouldn't be re-usable in other contexts.

        [LocalizedDescription("ResourceKey_MyProperty_Description")]
        public string MyProperty { get; set; }

• Or the attribute would need an additional parameter for specifying the type of the resource class, like it is done for the DisplayAttribute
  => this is ugly and unhandy

        [Display(Description = "ResourceKey_MyProperty_Description", ResourceType = typeof(Resources))]
        public string MyProperty { get; set; }

2. How to ensure type safety?

Strictly speaking it's probably more something like "reference integrity", but the point should be clear:

In either case you need to specify the resource key as string value, which means:

• There's no validation for that string value
• There's no reference between the string value and the resource definition
  • You can't navigate to look up the resource value
  • You can't look up usages of resource strings
• and all the other reasons why we don't want to have string literals in the code..

What about nameof()?

The nameof() operator can provide only a slight improvement in that situation, because:

• Name of what?
  With nameof(), we cannot ensure that it is actually referring to a resource key. It could be any name that is valid in the current context
• No resource reference
  All this can do is to provide a string to the attribute, but it doesn't provide information from where to load the resources

Desired Solution

There should be a way to provide a type-safe reference to a resource property through a single constructor parameter to an Attribute. Something like:

        [LocalizedDescription(propertyref(Resources.MyProperty_Description)]
        public string MyProperty { get; set; }

I found some proposals that could help. Interestingly, the syntax would always be the same, it would just be about replacing propertyref() with one of:

• propertyof()
• memberof()
• fullnameof()
• or similar..

I had hoped that there might be something among the existing new language features which could be used for those cases, yet I couldn't find any.
Maybe there's one that I missed?

What are the ideas of the C# Language Team for closing this gap?

Thank you very much,
softworkz

[HaloFour]

The validation and autocompletion of the resource property values could be handled by analyzers. Beyond that I don't really see where a language change would come into play here as there are existing well-known solutions to the problem.

[softworkz]

An analyzer can then verify you're doing this correctly.

Do you have one? Even R# can't do this (except for the DisplayAttribute, but not even DescriptionAttribute or DisplayNameAttribute).

I'm currently developing an R# plugin to add functionality to localize arbitrary attributes, as I'm having a solution with > 1k attributes spread over many projects to localize, Even with the plugin, and even with using nameof(), the situation is still non-satisfactory.

Having some kind of ability to reference not only a type but a member of a specific type in a constant expression would really be beneficiary IMO - not just for this specific case.

[softworkz]

The existing feature proposal might be #712, the infamous "infoof" operator.

Yup, I had read this - it would be one possible way. I wanted to be neutral though, and avoid jumping on a possibly dead horse 😄

I'd rather go with the most realistic proposal...

(tbh, I had the secret hope, that somebody might point me at an existing/upcoming method to solve that issue)

[CyrusNajmabadi]

Do you have one?

No. I have not run into the need for this myself. However, it looks like it would look for things for the form:

[Display(Description = nameof(Resources.ResourceKey_MyProperty_Description), ResourceType = typeof(Resources))]

It would then validate that the type referenced in the nameof is the same as the one in the typeof expression, and would fail if that wasn't a legal member as per hte rules of whatever attribute you were checking. It doesn't seem problematic to write. If you try it out and run into issues there I'd be happy to help you out :)

[softworkz]

Yup, that's what R# already does and the plugin I'm currently working on is adding support for being able to do this for other Attribute types as well.
(these need to have constructor parameters annotated with a LocalizableAttribute and one parameter needs to be of type Type and decorated with a special attribute to indicate that it's indicating the resources class)

Still, it would be way more elegant not having to specify the ResourceType separately and just have a single parameter referencing the property on the Resources class.
And in this case, no analyzer and no R# plugin would be required for validation.

That's what this is about precisely.

[CyrusNajmabadi]

Still, it would be way more elegant not having to specify the ResourceType separately and just have a single parameter referencing the property on the Resources class.

Perhaps. But, from my perspective, languages are very costly and have to produce commensurate value to the ecosystem. Given that this use case is already well solved by existing features and tooling, it greatly diminishes the value is see here. :)