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