Support for DataAnnotations

[Kirlu]

Would it be possible to support DataAnnotations since these could have a ErrorMessage associated with them?
In our Entity models we fx. use the Required DataAnnotation attribute, this can have an ErrorMessage, a string which could be translated. In our case we manually translate the ErrorMessage, but we are having trouble localizing this since it can only be a const string when initialized.
As I see it we have three options:

1. making a PowerShell script manually extracting all ErrorMessage = "Something" in DataAnnotations.
2. adding a prefix to strings which would then all be captured using PowerShell fx. "i18n:Something", this would require ngettext-wpf to remove the prefix before adding it to the po files.
3. making a new localized edition of the DataAnnotations, this would work although some of the DataAnnotations are used by fx EntityFramework and are sealed so no inheritance is possible.

What are your thoughts on this?

[robert-j-engdahl]

This is an annoying issue, because we don't have c style macros in C# (and I guess we aren't about to run the c preprocessor either).

I assume the localization part is something you (we) are already handling, and it is only the internationalization (extraction of untranslated messages) that is the issue here.

The classical work-around for "this string should be translated, but not right now" is string Translation.Noop(string msgId) which returns the msgId unchanged but can be recognized by the original xgettext tool given -kNoop option.

[Required(ErrorMessage="This field is required!")]
public int? SomeProperty {get; set;}

Translation.Noop("This field is required")

And given the badness of other options, I think this is what I would go for.

Now that would be an easy solution, but it is error prone as the error message is duplicated.

An awesome solution would be to add support for named attribute parameters in xgettext. Given xgettext already has some ability to parse C# that might actually be an option. Then the folowing would be enough:

[Required(ErrorMessage="This field is required!")]
public int? SomeProperty {get; set;}

when xgettext is invoked with something imaginary option like -kRequired(ErrorMessage). Changing the options might be harder than supporting the named attribute parametes, so -kErrorMessage is perhaps cleaner.

Finally, we could just make a PowerShell script that extracted all strings assigned to a property named ErrorMessage. I.e.

"ErrorMessage *= *\"([^"]*)\""

The rest of the script would look somewhat like Xgettext.Xaml.ps1