COMPGROUPS.NET | Browse | Post | Groups | Users | Stream | About | |

### History of gettext() et al?

• Email
• Follow

Hi all,

Does anyone know where gettext() (et al) originated from?
A quick google suggests it originated from the GNU project
in 1995, but the SunOS 4.1 manual set from 1990 I have here
also mentions it, so it obviously didn't originate at the FSF.

TIA,

--
Rich Teer, SCNA, SCSA

President,
Rite Online Inc.

Voice: +1 (250) 979-1638
URL: http://www.rite-online.net

 1

See related articles to this posting

In article <Pine.SOL.4.58.0311061718000.10310@zaphod>,
Rich Teer  <rich.teer@rite-group.com> wrote:
>Hi all,
>
>Does anyone know where gettext() (et al) originated from?
>A quick google suggests it originated from the GNU project
>in 1995, but the SunOS 4.1 manual set from 1990 I have here
>also mentions it, so it obviously didn't originate at the FSF.

gettext() is from Sun - Somewhere around 1987.

--
EMail:joerg@schily.isdn.cs.tu-berlin.de (home) J�rg Schilling D-13353 Berlin
js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

 0

On Fri, 7 Nov 2003, Joerg Schilling wrote:

> gettext() is from Sun - Somewhere around 1987.

Ah, GNU history revisionists at work again!

Cheers,

--
Rich Teer, SCNA, SCSA

President,
Rite Online Inc.

Voice: +1 (250) 979-1638
URL: http://www.rite-online.net

 0

In article <Pine.SOL.4.58.0311071003390.10310@zaphod>,
Rich Teer  <rich.teer@rite-group.com> wrote:
>On Fri, 7 Nov 2003, Joerg Schilling wrote:
>
>> gettext() is from Sun - Somewhere around 1987.
>
>Ah, GNU history revisionists at work again!

Or, to give them the benefit of the doubt, perhaps it's the limitations of

--
Barry Margolin, barry.margolin@level3.com
Level(3), Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

 0

On Fri, 7 Nov 2003, Barry Margolin wrote:

> Or, to give them the benefit of the doubt, perhaps it's the limitations of

http://www.gnu.org/software/gettext/manual/html_node/gettext_219.html#SEC219

This all began in July 1994, when Patrick D'Cruze had the idea and
initiative of internationalizing version 3.9.2 of GNU fileutils. He
then asked Jim Meyering, the maintainer, how to get those changes
folded into an official release. That first draft was full of #ifdefs
and somewhat disconcerting, and Jim wanted to find nicer ways. Patrick
and Jim shared some tries and experimentations in this area. Then,
feeling that this might eventually have a deeper impact on GNU, Jim
wanted to know what standards were, and contacted Richard Stallman, who
very quickly and verbally described an overall design for what was
meant to become glocale, at that time.

[...]

While Jim took some distance and time and became dad for a second time,
Roland wanted to get GNU libc internationalized, and got Ulrich Drepper
involved in that project. Instead of starting from glocale, Ulrich
rewrote something from scratch, but more conformant to the set of
guidelines who emerged out of the glocale effort. Then, Ulrich got
people from the previous forum to involve themselves into this new
project, and the switch from glocale to what was first named msgutils,
renamed nlsutils, and later gettext, became officially accepted by
Richard in May 1995 or so.

Let's summarize by saying that Ulrich Drepper wrote GNU gettext in
April 1995. The first official release of the package, including PO
mode, occurred in July 1995, and was numbered 0.7. Other people
contributed to the effort by providing a discussion forum around
Ulrich, writing little pieces of code, or testing. These are quoted in
the THANKS file which comes with the GNU gettext distribution.

There's no mention of prior art.

--
Rich Teer, SCNA, SCSA

President,
Rite Online Inc.

Voice: +1 (250) 979-1638
URL: http://www.rite-online.net

 0


Rich Teer wrote:
> On Fri, 7 Nov 2003, Barry Margolin wrote:
>
>
>>Or, to give them the benefit of the doubt, perhaps it's the limitations of
>
>
>
> 	http://www.gnu.org/software/gettext/manual/html_node/gettext_219.html#SEC219
>
> 	This all began in July 1994, when Patrick D'Cruze had the idea and

