Reorganize Wordlist and move logic to API endpoint

[abuango]

Currently the Wordlist is dependent on Hugo to generate the relevant pages and formats like JSON, PDF, ODT and downloadable HTML. While everything just works now, I propose separating the website into the following parts:

• Wordlist files in JSON or YAML, this can be in the same website project or a separate project.
• The website in Hugo while term pages rendered from the wordlist files.
• REST API endpoint for applications that use the wordlist programmatically while using the Wordlist files as source
• API endpoint to handle generating file formats instead of the current contraption

We can use Firebase Functions or GCP Cloud Run, since we have Google Workspace/GCP already/

cc: @nate-double-u

[relwell]

We might want to have different kinds of content for each term. There are two approaches you can take:

1) Use code generation to generate the page. This risks overwriting any custom content. 2) Rather than using a separate file format for the word list, implement front matter for each page for structure content related to the term.

I'm leaning towards front matter being the way to go. It would allow for greater flexibility per page, while still supporting structured data that could be used for sorting, filtering, reporting, etc.

[abuango]

Thanks for the feedback @relwell.

We currently do some form of Code Generation using Hugo Layouts, see https://github.com/inclusivenaming/website/tree/main/layouts/wordlist

The the markdown files are generated into 3 different formats: .json, regular .html and .custom. The .json file surrently serves https://inclusivenaming.org/word-lists/index.json, while the .custom files are used to generate custom HTML files without the webpage styling, for conversion to PDF, ODT and downloadable HTML formats.

Since front matter is YAML, we can have the terms in a separate directly or project in yaml files just like we currently have them, but not in markdown front matter. These files are then used generate the webpages in whatever format we want.

The new directory or project will be the single source of truth, from which the API, WebPage, and the different file formats are generated from. We can be flexible in the structure of the files, allowing for page specific data or information to be added and carried across the different formats.

I will work on a PoC and share in the next few days.