Feature requests: gettext

[Salvatore Santagati]

Hi there,

I  thought,  is if possible implement support for gettext
[http://www.gnu.org/software/gettext/] into gengetopt ?

Thanks in advanced
Salvatore Santagati


_______________________________________________
Help-gengetopt mailing list
Help-gengetopt@...
http://lists.gnu.org/mailman/listinfo/help-gengetopt

[Lorenzo Bettini]

Salvatore Santagati wrote:
> Hi there,
>
> I  thought,  is if possible implement support for gettext
> [http://www.gnu.org/software/gettext/] into gengetopt ?
>
> Thanks in advanced
> Salvatore Santagati

Hi

as I had already told Salvatore privately, I've never used gettext
(actually I've never used internalization myself in any programming
languages), so I'd really appreciate the help of anyone in the list who
used gettext: some ideas, some clues on how the generated parser should
be modified...

thanks in advance
cheers
        Lorenzo

--
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
ICQ# lbetto, 16080134     (GNU/Linux User # 158233)
HOME: http://www.lorenzobettini.it MUSIC: http://www.purplesucker.com
http://www.myspace.com/supertrouperabba
BLOGS: http://tronprog.blogspot.com  http://longlivemusic.blogspot.com
http://www.gnu.org/software/src-highlite
http://www.gnu.org/software/gengetopt
http://www.gnu.org/software/gengen http://doublecpp.sourceforge.net



_______________________________________________
Help-gengetopt mailing list
Help-gengetopt@...
http://lists.gnu.org/mailman/listinfo/help-gengetopt

[Tim Post-3]

Hi Lorenzo, sorry for the delayed reply:

On Sat, 2008-08-16 at 12:01 +0200, Lorenzo Bettini wrote:
> Salvatore Santagati wrote:
> > Hi there,
> >
> > I  thought,  is if possible implement support for gettext
> > [http://www.gnu.org/software/gettext/] into gengetopt ?

> as I had already told Salvatore privately, I've never used gettext
> (actually I've never used internalization myself in any programming
> languages), so I'd really appreciate the help of anyone in the list who
> used gettext: some ideas, some clues on how the generated parser should
> be modified...

Since getopt and getopt_long have many implementations (GNU, BSD,
OpenSolaris) .. the localized text would be at best '-glish'. By
'-glish' I mean, pick a language and add 'glish', i.e. 'spanglish'. The
output would be at best mixed, mostly English.

Most implementations of getopt report errors only in English. I just
ported NetBSD getopt to HelenOS after looking at all of them and noticed
that.

So at best, we could expect gettext() to report the few errors that come
from gengetopt generated code itself. This means yet another shared
object dependency ... without much of a payoff since we're limited to
constant English error messages in getopt itself (in most
implementations).

Implementing gettext in gengetopt itself might be worth it, but not in
the generated files.

Cheers,
--Tim

--
Monkey + Typewriter = Echoreply ( http://echoreply.us )



_______________________________________________
Help-gengetopt mailing list
Help-gengetopt@...
http://lists.gnu.org/mailman/listinfo/help-gengetopt

[Tim Post-3]

Hi,

Just to clarify, this is from NBSD getopt:

static const char recargchar[] = "option requires an argument -- %c";
static const char recargstring[] = "option requires an argument -- %s";
static const char ambig[] = "ambiguous option -- %.*sn";
static const char noarg[] = "option doesn't take an argument -- %.*sn";
static const char illoptchar[] = "unknown option -- %cn";
static const char illoptstring[] = "unknown option -- %sn";

FBSD, OBSD are similar, just longer to account for various GNU getopt
compatibility.

This is why I say the output would be (at best) mixed on many systems
when adding gettext. The above strings are expanded by warnx(), which
does not use gettext.

I really think this could introduce more porting headaches for
gengetopt, without much of a pay off.

Cheers,
--Tim

--
Monkey + Typewriter = Echoreply ( http://echoreply.us )



_______________________________________________
Help-gengetopt mailing list
Help-gengetopt@...
http://lists.gnu.org/mailman/listinfo/help-gengetopt

[Lorenzo Bettini]

Tim Post wrote:

> Hi,
>
> Just to clarify, this is from NBSD getopt:
>
> static const char recargchar[] = "option requires an argument -- %c";
> static const char recargstring[] = "option requires an argument -- %s";
> static const char ambig[] = "ambiguous option -- %.*sn";
> static const char noarg[] = "option doesn't take an argument -- %.*sn";
> static const char illoptchar[] = "unknown option -- %cn";
> static const char illoptstring[] = "unknown option -- %sn";
>
> FBSD, OBSD are similar, just longer to account for various GNU getopt
> compatibility.
>
> This is why I say the output would be (at best) mixed on many systems
> when adding gettext. The above strings are expanded by warnx(), which
> does not use gettext.
>
> I really think this could introduce more porting headaches for
> gengetopt, without much of a pay off.
>

 From what I understand, it's better not to add this feature, isn't it? :-)

--
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
ICQ# lbetto, 16080134     (GNU/Linux User # 158233)
HOME: http://www.lorenzobettini.it MUSIC: http://www.purplesucker.com
http://www.myspace.com/supertrouperabba
BLOGS: http://tronprog.blogspot.com  http://longlivemusic.blogspot.com
http://www.gnu.org/software/src-highlite
http://www.gnu.org/software/gengetopt
http://www.gnu.org/software/gengen http://doublecpp.sourceforge.net


_______________________________________________
Help-gengetopt mailing list
Help-gengetopt@...
http://lists.gnu.org/mailman/listinfo/help-gengetopt

[Salvatore Santagati]

>> I really think this could introduce more porting headaches for
>> gengetopt, without much of a pay off.

Thanks very much Tim for your explanation.

>
> From what I understand, it's better not to add this feature, isn't it? :-)
>

From explanation of Tim, I think is better not to add this feature ;-)

thanks in advance
Salvatore


_______________________________________________
Help-gengetopt mailing list
Help-gengetopt@...
http://lists.gnu.org/mailman/listinfo/help-gengetopt

[Lorenzo Bettini]

Salvatore Santagati wrote:

>>> I really think this could introduce more porting headaches for
>>> gengetopt, without much of a pay off.
>
> Thanks very much Tim for your explanation.
>
>> From what I understand, it's better not to add this feature, isn't it? :-)
>>
>
>>From explanation of Tim, I think is better not to add this feature ;-)
>
> thanks in advance
> Salvatore

