Re: Internationalized error messages
От | Patrick Welche |
---|---|
Тема | Re: Internationalized error messages |
Дата | |
Msg-id | 20010311181102.B8454@quartz.newn.cam.ac.uk обсуждение исходный текст |
Ответ на | Re: Internationalized error messages (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Fri, Mar 09, 2001 at 03:48:33PM -0500, Tom Lane wrote: > Peter Eisentraut <peter_e@gmx.net> writes: > > Well, SQL defines these. Do we want to make our own list? However, > > numeric codes also have the advantage that some hierarchy is possible. > > E.g., the "22" in "2200G" is actually the category code "data exception". > > Personally, I would stick to the SQL codes but make some readable macro > > name for backend internal use. > > We will probably find cases where we need codes not defined by SQL > (since we have non-SQL features). If there is room to invent our > own codes then I have no objection to this. > > >> I am not sure we can/should use gettext (possible license problems?), > > > Gettext is an open standard, invented at Sun IIRC. There is also an > > independent implementation for BSDs in the works. On GNU/Linux system > > it's in the C library. I don't see any license problems that way. > > Unless that BSD implementation is ready to go, I think we'd be talking > about relying on GPL'd (not LGPL'd) code for an essential component of > the system functionality. Given RMS' recent antics I am much less > comfortable with that than I might once have been. cf. http://citrus.bsdclub.org/ and the libintl in NetBSD, at least NetBSD-current, works. The hard part was eg convincing gmake's configure to use it as there are bits like #if __USE_GNU_GETTEXT rather than just checking for the existence of the functions (as well as the internal symbol _nl_msg_cat_cntr). So yes it's ready to go, but please don't use the same m4 in configure.in as for GNU gettext. Cheers, Patrick
В списке pgsql-hackers по дате отправления: