Where do resource files go within Onion Architecture?

Question

2 part question... I have several resource files (.resx) used in my solution primarily for translation of strings. For example, Errors.resx, Validation.resx, and Enums.resx.

Part1 : If I didn't have the Enums resource file, I'd assume that I should place all resource files in the UI Layer, probably within it's own assembly (like 'Company.App1.MVCApp.Resources') and reference it from the web app (Company.App1.MVCApp)... would I be correct in placing the resource files in the UI layer?

Part 2: The Enums.resx file contains descriptive strings that tie to enum members (using the Description attribute), in my UI and sometimes Domain services I will need to access the descriptive strings possibly in their translation. I thought about storing this somewhere in the Core/Domain layer maybe somewhere like Company.App1.Core.Resources ... ? Or should I create an abstraction in the Core layer and then implement the ResourcemManager somewhere in the Infrastructure layer in order to stick to the proper Onion Architecture.. ?

Answer 1

Part1 : In the application I'm currently working on, there isn't one resx file per concern (Enums, Errors...) but one resx file per project. If you take error messages, for instance, purely UI error messages go in the UI resx file, domain error messages go in the Domain resx, and son on. IMO resource files are best placed closest to the code where the localized strings are used. Having most localization files in the UI project tightly couples localization to the way your application is rendered, which might be problematic if you want to reuse localization in another context than that of your main UI.

Part2 : If you only need to access localized enum members in the Domain layer, then you could have a specific helper in the domain layer that derives from or uses System.Resources.ResourceManager to find the localized string. However, I find it handy to have some kind of general-purpose localization helper in an independent layer that centralizes all the localization logic that is more complex than just a Properties.Resources.[...] and is able to search in all resx files of your solution if need be.