I hope that gettext functionalities will be added to getopt
implementation soon, at least in glibc...

--
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
ICQ# lbetto, 16080134     (GNU/Linux User # 158233)
HOME: http://www.lorenzobettini.it MUSIC: http://www.purplesucker.com
http://www.myspace.com/supertrouperabba
BLOGS: http://tronprog.blogspot.com  http://longlivemusic.blogspot.com
http://www.gnu.org/software/src-highlite
http://www.gnu.org/software/gengetopt
http://www.gnu.org/software/gengen http://doublecpp.sourceforge.net


_______________________________________________
Help-gengetopt mailing list
Help-gengetopt@...
http://lists.gnu.org/mailman/listinfo/help-gengetopt

[Tim Post-3]

On Tue, 2008-09-16 at 10:32 +0200, Lorenzo Bettini wrote:

> I hope that gettext functionalities will be added to getopt
> implementation soon, at least in glibc...

I doubt it, and here's why:

Getopt is a corner case in userspace libc as far as internationalization
goes, almost everything uses it. If someone wanted to put program 'foo'
on an initrd for instance, they'd either have to statically link against
gettext or make room for another dso depending on how many things used
it. Then there's the dictionaries, etc.

Busybox is a good example.

If I use .. say .. libxml, I know that I have a dependency on something
beyond libc(x). Parsing command line options should not create such a
dependency.

I'd be all for a separate getopt_intl implementation though. Not only
would it help users, it would make producing locale specific manuals a
cinch with something like help2man. That should probably be based on gnu
getopt, since gnu getopt has more perks than most and is by far the
noisiest in its internal error reporting.

Cheers,
--Tim





_______________________________________________
Help-gengetopt mailing list
Help-gengetopt@...
http://lists.gnu.org/mailman/listinfo/help-gengetopt

[Lorenzo Bettini]

Tim Post wrote:

> On Tue, 2008-09-16 at 10:32 +0200, Lorenzo Bettini wrote:
>
>> I hope that gettext functionalities will be added to getopt
>> implementation soon, at least in glibc...
>
> I doubt it, and here's why:
>
> Getopt is a corner case in userspace libc as far as internationalization
> goes, almost everything uses it. If someone wanted to put program 'foo'
> on an initrd for instance, they'd either have to statically link against
> gettext or make room for another dso depending on how many things used
> it. Then there's the dictionaries, etc.
>
> Busybox is a good example.
>
> If I use .. say .. libxml, I know that I have a dependency on something
> beyond libc(x). Parsing command line options should not create such a
> dependency.
>
> I'd be all for a separate getopt_intl implementation though. Not only
> would it help users, it would make producing locale specific manuals a
> cinch with something like help2man. That should probably be based on gnu
> getopt, since gnu getopt has more perks than most and is by far the
> noisiest in its internal error reporting.

