Use of `slug` variable

[mdlincoln]

@fredgibbs I'm wondering if it would be possible for us to refactor away the need to add an explicit slug variable to every lesson. From looking over the current code, it seems that we need a slug for:

1. Generating links from the lesson index to the actual lesson page
2. Getting the image path for the lesson avatar on the lesson index
3. Locating the lesson-specific subdirectory of images/ when linking to images in the lesson page itself

Are these all the places that a slug is needed?

[mdlincoln]

FWIW I was thinking of putting this in _includes so we can call as needed:

{% if page.lang == 'en' %}
  {% assign slug = page.url | remove_first: '/lessons/' | remove_first: '.html' %}
{% else %}
  {% assign slug = page.redirect_from  | remove_first:'/es/lessons/' %}
{% endif %}

I can work up a PR if this actually covers the cases we're looking for.

[acrymble]

this probably isn't the place for this, but I'm worried that our simple, flat, technically sustainable website, is becoming increasingly complicated and reliant upon the knowledge of a few people.

[fredgibbs]

yeah, as things have come together i've thought about doing this as well, since we have snippets on various pages that do basically this same slug assignment. i think @amandavisconti added the slug data initially, so she might have another use in mind, but i think you've outlined the uses we have ATM.

one could argue that we should still allow for an explicit slug definition in the YAML in case we wanted it to be a bit different from the full title. but i'd prefer that they were necessarily the same to avoid confusion.

[mdlincoln]

OK. Lesson URIs are determined by the filename, not the title, so if one wants a new slug, you would just change the filename.

I have a PR cooking and will try to push it this week.

To @acrymble's worry - I want to minimize the amount of YAML headers that editors have to remember to enter, as we already spend quite a bit of time correcting missing headers, and it's why we want to implement validation in #426

To the larger concern - it's warranted. But remember, wanting translations easily tripled the complexity of the jekyll backend. Wanting tagged and sortable lessons increased it a bit more. Wanting to add versions of record will increase that complexity yet again. I think it's worth reevaluating whether versions of record are needed... but the horse has left the stable on multilingualism, and now we're just building the backend in order to manage that complexity.

As a rule of thumb, reducing editor, author, and reader requirements (like remembering which YAML fields to enter; navigating around linked and translated lessons; finding change histories; managing submission tickets) means increased backend engineering. Reducing backend complexity (no link checking, no yaml checking, no change histories, no lesson sorting, no image captions) means increasing editor, author, and reader requirements.

[fredgibbs]

nicely put @mdlincoln!

[acrymble]

@mdlincoln I definitely appreciate the need for complexity. I suppose I'm also wondering if our technical documentation is robust enough that if you got hit by a bus we'd still be able to understand the website.