Karsten Hilbert <Karsten.Hilbert@gmx.net> writes: > > > I am wondering, if it's effective to use text arrays to store > > > multilanguage information. > We solved it like this: > > http://savannah.gnu.org/cgi-bin/viewcvs/*checkout*/gnumed/gnumed/gnumed/server/sql/gmI18N.sql?rev=1.15 This doesn't work for me I get /cgi-bin/viewcvs/gnumed/gnumed/gnumed/serve: unknown location > - i18n_curr_lang holds the (ISO) language string per user I'm interested in this part. Is there a facility for having variables on the postgres side that you can set once at the beginning of a session and then refer to in functions? I instead made my application insert lang_en,lang_fr etc into the queries as appropriate. This made the application code a little uglier than necessary, but it's not too bad, I put the function name in a variable and call $xlate(column) in a double-quoted string. I think having a global postgres variable would be a nice shortcut, though I fear it would make it harder to do things like index lang_en() and lang_fr(). Do you cheat and make your _() IMMUTABLE? It's only immutable if you guarantee that i18n_currr_lang can never change in the middle of a query. But even then you're lying to the server and indexing _() would do strange things, for example. In fact I think it would produce corrupted indexes if it worked at all. > - v_missing_translations is a view of, well, ... This is the one thing that the array solution can't do. But in my case it's dynamic text and both languages are being provided at the same time by the same people. I'm not going to have a translator going through batches of them like gettext. Actually I also have a separate solution for the static application text that is going to be translated in the gettext style. In that case there is a translations table much like gettext. However all the logic for lookups is handled on the application side in a Smarty prefilter. -- greg ---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