Well, adding gettext functionalities to getopt would not necessarily
require gettext dependence: though I don't know much about gettext, in
the programs that used it there's always an #ifdef check to see whether
gettext is available: if it's not a call to a gettext function, say
foo(x) would reduce simply to x.

Moreover, I'm pretty sure to remember that there are some
implementations of getopt with internalization.

this is just for discussion: I'm not a big fun of internalization, and,
as you might have understood, I've never used it :-)

cheers
        Lorenzo

--
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
ICQ# lbetto, 16080134     (GNU/Linux User # 158233)
HOME: http://www.lorenzobettini.it MUSIC: http://www.purplesucker.com
http://www.myspace.com/supertrouperabba
BLOGS: http://tronprog.blogspot.com  http://longlivemusic.blogspot.com
http://www.gnu.org/software/src-highlite
http://www.gnu.org/software/gengetopt
http://www.gnu.org/software/gengen http://doublecpp.sourceforge.net


_______________________________________________
Help-gengetopt mailing list
Help-gengetopt@...
http://lists.gnu.org/mailman/listinfo/help-gengetopt

[Tim Post-3]

On Tue, 2008-09-16 at 11:43 +0200, Lorenzo Bettini wrote:
> Well, adding gettext functionalities to getopt would not necessarily
> require gettext dependence: though I don't know much about gettext, in
> the programs that used it there's always an #ifdef check to see whether
> gettext is available: if it's not a call to a gettext function, say
> foo(x) would reduce simply to x.

In most scenarios, gettext is an external dso. So using getopt would
mean a need to link against it (either dynamically or statically).
Similar to how you inherit ncurses by using readline.

However, getopt is part of libc(x), current use of it means you expect
only to link against libc(x).

A "hello world" program using getopt that normally depended only on core
libc would then inherit a dependency on the gettext dso (and need to set
flags accoringly).

Changing it now would break a lot of builds.

>
> Moreover, I'm pretty sure to remember that there are some
> implementations of getopt with internalization.

Do you remember which one(s)? When bringing getopt to HelenOS userspace
libc, I thought I looked at all of them .. but don't remember seeing
gettext.

>
> this is just for discussion: I'm not a big fun of internalization, and,
> as you might have understood, I've never used it :-)

I'm guilty of not using it much either. I do agree that an
internationalized version should appear, but needs to be separate from
what thousands if not hundreds of thousands of programs are currently
using.

Its an interesting discussion :)

Cheers,
--Tim




_______________________________________________
Help-gengetopt mailing list
Help-gengetopt@...
http://lists.gnu.org/mailman/listinfo/help-gengetopt

[Lorenzo Bettini]

Tim Post wrote:

> On Tue, 2008-09-16 at 11:43 +0200, Lorenzo Bettini wrote:
>> Well, adding gettext functionalities to getopt would not necessarily
>> require gettext dependence: though I don't know much about gettext, in
>> the programs that used it there's always an #ifdef check to see whether
>> gettext is available: if it's not a call to a gettext function, say
>> foo(x) would reduce simply to x.
>
> In most scenarios, gettext is an external dso. So using getopt would
> mean a need to link against it (either dynamically or statically).
> Similar to how you inherit ncurses by using readline.
>
> However, getopt is part of libc(x), current use of it means you expect
> only to link against libc(x).
>
> A "hello world" program using getopt that normally depended only on core
> libc would then inherit a dependency on the gettext dso (and need to set
> flags accoringly).
>
> Changing it now would break a lot of builds.

OK, now I see what you meant :-)

>
>> Moreover, I'm pretty sure to remember that there are some
>> implementations of getopt with internalization.
>
> Do you remember which one(s)? When bringing getopt to HelenOS userspace
> libc, I thought I looked at all of them .. but don't remember seeing
> gettext.

as I said, I can cross my heart on that... probably some years ago, but
I don't remember where... so probably I confused it with another program...

>
>> this is just for discussion: I'm not a big fun of internalization, and,
>> as you might have understood, I've never used it :-)
>
> I'm guilty of not using it much either. I do agree that an
> internationalized version should appear, but needs to be separate from
> what thousands if not hundreds of thousands of programs are currently
> using.

