Procedura consigliata per l'archiviazione di stringhe multilingue

Innanzitutto assicurati che le località del database può trattare lingue diverse. Usa una codifica del server UTF-8. Facoltativamente, imposta LC_COLLATE = 'C' essere su un terreno neutrale o utilizzare una confronto per la tua prima lingua per avere un ordinamento predefinito. Inizia leggendo il capitolo Supporto per la raccolta nel manuale.

Suggerirei vivamente di utilizzare l'ultima versione di PostgreSQL (9.1 al momento della scrittura) perché ha un supporto di confronto superiore.

Per quanto riguarda la struttura della tabella :mantieni la semplicità. Sembra che ci sia un numero basso e fisso di lingue da affrontare. Potresti avere solo una colonna per ogni lingua quindi:

CREATE TABLE txt (
  txt_id serial PRIMARY KEY
 ,txt    text NOT NULL -- master language NOT NULL?
 ,txt_fr text -- others can be NULL?
 ,txt_es text
 ,txt_de text
);

Questo è abbastanza efficace, anche con molte lingue. Lo spazio di archiviazione NULL è molto economico.
Se hai un numero variabile di lingue da gestire, una tabella separata potrebbe essere la soluzione migliore. Questa soluzione presuppone che tu abbia una "lingua principale", dove la stringa è sempre presente:

CREATE TABLE txt (
  txt_id serial PRIMARY KEY
 ,txt    text NOT NULL -- master language NOT NULL?
);

CREATE TABLE lang (
  lang_abbr text PRIMARY KEY -- de, es, fr, ...
 ,lang      text NOT NULL
 ,note      text
);

Oppure, se è sufficiente un'abbreviazione (di due lettere), basta creare un enum digita per identificare la lingua.

CREATE TABLE txt_trans (
  txt_id    int REFERENCES txt(txt_id) ON UPDATE CASCADE ON DELETE CASCADE
 ,lang_abbr text REFERENCES lang(lang_abbr) ON UPDATE CASCADE
 ,txt       text NOT NULL -- master language NOT NULL?
 ,CONSTRAINT txt_trans_pkey PRIMARY KEY (txt_id, lang_abbr)
);

Non trattare la lingua principale in modo speciale e mantenere tutte le varianti di lingua nella stessa tabella potrebbe semplificare la gestione nell'app. Ma dipende molto dalle tue esigenze.