A service that returns localised strings could be wrapped in a service, so that it could be used both locally (eg in an MVC app) and remotely (eg possibly Silverlight).
But...if sticking with the standard practice of creating resources in the UI assembly, that would in effect make a lower layer (BL/Services) have to have a ref on a higher layer (UI)...a definite no-no.
And whereas a lot of AppWide resources (eg: AppName, OK, Cancel, etc.) could be defined in a Common cross-cutting assembly, and the BL/ResourceSerouce could ref and wrap those, that doesn't work in a a Modular App, where the Core app should have no binding to/knowledge of any Module.
One solution could be to have each module, once mounted in mem, 'register' their Resource files with the service, who would then return it to the service (rather a long round trip, but at least consistent as a service, and potentially resources/images could be shared with other resources).
Secondly, that may work in a web app...but not sure how that pattern could be extended to a Silverlight modular app (the round tripping becomes prohibitive).
ie...what are best practices for allowing Resources to be to be defined by the UI designer, in a higher level, but served from the lower BL layer, as a Service?
Or is there a better way of understanding/solving the problem?