On Sat, Apr 11, 2009 at 02:47:53AM +0100, Pedro Doria Meunier wrote:
> Actually what I have is a fully internationalized site by means of
> getttext.
> *Some* of the content comes from the PGSQL database where 2 tables
> relation with others (namely for sensor data description).
Why not continue using gettext?
> These tables have the simplest arrangement: id, description :]
>
> I wondered if there was some sort of pgsql extension providing a text
> replacement mechanism of sorts in order to achieve something like
> gettext ...
As with any specialised problem, PG doesn't solve it directly but
provides various tools for you to solve it in which ever way is best for
you.
> I guess I'll have to resort to what I've previously thought of ...
If, by this, you mean having a column for each language, I'd recommend
against doing this. Normalisation is normally the thing to aim for in
databases, so something like:
CREATE TABLE descriptions (
id INTEGER,
lang TEXT,
PRIMARY KEY (id,lang)
description TEXT
);
would generally be considered better. The reason being that this way
you don't need to change the database every time somebody wants to
translate the software into a new language. If you wanted to maintain
compatibility with the rest of the existing code, you could create a
view like:
CREATE VIEW descriptions AS
SELECT id, description
FROM descriptions
WHERE lang = 'en';
Or whatever language your messages are already in and call the table
above something else. Your code can carry on thinking there's a
"descriptions" table (or whatever you call the view) and doesn't need to
know that there are other languages available. You can then slowly move
the code across to the new version of the table and get rid of the view
when you're done.
--
Sam http://samason.me.uk/