Hi,
On 05/30/2013 09:44 AM, Xiaofan Chen wrote:
> On Tue, May 28, 2013 at 6:25 PM, Hans de Goede <hdego...@redhat.com> 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.
>
> I think the other way around will probably be better. By default,
> libusb_strerror()
> should be pure ASCII without doing any other thing. This will make it
> compatible with the existing patched version of libusb.
See my new proposal in this thread, that does exactly that.
>
> IMHO, I am not that fond of a multi-lingual version of libusb_strerror()
> at all. A wiki page providing the translations for the English only error
> messages will be good enough for simple library like libusb.
A disagree if you've a fully translated / localized application you want
user visible error messages to be translated too. But with my new proposal
app authors can choose, and will get only English by default.
>
>> This patch includes a Dutch translation for the messages to show how further
>> languages can be added in a simple manner.
>
> I do not quite like the idea of adding lots of translations in the source
> code. Can it be a separate file if this is really wanted by the community?
This is why it sits in its own strerror.c file, so it is already in a separate
file, esp. with the new proposal, 90% of that file will just be translated
strings,
and unless you're adding a new error code you will never open that file, so all
the translations won't bother you when doing normal development.
Adding it in an external file and doing parsing of that + trying to find a good
location to install it to, and make sure we can find it at runtime, is a lot
of extra code for these 20 or so strings we want translated.
Regards,
Hans
------------------------------------------------------------------------------
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
