- What is your evaluation of the documentation?
Good except that there are at least some errors/inconsistencies (ngettext in messages_formatting.html for example is missing an argument).
Already noted, will be fixed.
- Did you try to use the library? With what compiler? Did you have any problems?
Yes. MSVC2010. No problems specific to the library but did have a pretty hard time figuring out which version of gettext was necessary and finding it. Simple search for gettext win32 or windows does not turn up a version compatible with this library (--keyword=translate:1,1t syntax invalid). Had to get the recent MSYS developer toolkit (mingw + msys wasn't even enough). After a couple of hours of searching it seemed to be the only option.
[snip]
I have some concerns about the fact that it relies so much on 3rd party
stuff.
The gettext tools are obviously moving targets and not having an easily accessible version of xgettext for Visual Studio users is not an optimal situation. Having to install MinGW and the works shouldn't be required. Various supposed binary downloads of gettext for win32 either are not or are too old.
I also found that of the tools listed for working on po files, only one both worked with plural forms and worked on win32 In fact possibly only the one worked with plural forms at all.
The fact that this library implements a gettext like setup is nice, but the dependency then upon gettext to provide the source extraction tools and such is unfortunate and could certainly lead to problems where there are version conflicts. Based on my experience I'd say that clearly there are some availability issues in this area for those using Visual Studio. Since gettext is someone else's problem, I don't see how boost can safely make sure the necessary programs are available to anyone using boost. Certainly some better documentation about which version of gettext is being emulated should be included (I looked through the docs and never saw anything specifying version).
I'll explain why I relate on 3rd part programs. It is not only xgettext it is much more, you will need many programs. - Gettext provides tools for extraction, merging catalogs and handling them. They are quite complex as they allow for example mark slightly changes source strings as Fuzzy and allow translater to fix them in much easier way. Reinventing this wheel would require lots of work and I'm not so sure it is justified. I admit that as Linux user I sometimes assume that getting latest 3rd part tools is a piece of cake and forget that for Windows much more explicit description required. I'll add to the tutorial pointer to the latest version of gettext tools for Windows. - You will also need tools like Lokalize, Poedit or other translation tools. They are very-very important. For example it took me half an hour to translate entire blog system with Lokalize to Hebrew. Why? Because it gives you embedded spell checker, allows to browse over untranslated strings, search specific strings easily (when I wanted to replace one term by other all over the strings) So translation tools will always be requirement. There are many of them and they are important and well designed. It was essential to replace the runtime part due to - License restrictions (LGPL) - Inability to handle multiple locales in same process. But other then that I don't think that it is essential to rewrite good tools unless you have something to gain. So I'll will add very explicit instructions on how to get latest GNU Gettext for Windows. And how to use older versions and what are their limitations.
Once I did find the correct version of the tools (or at least a version that responded as the documentation explained) the system seemed to work out just fine. I would like to see an alternative to a complete msys install (though I personally like to have it around, others on my team find it useless). I would guess that there should be one but I seriously couldn't find it.
I think it would be possible to provide gettext runtime installs outside boost project. And I'll also put an investigation about it.
I would also like to see boost::locale::format work like boost::format. The documentation also calls this thing a printf like utility class but it doesn't, as opposed to boost::format, accept printf format strings. On the other hand, boost::format(translate("%.4g")) % 3.14 worked just fine so I don't know what this locale specific version is providing.
Small differences between (A) out << boost::format(translate("%.4g")) % 3.14 And (B) out << boost::locale::format(translate("{1,num,p=4}")) % 3.14 A uses global locale while B uses out's locale for both transation and formatting. A would use display non-localized bumber (i.e. C locale) while B localized one like 3,14 instead of 3.14 There are huge differences between them and I'm not sure it is easy to close the gap without reimplementing boost::format.
All that said, I think it could be a good addition. We certainly need something like it and it at least does what I think I need from such a library.
Thanks Artyom