💾 Archived View for rawtext.club › ~sloum › geminilist › 001418.gmi captured on 2020-09-24 at 01:53:47. Gemini links have been rewritten to link to archived content

View Raw

More Information

-=-=-=-=-=-=-

<-- back to the mailing list

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

solderpunk solderpunk at SDF.ORG

Mon Jun 8 08:36:06 BST 2020

- - - - - - - - - - - - - - - - - - - 

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 typewhich is part of the response header. It doesn't go in the documentitself. Server software will need to provide admins and/or users someway to configure this.

This will be fairly easy for people who run their own serer, and hencehave 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 astext/gemini).

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

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

I don't deny that this is kind of painful. But I don't see a way aroundit - 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 doorto arbitrarly many additional options. This basically gives us HTTP'sopen-ended response header structure and completely defeats the point ofhaving 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 getthat they're also a quote of sorts, but simplicity necessitatessacrifcing the ability for total semantic precision. I hope we can livewith this.

(of course, something like an entire screenplay can always just beserved 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