Common localization messages about dscresource.template

[PlagueHO]

Hi @kungfu71186 - I know what you mean. There are a lot of common messages that it would be good to have use across resources. However, there are a lot of resources where these wouldn't be able to be applied - e.g. resources where properties aren't retrieved individually. I guess the challenge is determining what are the common messages that all resources should log? This might be quite difficult.

Perhaps it would be good to start with a higher level verbose logging strategy that defines what should be logged and when? I often see:

1. logs for the sake of logs (I'm guilty of this and trying to do better).
2. logs that double as code comments. E.g. adds no diagnostic detail, just a description of the code that was run.
3. lack of key information in logs. E.g. Missing a critical piece of diagnostic data from the message (see "Setting the IP address on the adapter".... setting it to what? On what adapter? What Address Family?)

From my experience it might be good to focus on giving guidance around what is useful in logs would be helpful.

Not saying common messages aren't a good idea, just saying that the common messages might only be common across a smaller subset of resources than expected. E.g. the two listed above I only use in about 5% of the resources I maintain (it's not a pattern I've needed much).

[kungfoome]

@PlagueHO That's why I saying that this really isn't about the messages per say, just the ability to have it there.

We used something similar for localized data in another project where it would automatically take the localized data, but you could override or add your own if you wanted to.

So something similar where if I load the localized helper module, it will take what's in that resource and take the common ones and combine them. No extra work on anyone's part, but now you can use common messages if you wanted to.

[johlju]

You mean that Get-LocalizedData should load a common string library (en-US if the specific localized language is not available), and then load the resource specific strings that will override any duplicate in the common string library? The total is returned by Get-LocalizedData. That could work, I like that idea.

@PlagueHO I was thinking the exact thing yesterday when I adding localization to resources in SqlServerDsc. Depending on the day I add verbose strings differently 😞 Though, I try to minimize the change in the resources, so don't want to add verbose string, where no aren't already, but I see the resources are very differently in what is outpute, just as you menationed. Some don't output anything really. And some is "diagnostics". I kind of like "diagnostics", it's easier to debug the code when a user can give the verbose log, and you can follow what happens. But then it need to show the actual values.
I agree we need guidance what to log, where and when. 😄