Allow setting static func to get resources in CommonRules

[rxelizondo]

Hello,

Our 22 year old CSLA based application is now expanding to Poland! As far as I can see, there is no Polish resource file so we will have a translator work on some of the translations.

From the looks of it, most of the resource strings appear to be technical lingo (something that a programmer may find useful but not an end user). So at this point, I would like to focus on translating only the resource strings that matter to the end user (such as built-in broken rules messages that would be displayed during regular application use). Later on, we may expand the translation as needed.

So far, I have identified the following resource strings (the one we use) as resource strings that could be displayed to the end user:

• StringRequiredRule
• StringMaxLengthRule
• StringMinLengthRule
• MinValueRule
• MaxValueRule
• RegExMatchRule

Could someone help me identify other resource string I am missing given the current scope of the translation (resource strings meaningful to end users)?

Thanks.

[rxelizondo]

Never mind, after giving this some thought, I am thinking on going on a different direction.

Thanks.

[rockfordlhotka]

I'd be thrilled to have another language as a resource.

But if you just roll your own rule classes you get to provide your own output strings.

[rxelizondo]

Rolling our own rule classes is what I was thinking of doing. However, I wish there there was an easy way to globally override the output string of the built it rules in a single call. Something like:

Required.MessageText = "Hey, please don't leave {0} blank";

Of course, ideally, the string would come from a resource file. But the point is that at least this way, I could set my custom message one time during initialization.

Did't really think this thorough, just a though.

[rxelizondo]

I don't mind creating the Poland resource file if it helps. We have a translator doing a bunch of English to Polish translations right now and I don't think it would be a big deal to create a resource file for the CSLA.

The biggest issue that I see is that a lot of the translations seem to be technical and specific to the CSLA. And since the person working on the translation is not really technical and knows nothing about the CSLA we may end up with something no better than if we were just using Google translate to do the translation.... perhaps I am wrong about this but that was my first impression from a quick glance at the resource files.

This is why I was thinking on focusing on the important translations first, the ones that are designed to be viewed by the end user. For those, a tool like Google translate not always does a good enough job. You need a native speaking person to do a good enough translation.

[rockfordlhotka]

Thank you @rxelizondo - most of the text is very technical with developer jargon, that is very true. I suspect a native Polish speaker, who is also a developer, would be the only way to get a good translation.

To your point about the strings being flexible - they already are.

For example, there's an overload in the Required rule where it calls your method to get the text.

This allows you to provide a lambda that pulls the text from your application's resource file, instead of the CSLA resource file.

[rxelizondo]

Thank you Rocky,

Assuming that I understand this correctly, the issue with the overload is that I have to add the lambda every time I use the Required rule.... that works but I wanted something easier.

In may example above, I am calling a static property on the Required rule:

Csla.Rules.CommonRules.Required.MessageText = "Hey, please don't leave {0} blank";

Here, I only have to set the message once while my app is initializing and not every time I use the Required rule. I would expect the Required rule to see if its static MessageText property is implemented while figuring out what message to display.

But honestly, this is probably an overkill as I can just create my own rule inhering from the CSLA common rules and override the message there, so its really no big deal... and to be honest, the static property sound like a lazy hack rather than a good workaround.

Thank you.

[rockfordlhotka]

The DataAnnotations attributes have a solution too - where you can provide a resource moniker they use to find the string. If I remember right, you provide the assembly containing the resources, and then the resource name.

We thought about doing that with the CSLA rules too - but decided an open-ended Func was more flexible.

The trick in supporting resource files, is that it is your code that has access to the resources. For someone else's code (like CSLA) to get at your resources, you need to provide the assembly and resource name - or a Func that is in your code.

[rockfordlhotka]

Oh, the reason we went with the Func approach is that some people get resources from a database, not a resource file - and this approach works either way.

[rockfordlhotka]

So I'm thinking this through. Perhaps a good answer is to allow setting the Func as a static on the rule. And integrate it into the config subsystem, so in your app startup with you are configuring services and that sort of thing (in Startup.cs or Program.cs) you'd do something like this (not thought through fully):

  app.UseCsla(c =>
    .Rules()
      .RequiredRule.GetMessage(MyResourceFunction);
...

  public string MyResourceFunction()
  {
    return MyProject.Properties.Resources.RequiredRule;
  }

[rxelizondo]

Just for completeness, I should have probably done this:

Csla.Rules.CommonRules.Required.MessageDelegate= () => "Hey, please don't leave {0} blank";

This would be more adequate.

[rockfordlhotka]

We are thinking along exactly the same lines - I like this idea.

[rxelizondo]

Ah, I see you updated your post as I was creating mine. Yes, your post looks great.

[ossendorf-at-hoelscher]

@rockfordlhotka Isn't this already implemented?

[rockfordlhotka]

I had created this issue as a reminder to look into whether it would be better to use satellite assemblies vs packaging all the resources into the same package as today.

I do think you are right - this isn't really something worth the effort.

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.