On Sat, Sep 11, 2010 at 04:59:23AM -0700, Artyom wrote:
Perhaps you could let users supply a functor open_file(filename), and they can choose to open the path however they want, from whatever source. The default functor would use what you currently have. Would this be prohibitively difficult?
Yes, it is doable.
However I don't think it is reasonable, I hadn't seen any localization system that does this. Putting dictionaries in file system and using them is something common, also it does not have any performance impacts as dictionaries should be loaded only once into the memory, unlike other game resources like video or images where fragmentation or access time may have effect.
There are many situations where it is unfeasible or even impossible to write to or even read from the filesystem, nor have more than a small set of files available, if any at all. Consider these use cases: * a plugin component for some existing application in the form of a DLL/so, where you then would store localization information inside your executable image; * an ActiveX component for the web, where you have significantly restricted permissions and probably fall under the above case, but with more restrictions; * a game or other application where your resources are baked into virtual filesystem images for efficiency and organizational purposes; * a video game console, where you may have a filesystem to work with, or non-standard interfaces to work with one; * any kind of application where you may retrieve the resources from external sources, like other parts of the filesystem or from a remote host. The last case may sound a bit remote, but consider the case where you have an application installed into a priviledged location like Program Files or /usr. Assume that an end user wants to add new localizations (which happens in real life) and he might not have write permissions into the application directory. A solution to that is to have him put his files in a directory he has permission to, typically in his home directory, from which the localization can override lookups into.
In any case, I would say, you can always re-implement your own boost::locale::message_format facet to deal with such non-standard situation.
Judging by the name of that type and it's apparent purpose, it sounds like quite a strange place to be hacking in file handling when it should be properly extendable. The counter-argument that you need directory information for traversal sounds like something that should be easily accomodatable in a proper extension point. As far as I can see to support your fallbacks, all you need to have is the ability to query and enumerate entities in a hierarchy and retrieve istreams to them. For such an apparently rich and useful library, I find this restriction rather strange. -- Lars Viklund | zao@acc.umu.se