Hello Dave,
Dave Shield schrieb:
>
> Paul> I originally only had the one log, but some comments back
> Paul> felt the need to write to both so as not to confuse the user.
>
> I could be wrong, but having two separate messages (in two different
> places) relating to the same underlying problem would seem to hold
> equal possibility for confusion.
>
> I'd suspect that anyone using polylingual OpenSource software will be
> quite used to coping with a mixture of messages. But (as usual),
> I'm guessing. More informed input would be useful....
I agree with you in respect to system admins which often have to deal
with english messages as well as native messages. English messages are
ok when it comes to system log files or kernel messages, but for the
user interface of any command it would be great if the messages coming
from there are in the user's native language, and the user will set
his/her native language by setting LANG etc. appropriate.
> Paul> Just setting the locale does not translate any text.
>
> Not at the moment, no.
> But I thought that was the usual mechanism for controlling the
> behaviour of I18ned applications?
> So surely that's the model we should be aiming towards?
>
> [And yes - I did understand what you're planning for]
>
> Dave> Rather than define a new, separate internationalised logging
> Dave> API,
> Dave> [we should] adopt
> Dave> one or other of the "standard" approaches,
>
> Paul> What standard?
> Paul> As far as I can tell there is no internationalized support in
> Paul> net-snmp?
>
> Not in the package as it currently stands, no.
> But the two main I18n standards appear to be the X/Open 'catgets'
> suite (as mentioned by Johannes), and the Gnu gettext approach
> (as mentioned by Patrick).
The decision which package should be used (gettext() or catNNN()) should
be left to the configure mechanism, and in case neither is available it
should switch to a default implementation which simply uses the english
messages passed in either case.
> I don't see the need to re-invent the wheel here. (Why's Wes
> laughing again?) Why don't we adopt one or other of these two
> mechanisms?
> Personally, I'm inclined towards the gettext approach (though there
> are licensing implications), partly because this would probably allow
> this to be slipped into the existing snmp_log* API routines with
> minimal changes needed elsewhere.
> But I don't really have the experience to make an informed decision.
The legal question with gettext will be (I think) whether can be used
according to the GNU General Public License or according to the GNU
Library General Public License. The latter shouldn't be a problem as it
isn't with the glibc library which is used in net-snmp when e.g.
compiling and linking under Linux. For the former I can't say anything
but I presume it's more restrictive than the net-snmp license (is it a
BSD style license?).
Who's able to answer whether gettext() might be used according to the
GNU Library General Public License?
BTW I've seen that in some Linux versions the gettext() function comes
from the glibc library. Does that mean that at least the function can ge
used according to the GNU library license?
An alternative might be that in case of using net-snmp sources within
commercial products the usage of gettext() is not allowed, and that
product must either use catNNN() or the default implementation returning
the english messages.
But I'm no lawyer either...
Johannes
> Dave
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Net-snmp-coders mailing list
> Net-snmp-coders@xxxxxxxxxxxxxxxxxxxxx
> https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
--
Johannes Schmidt-Fischer
InterFace AG phone +49 (0)89 / 610 49 - 207
Leipziger Str. 16 fax +49 (0)89 / 610 49 - 85
D-82008 Unterhaching mobile +49 (0)171/ 787 76 01
http://www.InterFace-AG.com mailto:jsf@xxxxxxxxxxxxxxxx
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
|
