Support Live-Refreshing of IStringLocalizer Strings

[bgribaudo]

This is a belated response to the following request from #3289 (comment):

@mkArtakMSFT:

@bgribaudo, can you please file a separate issue for the following ask. We would like to review it further:

Any chance that support could be added for refreshing cached localizers so that localization strings can be updated live?

In ASP.Net Core 2.1, changes made to pages (*.cshtml) are reflected on the site as soon as the change is saved and the browser window is refreshed. The same holds true with the IViewLocalizers used by pages—updates to these localization strings are reflected on the site as soon as they are saved and the browser window refreshed.

However, the IStringLocalizer instances used for form validation error message are cached during the first request that accesses a particular localizer and remain cached until the site is restarted.

This latter behavior breaks the ability to fully live edit all the text on a page during development as a restart is required every time an IStringLocalizer’s source data is modified.

It also blocks the ability for custom IStringLocalizers to pull live data from external sources (e.g. a database). Instead, when translation strings are updated in the external database, some process needs to take place that restarts the site so that cached localizer instances are purged and new localizer instances are populated with the revised strings (unless someone pulls off fancy code that goes into ASP.Net Core’s internals and wires in a cache purge feature).

Proposal

The ask is for there to be some way to recreate (or refresh) IStringLocalizers on a per-request basis without restarting the site.

Ideas on how this could be done:

• A simple way to do this would be to not cache those localizers across requests. Since this is already the way that IViewLocalizers are handled, it doesn’t seem like too terrible an option. 😊
• Another idea would be to allow specifying a caching stagey when an IStringLocalizerFactory is registered (e.g. an optional argument on the registration method allowing choices like: cache across requests, do not cache, etc.). This would allow the localizer developer to choose the behavior most appropriate for the particular situation.
• A third option would be to provide a method that purges the cache of localizer instances when called. A developer could then hock in a method that runs on each request which calls this method when appropriate.

Related: aspnet/Mvc#7887 (comment)

[hishamco]

I like the 2nd and 3rd options to get live refreshing resource values, but there's one point we should take care about the save and refresh approach is useful in development, but for production precompiled views are preferred

[mkArtakMSFT]

Thanks for contacting us, @bgribaudo.
After some review on this issue we believe this is not something we can provide out of the box, based on the existing ResourceManager based implementation.
Your suggestions look good and you can implement your custom IStringLocalizer to solve this issue.