This page collects information about this website itself. It’s divided into two sections: About the contents, which describes information about my posts and how I use this site; and Technical Details which lists things such as the design philosophy and the tools used to produce the site.
- About the contents
- Technical Details
About the contents
Copyright and Copyleft
All of the posts and pages on this site are released under the Peer Production License. This is a modified, explicitly anti-capitalist, version of the CC-NC.
It’s fairly common to release blog content under a CC license, but I don’t do this because I think the name is misleading and it actually enables privatisation and permits for-profit use of the work. If I want to contribute to some shared ideal of a digital commons; I want to make sure that these commons are not enclosed like those of yore. Read more about this here, and here.
You can read the P2P foundation page wiki on the Peer Production License, but in summation if you’re a commoner, an independent worker, a co-operative or worker-owned entity, or a non-profit: you can do what you want with the content, for free, including republishing it to make money (e.g. in a book). If you’re a for-profit, capitalist, organisation that isn’t owned by its workers then you have to pay to have these rights. You don’t get anything without contributing back to the commons.
Since languages are cool and one of my interests; I’ve built this site to support pages and posts in multiple languages. The officially supported languages of the site are currently English (en) and Esperanto (eo), insofar as a personal website can have officially supported languages! The reason I make this distinction is that I’ve committed to translating certain portions of the site into each officially supported language. This means that the following pages are available in each English and Esperanto:
For blog posts: each site language has its own archive of posts which are written at different times. I often write posts in multiple languages but this is not guaranteed. For example, I may write some posts only in Esperanto or only in English. Posts dated before 2021 are generally only available in English.
Very occasionally I may write a single post in a language which is not “officially supported”; if that occurs I’ll make efforts to highlight it in some way so it’s not buried in the site without a page linking to it. The reason I may do this will likely be if I’m learning the language, or learning about the language, and I want to play around.
If a page or post has translations, these are accessible underneath its title via the language menu using the ISO 639-1 code for the language.
For ease of access, here are links to the site index page for each officially supported language:
In the future, I plan to study another language (most likely this will be Spanish) and so this list will grow.
This site supports RSS feeds. There are actually several feeds available. The main feed contains the latest 20 blog posts published on the site at all, from every language (see languages). There’s also a dedicated feed for each site language which is currently English and Esperanto.
Unlike other protocols, on the Web it’s the content producer who decides how content should be viewed.
The site’s design philosophy is inspired by the following sources:
I’ve distilled these into the following rules for myself, which also act as promises to you as a reader whose device has downloaded this page:
- No inline images: Rather than place images on the page within posts I will always link to images and tell you that it’s an image I’m linking to. The reason for this is that this site should load quickly regardless of connection and inline images will slow it down. In addition the page size will increase. If I added in images inline to posts you could unexpectedly use up your mobile data downloading an image. There may be some old posts with some rogue inline images. If you find one, please contact me.
- Simple navigation: I try to keep the site as flat as possible, with only a few layers. Ideally, you’d only need a few clicks to reach any given content from any page.
- Standard, semantic, HTML: I mark up my pages, particularly posts, with semantic HTML such as
<nav>which supports its parseability and readability. Ideally I want a screen reader to be able to interpret the page properly. This also supports you reading this in, for example, Firefox’s Reader View which is good because that means you control the typography.
- Including a Table of Contents on longer pages/posts: Because I ramble, and some pages are longer, I try to write a basic table of contents at the top of each longer page/post to support you jumping to sections.
This site is a static site is built in Markdown and Jekyll. I used to run previous versions of the site via my Indieweb software Brimstone, but that fell over due to lack of maintenance in the face of the onward march of PHP and Symfony. I got into the static site game later than a lot of folks (2021, in fact!) mostly because I enjoyed hacking at Brimstone. I think a lot of folks have migrated away from Jekyll now but it’s what I learned a few years ago and does the trick. My site isn’t very complex compared to a lot of other Indieweb sites, so it builds pretty quickly.
To update the site I write in my text editor, Atom, and upload the static pages to my server via SFTP via Filezilla. I don’t use any Github pages or webhooks. Partly because that’s how I like to do it, partly because I don’t want to add another tool chain in and therefore keep this thing as simple as possible. The code for the site is maintained in a private Gitlab repo.
To enable the multi-language pages and posts, I followed these instructions from Anthony Granger around building a multi-language Jekyll site. In essence, I just add a sub-folder for each language and do some wiring in the config file so that each sub-folder has a url path and each page/post is assigned a language code. A
i18n-link variable added to the frontmatter of each page and post to link the two, and then the templating pulls in all the linked pages.
For the HTML and CSS, I use Pure as it’s simple, clean, elegant, and small. It means that I don’t end up using an entire heavy framework which includes elements I don’t need. I don’t receive it via a CDN at the moment, because it’s so small. I write my own styles on top of it to style things such as the site header and make some text more readable. These custom styles were inherited from Brimstone.