It should not be too hard but requires non-negligible amount of work.
Yes I understand that, thats why:
I wouldn't require such a backend for inclusion, but if/when such a backend gets written I would like it to be included.
So I do not expect you to write such a thing, but if someone did I'd expect you to integrate it. By the way, can you "guesstimate" how much work it would take?
I have no idea, for example to handle XLIFF format it is required to have... an XML parser so I don't know what would it take.
Maybe. From what I understand from the doku boost::format is a subset of locale::format, so I'd expect something like this to work: locale::format("Hello %1%!") % name
Your docs do not say what happens when I do this: locale::format("Today is {1}.") % date(d) I'd expect it to work and give the date in some sensible default formatting.
I'd hate if we had to do something like this:
boost::format("Sensor Value (at %1%): %2$.2%") % (locale::format("{1,date_time}") % date) % value
You can just do boost::locale::format("Sensor Value (at {1,dt}): {2,p=2}") The point is that date_time is actually a number of seconds since Jan 1, 1970 GMT and that is why it is number. Its representation is actually a matter of formatting. Why because if user is happy with time_t he should be able to use it. Finally boost::locale::format does not care about what he writes to the stream.
* it would be nice if boost::locale::date_time and boost::date_time interacted nicely, or ideally could be merged
[snip]
So they can't be really merged.
I understand that, thats why I said interact nicely OR merge.
Minimally I'd expect
boost::date_time dt = ...; locale::format("Today is {1,date}.") % dt to work.
There are several problems: 1. boost::date_time has its own formatter facets and they can't be overridden 2. The use of locale facets in Boost.DateTime is quite incorrect. It is not that simple. I think it can be worked out together with cooperation of Boost.DateTime author/maintainer.
Regards
Fabio
Thanks, Artyom