I have a feature request for a method in the LocalizationService that returns resource strings in a tree structure. When I call LocalizationService's GetAllStrings(string) method I get a flat structure in return (filtered by the key I pass in, which is really nice!). Basically a list of key/value pairs (ResourceItem) where the key is complex and seperated by "/". If I for instance would like to expose resouce strings to an AngularJs app it makes sense to describe resource strings in a json object, much like in the same structure as resource strings in XML files in the ~/lang folder. If the LocalizationService could expose a GetAllStrings variant that returns something like a XDocument or XElement it would be super easy to use that structure in a more flexible way. For instance; serialization of XElement to Json would be a breeze.

I had a look at the XmlLocalizationProvider in action while debugging, and it seems that the internal property XmlLocalizationProvider.LanguageDocument holds pretty much what I'm after, but it is internal and out of reach. Also, It would be nice to be able to simply use the current LocalizationService to get hold of the resource string structure, and not have to cast it to ProviderBasedLocalizationService and dive in to the Providers property and mess around with those.

For now I simply make sure all my resource strings are stuctured in several XML files in the lang folder, and then I read those files from disk as XDocuments and serialize them as json. It works, but I would like a layer of abstraction in between, so that I don't have to load stuff from disk and keep track of file names and so on.

Is this possible at all?

-- 
Regards,
Tarjei Olsen