Breaking national language support in Solaris 8
There is a proposal being discussed on the hackers list about adding
gettext plural support to the national language support (NLS) feature
(--enable-nls) in the upcoming PostgreSQL 8.4. This would mean that
plurals of translated messages (e.g., in psql: 1 row/n rows) will work
properly in languages that don't have plural rules similar to English.
This will, however, only work with GNU Gettext (as used in Linux and BSD
distributions) and Solaris 9 or later, and it is not easy to provide a
backward compatible mode. So we would probably break NLS in Solaris 8
or earlier. Workarounds would be building PostgreSQL 8.4 without NLS or
building with GNU Gettext instead of the one built into Solaris.
If any user of such older Solaris systems or perhaps other systems with
similar issues that we have not considered thinks this would be a
terrible idea, please speak up now.
The thread on the hackers list can also be followed here:
http://archives.postgresql.org/message-id/87y6v3gpa8.fsf@seb.progtech.ru
Peter Eisentraut <peter_e@gmx.net> writes:
This will, however, only work with GNU Gettext (as used in Linux and BSD
distributions) and Solaris 9 or later, and it is not easy to provide a backward
compatible mode.
Eh? I thought it was trivial to provide a backward compatible mode which is
just as good as the existing code. Just use regular gettext on the two strings
separately and pick the right one based on the English rule.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's Slony Replication support!
On Sunday 22 March 2009 13:03:29 Gregory Stark wrote:
Peter Eisentraut <peter_e@gmx.net> writes:
This will, however, only work with GNU Gettext (as used in Linux and BSD
distributions) and Solaris 9 or later, and it is not easy to provide a
backward compatible mode.Eh? I thought it was trivial to provide a backward compatible mode which is
just as good as the existing code. Just use regular gettext on the two
strings separately and pick the right one based on the English rule.
Please follow the thread to the end. This message describes the main problem:
http://archives.postgresql.org/message-id/49C25F76.3030604@gmx.net