|
this is somewhat related and very important for the internationalization of postgres db i took a look at the localisation routines and could'nt locate any functionality to java getText(int KeyToLookup) ..no big surprise as C preceded Java by at least 10 years 10 years ago i did a contract where I ran thru a mass of legacy code and localised it..the contract was 3 months long and it took every minute to make the localisation work i'm wondering if there is an faster alternative for legacy apps here is what i think is the current localisation for deutsche from /po/de.po source distro #: pl_comp.c:418 pl_handler.c:177 #, c-format msgid "PL/pgSQL functions cannot accept type %s" msgstr "PL/pgSQL-Funktionen können Typ %s nicht annehmen" //In JAVA //to enable deutsche messages struts.custom.i18n.resources=globalMessages_de //globalMessages_de.properties msgid=Speichern greeting=GutenTag item.edit={0} bearbeiten item.create={0} neu anlegen item.list={0}-Liste token.transfer.time=Die \u00dcberweisung wurde am {0,date,HH:mm:ss MM-dd-yyyy} durchgef\u00fchrt endTag=VielGluck firstName=Martin //to acquire localised key for jsp display <s:textfield label="%{getText('employee.firstName')}" name="currentEmployee.firstName"/> ? Martin Gainty ______________________________________________ Verzicht und Vertraulichkeitanmerkung Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. > Subject: Re: How to automatically find the *right* libpq_fe.h? > From: steve@xxxxxxxxxxx > Date: Tue, 3 Nov 2009 10:39:10 -0800 > To: pgsql-general@xxxxxxxxxxxxxx > > > On Nov 3, 2009, at 10:09 AM, Kynn Jones wrote: > > > I'm trying to automate an installation of a collection of Perl > > modules, which requires determining the path to the correct > > libpq_fe.h file. > > > > My original implementation of the Makefile.PL file for this > > installation set this path as the first valid path that it could > > extract from the output of the system command "locate libpq_fe.h". > > > > Not surprisingly this leads to serious problems when the path so > > "discovered" does not really correspond to the Pg server actually > > running on the machine. > > > > Is there a better way to determine the path to the correct > > libpq_fe.h for a given Pg server, short of asking the user to enter > > it by hand? (I'm trying to make this installation automatic rather > > than interactive.) > > > > E.g. is there some way to interrogate the running server for this > > information? > > There isn't really a "right" libpq-fe.h for a given server, you just > want one that's right for the machine you're installing the app on. As > an extreme case, consider what the answer would be if the database was > on a remote machine. > > Rather, use the pg_config you find in the path to get the include > directory (or the compiler flags) or use App::Info::RDBMS::PostgreSQL > or as a last resort $POSTGRES_HOME. > > I think DBD::Pg knows all about this already, as well as some fallback > and override techniques, so unless you're doing something non-DBI you > shouldn't have to worry about it. > > Cheers, > Steve > > > > > -- > Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-general Bing brings you maps, menus, and reviews organized in one place. Try it now. |
