Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
To: "Callum Brown" <callum@calcuode.com>, "Arav K." <nothien@uber.space>,
 <~mieum/booksin.space@lists.sr.ht>
Subject: Re: The brick and mortar
From: "mieum" <mieum@namu.blue>
Date: Mon, 02 Nov 2020 11:49:30 +0900
Message-Id: <C6SFP8YYJ146.1V609X61E02U@maclibre>
In-Reply-To: <C6QFT3ETT965.QRB9DTIB9WY4@callum-computer>

Sorry for my delay again, folks. I have been mostly AFK these past few
days~

> Either one file with different language entries differetiated
> somehow, or each language has its own .bib file.

This might become a little unwieldy. I liked the idea of using a .bib
file to store all the metadata to build out the site, but it might
become a little cumbersome. In the case of different translations of a
text, my understanding is that each individual "text," which in our case
would be the actual files containing the "books," should have it's own
.bib file or entry in a master .bib file. Trying to pack all the
metadata we need into a .bib file seems possible, but it might be better
to just use yaml and source it to build .bib files where we need them :)

> I know the format used in .bib files is geared towards making=20
> citations, cross references, etc., and that the programs that use them
> (e.g. BibTeX, Biber) are tightly coupled to TeX/LaTeX.
> From that point of view YAML probably makes more sense.

> If it seems that we have too much information needed, I suggest we
> stick with using the YAML for all in-site needs (but we still provide
> the .bib files).

I tend to agree with this point now, after thinking about it all
weekend. The bibtex format is pretty versatile and in no way limited to
TeX/LaTeX, but it seems like using yaml would be more robust---and plus
the tooling is already available for such a purpose of building out a
site.

Likewise, I don't think it would be necessary to include a separate
/cite/ or /books/ level. The .bib file can just live with the other .gmi
files and be accessed through the index page for the book, no?

> I like the concept of using localized names in the URLs for everything,
> but I don't know whether it would work with more complicated languages
> (e.g. Chinese).  IIRC, there is a way to encode Chinese characters in
> URLs, but I don't remember whether it would look as neat.

The URLs would have to be percent-encoded, which makes it kind of messy.
If your client percent-encodes URLs for you, then it's not really an
issue I suppose.=20

So, I think we should try and sketch out how to entire site should be
structured. I'm having a hard to time keeping it all in my head (since I
have been VERY distracted lately >_<). I'm trying to picture the entire
process of adding a book and publishing it on the library shelves. Here
are some questions and ideas I have about that:

1. Should the data files (the .gmi files of the books themselves) be
   stored statically to allow permalinks? If so, where? At first I
   thought it would be best to just keep all the data files in a
   separate subdomain, such as stacks.booksin.space, and link to it from
   indexes on language-specific subdomains: en.booksin.space,
   es.booksin.space, etc. For example, a book accessed at
   en.booksin.space/melville/mobydick/mobydick.gmi or=20
   en.booksin.space/fiction/mobydick/mobydick.gmi would=20
   essentially be a symlink to somwhere like
   stacks.booksin.space/melville/mobydick/en/mobydick.gmi, and the
   "permalink" could be given on the index page.

   Is that a weird way to go about it? Different trnaslations would be
   kept in a subfolder where the text is located in the "stack" (such as
   stacks.booksin.space/melville/mobydick/es/mobydick.gmi,=20
   ... /de/mobydick.gmi, etc.) and the index pages of each translation
   would be linked to each other.

   At any rate, it would be helpful to sketch out all the ways the files
   will be accessed through indexes---that is, the logical structure of
   a path, say, for browsing texts by genre.=20

2. The "source files" of the library. Will the source files be separate
   from the data files, or should the "source" be the static directory
   of data files? What I mean is, when a book is added, for example, a
   .gmi file containing the text of the book (formatted in Gemtext) with
   a yaml header is added to the repo. That change gets pulled to the
   server where it is then built into the site and all the static
   indexes, links, etc. are built and adjusted based on the yaml
   metadata. Is this a desirable method, or would it be better to
   manually add a new book to the "stacks" in the form of a .gmi file of
   the text and an accompanying .yml file, and then have the capsule
   builder look for new additions in the stacks and build out all the
   indexes that way?

Sorry if I don't make perfect sense...I am quite sleep deprived right
now haha. Again, thanks for all your interest everyone. Hopefully this
week I will have more time at the computer so I can work on this some
more.

~mieum