Well, I was going to start writing this message to back you up, since a
previous message mentioned some Sun documentation from 1987 and I was
able to find gettext in SunOS 3.5 circa 1986, *but* it was not related
to the present day gettext, so I figured you were correct.

However based on your latest post, I will have to disagree with you now that
you have given an actual date. I can state with certainty that the gettext
program as we know it now was indeed included in SunOS 4.1 at least as early
as 1990. Further, it was a part of the xpg library, which in general included
interfaces that were defined in an open standard (such as POSIX) that had
defined behavior that was incompatible with the regular library behaviors.
So gettext was no only in use by 1990, it's behavior was mandated by a standard
that probably used a prior implementation as its basis. This last may be
incorrect, because sometimes standard bodies come up with things cut
from whole cloth.

But as far a prior art relative to 1994, gettext was already here in 1990.

--
blu

Lesson from the blackout of 2003:
The power grid is THE most critical infrastructure, upon which all
others depend, and nobody really knows how it works.
--------------------------------------------------------------------------------
Brian Utterback - Solaris Sustaining (NFS/Naming) - Sun Microsystems Inc.,
Ph/VM: 781-442-1343, Em:brian.utterback-at-ess-you-enn-dot-kom


 0

Joerg Schilling (js@cs.tu-berlin.de) wrote:
: In article <Pine.SOL.4.58.0311061718000.10310@zaphod>,
: Rich Teer  <rich.teer@rite-group.com> wrote:
: >Hi all,
: >
: >Does anyone know where gettext() (et al) originated from?
: >A quick google suggests it originated from the GNU project
: >in 1995, but the SunOS 4.1 manual set from 1990 I have here
: >also mentions it, so it obviously didn't originate at the FSF.

: gettext() is from Sun - Somewhere around 1987.

Was Al Gore around 1968 when he was laying out the plans for the internet.

-bruce
bje@ripco.com

 0

bje@ripco.com (Bruce Esquibel) writes:

> Joerg Schilling (js@cs.tu-berlin.de) wrote:
> : In article <Pine.SOL.4.58.0311061718000.10310@zaphod>,
> : Rich Teer  <rich.teer@rite-group.com> wrote:
> : >Hi all,
> : >
> : >Does anyone know where gettext() (et al) originated from?
> : >A quick google suggests it originated from the GNU project
> : >in 1995, but the SunOS 4.1 manual set from 1990 I have here
> : >also mentions it, so it obviously didn't originate at the FSF.
>
> : gettext() is from Sun - Somewhere around 1987.
>
> Was Al Gore around 1968 when he was laying out the plans for the internet.

I began writing computer programs in 1968.  *Internet*? Are you sure
you did not mean 1986?  And who is that Al Gore, BTW?

--
Maurizio Loreti                         http://www.pd.infn.it/~loreti/mlo.html
Dept. of Physics, Univ. of Padova, Italy              ROT13: ybergv@cq.vasa.vg

 0

On Fri, 7 Nov 2003, Brian Utterback wrote:

> However based on your latest post, I will have to disagree with you now that
> you have given an actual date. I can state with certainty that the gettext
> program as we know it now was indeed included in SunOS 4.1 at least as early
> as 1990. Further, it was a part of the xpg library, which in general included

That means that we agree!  :-)

--
Rich Teer, SCNA, SCSA

President,
Rite Online Inc.

Voice: +1 (250) 979-1638
URL: http://www.rite-online.net

 0

At Fri, 07 Nov 2003 01:25:44 GMT, Rich Teer <rich.teer@rite-group.com> writes:

> Does anyone know where gettext() (et al) originated from?

Sun originated most of the API, and it was a Uniforum proposed
standard.  gettext lost out to catgets in the standardization wars for
some reason, but most free software uses gettext in preference to
catgets.

Thanks to Bruno Haible, the GNU gettext tools these days are much
better than Solaris's; Sun has pretty much stood still while the GNU
folks overtook it.  I think the GNU API is pretty much a superset of
Sun's now (e.g., better support for pluralization).

 0

