Hi Olaf,
At my current company they use mainly a mixture of 1 and 3. Whichever way you do it you need to be very organised otherwise it soon becomes a very big content management headache!
Some of the problems I have found:
1. if you keep everything in a database then it loses context so that can cause maintenance problems, for example if you are later asked to change the wording on a page it can be hard to track down all the db records that make up that page. Also its very difficult for translators to work with - they need to see all the text on a page in context in order to effectively translate it without losing the overall meaning.
2 Keeping everything in HTML is easier to work with, but then if the page structure changes, you have many copies to update - trying to keep them all in line is the biggest headache of doing things this way. I think it would be better to use XML/XSLT to generate the HTML - then for each page you could have 1 XSLT file with the structure of the page, plus many XML files containing the text in different languages, plus any other language dependant stuff (for example sometimes images contain text so you may need separate language versions of these...)
3. Do not forget other areas where text may be generated, for example validation warnings from javascript - you can handle this by having separate
js files that only contain the text (defined as constants that can be used in a single functional javascript file), then just include the relevant
js language file along with the
js functions file.
4. also there are other more subtle problem you may find, for example some languages are just have a lot of long words in them (for example Finnish), so the translated version may not look nice in the original layout when things like column headings suddenly become twice as long...
It is definitely an area where the more time you can spend in advance thinking about ways to deal with these sorts of issues, the easier the whole thing will be for you.
hth
Phil