however, I've always thought that libc itself was internationalized...

>
> Its an interesting discussion :)

it is :-)

--
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
ICQ# lbetto, 16080134     (GNU/Linux User # 158233)
HOME: http://www.lorenzobettini.it MUSIC: http://www.purplesucker.com
http://www.myspace.com/supertrouperabba
BLOGS: http://tronprog.blogspot.com  http://longlivemusic.blogspot.com
http://www.gnu.org/software/src-highlite
http://www.gnu.org/software/gengetopt
http://www.gnu.org/software/gengen http://doublecpp.sourceforge.net


_______________________________________________
Help-gengetopt mailing list
Help-gengetopt@...
http://lists.gnu.org/mailman/listinfo/help-gengetopt

[Tim Post-3]

On Tue, 2008-09-16 at 12:30 +0200, Lorenzo Bettini wrote:

> OK, now I see what you meant :-)

:)

> as I said, I can cross my heart on that... probably some years ago, but
> I don't remember where... so probably I confused it with another program...

Actually we share the same foggy memory. Maybe it was BEOS? I can't put
my finger on it either. When I looked, I could not find it .. so it had
to have been something now off the 'radar'.

> however, I've always thought that libc itself was internationalized...

This is why getopt is a corner case.. most things in standard libc do
not print strings, they return allocated or modified strings. Most just
set errno meaningfully which we can make some sense of, most getopt
implementations do not set it, they just print static const strings.

Some have error handlers, but those handlers are not exposed and do not
set anything we can reach.

Getopt has instances where it either:

 - can not complete
 - warns a user why it can't complete

> > Its an interesting discussion :)
>
> it is :-)

Perhaps it will lead to building the better getopt :) The modern getopt
should not use gettext, rather it should let us register a callback
function that prints and deciphers its noise according to weight. (5
being debug, 1 being error). That callback could then use gettext .. and
the issue would be solved.

This keeps extra dependencies out, but still makes internationalization
simple .. yes? :)

Cheers,
--Tim




_______________________________________________
Help-gengetopt mailing list
Help-gengetopt@...
http://lists.gnu.org/mailman/listinfo/help-gengetopt

[Lorenzo Bettini]

Tim Post wrote:
>> as I said, I can cross my heart on that... probably some years ago, but
>> I don't remember where... so probably I confused it with another program...
>
> Actually we share the same foggy memory. Maybe it was BEOS? I can't put
> my finger on it either. When I looked, I could not find it .. so it had
> to have been something now off the 'radar'.
>

mh... I don't think it was BEOS...

> Perhaps it will lead to building the better getopt :) The modern getopt
> should not use gettext, rather it should let us register a callback
> function that prints and deciphers its noise according to weight. (5
> being debug, 1 being error). That callback could then use gettext .. and
> the issue would be solved.
>
> This keeps extra dependencies out, but still makes internationalization
> simple .. yes? :)
>

yes, that'd be a nice implementation! :-)

--
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
ICQ# lbetto, 16080134     (GNU/Linux User # 158233)
HOME: http://www.lorenzobettini.it MUSIC: http://www.purplesucker.com
http://www.myspace.com/supertrouperabba
BLOGS: http://tronprog.blogspot.com  http://longlivemusic.blogspot.com
http://www.gnu.org/software/src-highlite
http://www.gnu.org/software/gengetopt
http://www.gnu.org/software/gengen http://doublecpp.sourceforge.net


_______________________________________________
Help-gengetopt mailing list
Help-gengetopt@...
http://lists.gnu.org/mailman/listinfo/help-gengetopt

[Tim Post-3]

On Tue, 2008-09-16 at 13:45 +0200, Lorenzo Bettini wrote:
> yes, that'd be a nice implementation! :-)

For that to happen, getopt has to get its own errno and various levels
in standard libc... otherwise the callback can only hope to know the
string, errno and the line in getopt that issued it. If statically
linking, this is no problem. But thats icky.

If that's not the case, we squash the errno that the preceding call set.

The former works, until the line number changes in getopt :) This is the
same case with liblvm2cmd.

This is why I suggest an independent library for a modern getopt.
Porting the existing implementation would be madness in ANY flavor. I'll
work on it if you will :)

Cheers,
--Tim




_______________________________________________
Help-gengetopt mailing list
Help-gengetopt@...
http://lists.gnu.org/mailman/listinfo/help-gengetopt