localization design for DB structures?

Hello,

I asked this a while back but didn't get a reply, so I'm trying again
(hopefully explaining my question better, too).

I'm setting up a basic "document manager" system that stores various short
text documents which are flagged for display on certain sections of our
website. That's the easy part, which I've already implemented in
FileMaker/Lasso (which I can't wait to get away from, now that I've been
using Postgres and PHP).

We also want to have translations into other languages available for these
documents (although not all of them will be translated). Have others set up
a structure like this before? I'm looking for some guidance on how to set up
the tables so that the document only shows up once in a list of all
documents (or searches), but the user gets the title and content based on
the language they're using (and also when viewing the document in "your"
language, you can see which other translations are available).

My first guess is to have one table with all the basic (meta) info about the
document (category, title in english, id#, etc), and then use another table
for the actual text content and localized versions of the info. This 2nd
table has columns for language, the title (localized).

Anyway, I'm kinda flying in the dark here, and yet I know whole operating
systems have been localized so it can't be too hard to do it for a
relatively short list of categorized text documents (200 or so). This is
probably a wheel that doesn't need re-inventing! Can anyone point me to
where to RTFM or find examples (or books, etc.)?

Thanks.
--i