[SPEC-CHANGE] lang parameter, minor line type changes, clarifications...

[solderpunk]

On Sun, Jun 07, 2020 at 07:06:38PM -0400, Matthew Graybosch wrote:
 
> I just read the relevant part of the spec, but I'm still not clear on
> how I should go about specifying that my text is US English. Do I just
> have to add "lang=en_US" on the first line of a text/gemini file?

No, the "lang" parameter is a parameter to the text/gemini MIME type
which is part of the response header.  It doesn't go in the document
itself.  Server software will need to provide admins and/or users some
way to configure this.

This will be fairly easy for people who run their own serer, and hence
have access to the config file, and who write in only a single language
- they can just set a single value which the server includes for all
.gmi files (or whatever extension has been configured to serve as
text/gemini).

Multi-lingual sites would probably work best with content in different
languages separated by the path hierarchy, and servers could let people
designate different languages depending on which regex the path matches.

Multi-user sites will be trickiest of all and will require users to
either bother the admin, or for servers to implement something like
Apache's .htaccess files.

I don't deny that this is kind of painful.  But I don't see a way around
it - if we say that the first line of a text/gemini file should be
"#lang: en-US" or anything like that we have immediately opened the door
to arbitrarly many additional options.  This basically gives us HTTP's
open-ended response header structure and completely defeats the point of
having a response header which is explicitly a single line.
 
> > Lines beginning with ">" are now defined to be quote lines, as per
> > popular demand.
> 
> This will be handy, but now I'm wondering about pre-formatted quotes
> (mainly for poetry, song lyrics, screenplays, etc.)

I would expect those to be handled just with pre-formatted lines.  I get
that they're also a quote of sorts, but simplicity necessitates
sacrifcing the ability for total semantic precision.  I hope we can live
with this.

(of course, something like an entire screenplay can always just be
served in its own document as text/plain)

> Furthermore, looking for quote characters inside a preformatted block
> and then rendering that block in a variable-width font instead (when
> applicable) sounds like a good way to introduce bugs.

It's also a clear violation of the spec!

Cheers,
Solderpunk