Here's a brief overview of how our wml set-up works.
----------------------------------------------------

Here's a typical wml file:
https://svn.torproject.org/svn/website/trunk/en/bridges.wml

The top of the file has:

  ## translation metadata
  # Revision: $Revision$
  # Translation-Priority: 1-high

  #include "head.wmi" TITLE="Tor: Bridges"

  <div class="main-column">

and the bottom of the file has:

    </div><!-- #main -->

  #include <foot.wmi>

and the middle is standard html, plus a few extra tags like
<page> that we've added to automatically link to the translated
pages when they exist. So that wml page produces this html page:
https://www.torproject.org/bridges aka
https://www.torproject.org/bridges.html.en

Then head.wmi and foot.wmi are just other mostly-html files you import
to handle the repeat parts of each page (well, that plus some embedded
perl scripts to generate some of the static content).
https://svn.torproject.org/svn/website/trunk/include/head.wmi
https://svn.torproject.org/svn/website/trunk/en/foot.wmi

You can basically ignore the wml part of them, and to a first
approximation just think of them as more html.

So in summary, wml is like html with a bit more markup.

----------------------------------------------------

Where it gets interesting is the download page:
https://svn.torproject.org/svn/website/trunk/en/easy-download.wml

It has the standard header and footer section, but in the body of the page
it includes links like <a href="<package-osx-bundle-stable>". Rather than
putting URLs and Tor versions into every wml page, and then requiring
the translators to update their page whenever we bump a version number,
we instead define each URL and version as a new wml element:
https://svn.torproject.org/svn/website/trunk/include/versions.wmi