On Tue, May 28, 2013 at 12:25:42PM +0200, Hans de Goede wrote:
> This patch adds the much requested libusb_strerror() function, taking into
> account all issues people raised wrt previous attempts.
> 
> Criteria / Decisions underlying this implementation:
> -Must support translated messages
> -Must not use gettext as that does not work well in combination with Windows
>  (when building with Visual C, or for Windows CE)
> -API compatible with FreeBSD and various patched libusb-s floating around
> -KISS:
>  -Do not add any (other) library dependencies
>  -Do not try to deal with message encodings (iconv), simply always return 
> UTF-8
>   making encoding the problem of the application using libusb_strerror.
>   Apps which don't want to deal with encoding can opt-out with a simple:
>   libusb_set_strerror_locale("en") call, after which the messages returned by
>   libusb_strerror are guaranteed to be pure ASCII.

IMHO you should use LC_MESSAGES in the usual way instead
of inventing your own API.  I.e. libusb_strerror() internally
calls setlocale(LC_MESSAGES, NULL) to query the locale.
But I think it would be better use gettext on platforms where
it is available because translators know how to work with it.

I have no clue about Windows, but it seems libglib2.0 uses gettext
and can be compiled with MSVC?


Johannes

------------------------------------------------------------------------------
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with <2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
_______________________________________________
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel

Reply via email to