At Fri, 07 Nov 2003 19:25:05 GMT, Rich Teer <rich.teer@rite-group.com> writes:

> There's no mention of prior art.

There should be.  I've sent the following patch to the gettext
maintainer.  Thanks for bringing this up.

2003-11-07  Paul Eggert  <eggert@twinsun.com>

* gettext.texi (History): Give a tip of the hat to Sun's
UniForum proposal.

===================================================================
RCS file: gettext-tools/doc/gettext.texi,v
retrieving revision 0.12.1.0
retrieving revision 0.12.1.1
diff -pu -r0.12.1.0 -r0.12.1.1
--- gettext-tools/doc/gettext.texi	2003/05/05 09:09:21	0.12.1.0
+++ gettext-tools/doc/gettext.texi	2003/11/07 23:11:00	0.12.1.1
@@ -8513,6 +8513,10 @@ from Patrick and Richard, of course, but
MacKenzie, Fran@,{c}ois Pinard, and Paul Eggert, all pushing and
pulling in various directions, not always compatible, to the extent
that after a couple of test releases, @code{glocale} was torn apart.
+Paul suggested in October 1994 that GNU applications should use the
+simpler @code{gettext} API proposed by Sun to the UniForum Technical
+Subcommittee on I18n and originally implemented in Solaris, and this
+API eventually won out over the alternatives.

While Jim took some distance and time and became dad for a second
time, Roland wanted to get GNU @code{libc} internationalized, and

 0

On Fri, 7 Nov 2003, Paul Eggert wrote:

> Thanks to Bruno Haible, the GNU gettext tools these days are much
> better than Solaris's; Sun has pretty much stood still while the GNU
> folks overtook it.  I think the GNU API is pretty much a superset of
> Sun's now (e.g., better support for pluralization).

I think that's pretty much correct.  Solaris 9 includes the
GNU gettext implementation.

And thanks for sending that note to the gettext maintainer!

--
Rich Teer, SCNA, SCSA

President,
Rite Online Inc.

Voice: +1 (250) 979-1638
URL: http://www.rite-online.net

 0

On Sat, 08 Nov 2003 00:56:43 GMT Rich Teer <rich.teer@rite-group.com> wrote:
> On Fri, 7 Nov 2003, Paul Eggert wrote:
>
>> Thanks to Bruno Haible, the GNU gettext tools these days are much
>> better than Solaris's; Sun has pretty much stood still while the GNU
>> folks overtook it.  I think the GNU API is pretty much a superset of
>> Sun's now (e.g., better support for pluralization).
>
> I think that's pretty much correct.  Solaris 9 includes the
> GNU gettext implementation.

An older one though, IIRC.

I remember going ahead and building the GNU stuff anyway and linking
GNU programs against it, instead of the installed software -- to ensure
that those apps ran the same way on both Solaris and other platforms.

/fc

 0

In comp.unix.solaris Paul Eggert <eggert@twinsun.com> wrote:

> Thanks to Bruno Haible, the GNU gettext tools these days are much
> better than Solaris's; Sun has pretty much stood still while the GNU
> folks overtook it.  I think the GNU API is pretty much a superset of
> Sun's now (e.g., better support for pluralization).

If it were actually a superset, rather than "pretty much", that would be
simple enough to verify by side-by-side comparison.

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

 0

13 Replies
1296 Views

Similar Articles

[PageSpeed] 47

• Email
• Follow

Similar Artilces:

Correct typesetting of i.e.'' et et al'' ?
Hello, as I am writing a my masters thesis, I often write i.e.'' in sentences like  The car is red, i.e. the same color as a tomato'', and et al'' as in  This red car has been entirely described by John Smith et al [Smi93]''. I wonder how to typeset correctly i.e and et al. Is is italic, are there points, how large are the spaces, are there commas before or after? You are welcome to tell me everything you know about correctly typesetting these two abbreviations ;) Best, Bernhard bernhard.kramer@lien.uhp-nancy.fr wrote: > Hello, > > ...

