Search Postgresql Archives

Re: Internationalization

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thank you Sam for the valuable input!

Best regards,

Pedro Doria Meunier
GSM: +351 96 17 20 188
Skype: pdoriam
 



Sam Mason wrote:
> 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.
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFJ4LhQ2FH5GXCfxAsRAqKwAJ98yZXXpFyVrQCqa5vMEA40UMDsXQCfcQXB
nlxeWHPba/Ab35F2gko4OVs=
=YGTU
-----END PGP SIGNATURE-----

begin:vcard
fn:Pedro Doria Meunier
n:Doria Meunier;Pedro
org:MGPS - MADEIRA GPS, LDA.
adr:;;;;;;Portugal
email;internet:pdoria@xxxxxxxxxxxxxx
title:CEO
tel;home:+351291603721
tel;cell:+351961720188
version:2.1
end:vcard

-- 
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux