If it's mostly static content, it might make sense to just do different versions. Just figure out how much time it will take to copy/paste/replace content to create the second version and how long it will take to maintain multiple versions and if that's less than how long it would take to create a programmatic solution, it might make sense. If the content is going to change a lot, this might get tedious.
Many of the modern programming environments provide some mechanisms for localization. .Net uses resource files which are basically XML docs that can be organized in different ways. You can pull the locale from the browser or set the locale you want to show, and based on that .Net will render the correct labels from the correct resource file.
So you might be able to do a simple site in one of the modern environments without a great deal of effort.
Can't speak much about CMS systems but I'm sure some out there have solved this problem. It's pretty common these days.
For an app we're building now we rolled our own solution storing localized strings in the database. This gives us a lot more control and it's easier to maintain data in the db than in resource or XML files.
My only advice is to get the site solid and polished before attempting to introduce localized versions. It's easy to make minor UI adjustments and label changes when you're just dealing with one language. Once you start dealing with multiple, adding new labels to a screen or changing them can go from a quick change to one that can take hours and involve multiple people who have to do the localization.
Also be aware that some languages are very long so the space you provide in your menus may be fine for English, but other languages can easily require much more width to communicate the same thing. You might experiment/keep that in mind as you begin working on the design.