Re: et al.
At 03:07 AM 7/30/2003, Roland Nilsson wrote: >Hi people, > >anybody know if there's a way to get DensityGraphics[] and related functions >to draw its objects without any margins? I've tried various options, but I >always get my density plots with a small whitespace-border, which changes >with plot size in some (seemingly) unpredictable manner. I need to be able >to get the exact positions on-screen of columns and rows in density plots, >so this is a problem... > > >Best Regards, > >--------------------------------------------- >Ro...

Italic et al.
Hi I was trying to find a simple wa of having the et al. in references in italic. some authors don't really agree with this, but must journal require this. I have been using Natbib with apalike Best regards and thanks for your help Luis > I was trying to find a simple wa of having the et al. in references in > italic. custom-bib package can make , well, custom bibliography styles with many variations you can choose from. I think having italic or roman et al. is one of the choices. Chris On Mon, 22 Sep 2003 12:06:14 -0600, Luis wrote: > I was trying to find a simple wa ...

Kernels et al
Hello, This is something from image processing.I know that a guassian 2d kernel is: G(x, y)= 1/(2* pi * sqr(sd))(Exp(- (sqr(x) + sqr(y))/(2*sqr(sd)) where sd is std deviation Is this right? How will the IDL Formulation look like? This is an example of gaussian blur, i guess. Any idea how a hanning kernel looks like? Thanks, Pravesh ...

Templates, et. al
Got a question as it relates to an implemtation approach on templates. So now consider commands and status messages .. lots (a few shown) of them typedef enum { ISP_MSP_ID = 0x1D, MSP_ISP_ID = 0x3F, RJS_LST_ID = 0x2C, // lots more } MSG_ID; typedef struct { unsigned int dest_id :8; MSG_ID msg_id :8; unsigned int length :12; unsigned int count :4; } MSG_HEADER; typedef struct { MSG_HEADER header; unsigned char ccp_message[512]; } CCP_MESSAGE; // MSP <--> ISP messages typedef struct { MSG_HEADER header; unsigned int mode_cmd; double rtc...

Templates et al
I'm revisiting my templates and am kind of wondering how others are migrating their templates as SolidWorks evolves. In the past I had a bevy of part templates set up for the different materials I commonly use. With the advent of the Material manager this is rather redundant, so I'm wondering what types of part templates do y'all use. I could see a different one for different units (fractional, decimal, SAE, Metric, etc) but not much else. You can tell I haven't thought much about this, so I'm throwing it out for opinions. There is less of an issue for assemblies as I...

XKeysymToKeycode et al.
Hello, I'm trying to translate a string into XKeysymcodes. What am I doing wrong? // ------------------------------------------------------------------ // /* gcc -g -Wall -o test test.c -L /usr/X11R6/lib/ -lX11 -lXtst */ #include <stdio.h> #include <X11/Xlib.h> //#include <X11/extensions/XTest.h> int main() { Display *dpy = XOpenDisplay( NULL ); char *teststr = "Hello World"; int i = 0, pdone = 0; KeyCode kcode; KeySym ksym; char *kcodestr, a[2]; while(!pdone) { if(teststr[i]) { a[0] = teststr[i]; ...

wxFileName et al
Looks like wxFileSelector returns properly escaped strings, i.e. C:\\foo\\bar.baz Any recommendations on the easiest way to get the string ready for wxFileName::Assign()? This example... wxFileName one; wxFileName two; //one.Assign("c:\\foo"); one.Assign(wxFileSelector(_T("Pick a file"))); two.Assign("bar"); two.PrependDir(one.GetPath(wxPATH_GET_VOLUME,wxPATH_NATIVE)); wxMessageBox(wxString::Format("%s",two.GetFullPath())); ....displays "C:\\bar" which means the string actually contains four backslashes. Maybe this is a bug in ...

ACID et al
I'm interested to see any comments the group has on something I'm (haphazardly) working on which in part has to do with guaranteeing the ACID properties without locking. In case it's of any interest this was partly prompted by several previous threads regarding lock-free db's, in-memory db's and the TRM. Also by my feeling that the historic 'impedance mismatch' that dates back to batch days, has sort of been superceded by new kinds of impedance. Two big mismatches that I can think of are the stateless nature of the www versus conventional persist...