Date: Sat, 8 Jun 2002 12:49:15 -0400 From: The Anarcat <anarcat@anarcat.ath.cx> To: Libh <freebsd-libh@freebsd.org> Subject: i18n tools Message-ID: <20020608164915.GA292@lenny.anarcat.ath.cx>
next in thread | raw e-mail | index | archive | help
--/9DWx/yDrRhgMJTb
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Hi.
I've read through the man pages of cat*(3) stuff and, well, I'm not
sure it's suitable for libh. The reason is this: contrary to
gettext, catgets(3) doesn't index the messages per string, but per a
single msg_id (int):
char *
catgets(nl_catd catd, int set_id, int msg_id, const char *s);
That would mean that translation calls would be made like this:
catgets(catd, 0, x, "Monkey");
where x is an arbitrary number defined in the catalog file generated
via gencat. So this would mean having either (a) arbitrary numbers for
messages all around the place, or (b) making a header file containing
macros to give proper names to these numbers.
(a) is out of the question, of course, because of the size of the
project.
(b) is realizable, but still hard to manage anyhow.
I thought at first that the -h option of gencat could do (b), but it
seems it just generates 2 odd macros I didn't figure out yet:
/* Use these Macros to compose and decompose setId's and msgId's */
#ifndef MCMakeId
# define MCMakeId(s,m) (unsigned long)(((unsigned short)s<<(sizeof(short)*8=
))\
|(unsigned short)m)
# define MCSetId(id) (unsigned int) (id >> (sizeof(short) * 8))
# define MCMsgId(id) (unsigned int) ((id << (sizeof(short) * 8))\
>> (sizeof(short) * 8))
#endif
I guess those could be used to generate msg_ids from strings, but that
doesn't make a lot of sense.
So we have 3 alternatives to the system's i18n facilities:
1- use GNU gettext: one more dependency, and a GNU one, but
tried-and-tested software that's easily scalable to our needs.
2- use Citrus project's BSD gettext replacement: not fully
implemented, seems we would still need GNU gettext to generate the
catalogs
3- make our own wrappers to catgets(3): would take time and create
problems
I'm open to suggestions.
I'm not sure that going the catgets(3) direction is the easiest one,
but it's a portable one, and we limit our dependencies this way. But
we'll have a hell of a time implementing this one.
I'm putting this thing back on hold until we have figured this out.
A.
--=20
The idea that Bill Gates has appeared like a knight in shining armour to
lead all customers out of a mire of technological chaos neatly ignores
the fact that it was he who, by peddling second-rate technology, led
them into it in the first place. - Douglas Adams (1952-2001)
--/9DWx/yDrRhgMJTb
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (FreeBSD)
iD8DBQE9AjWKttcWHAnWiGcRAuZSAJ9VqbFWAE0NmFt6WrfzRsXhkEfkEwCeJ+1r
Pz72GQBhYBRAc0CU8WmKxX0=
=GxRR
-----END PGP SIGNATURE-----
--/9DWx/yDrRhgMJTb--
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-libh" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020608164915.GA292>