Adding a language tag in responses

[bortzmeyer]

The Gemini specification allows to set a language tag for content in the response. I do not find a way to add it with Agate. Reading the source code https://github.com/mbrubeck/agate/blob/cd5918e1b95bf799996ebb6cf71e3e308a4dc2b9/src/main.rs#L169 it does not seem possible. This is an important feature so please add it.

[mbrubeck]

Yes, we should add support for this.

Note: There's some discussion here about how other servers let users set the MIME type and language per file: https://lists.orbitalfox.eu/archives/gemini/2020/002525.html

[bortzmeyer]

A possible way is to have a global parameter (for all files). twins and gemserv do it that way, the lang parameter is global to an entire vhost. So if you want content in english and in french, you need two vhosts.

For finer configuration, or for servers without vhost, yes, we need another solution. May be a configuration file with a list of regexps or even simple paths?

/france/ fr
/united-kingdom/ en
/usa/ en
# Default:
/ en 

[KillianKemps]

Maybe the language could be included in the file name to change from the default language?

For example

articles/my-post.en.gmi
articles/mon-article.fr.gmi

[mbrubeck]

I just released Agate 2.0, which has a --language option for setting a global default language for all text/gemini responses. (There are some other significant changes in the version too; see the documentation and release notes for details.)

I also plan to add a way to override this default for individual documents, but I'm not sure when I will get around to it. Patches are welcome.

[Ylhp]

The most flexibel way I see it's to let know to Agate a script given in args which must take in argument the relative path to the file, and the script must answer about language and mime format to answer.

It's a bit tricky, but working and won't break any future standard.

[Ylhp]

Ok, my answer was really awkward, the other mime type are handled yet, I'vnt seen/tested :

if path.extension() == Some(OsStr::new("gmi")) {
        send_text_gemini_header(stream).await?;
    } else {
        let mime = mime_guess::from_path(&path).first_or_octet_stream();
        send_header(stream, "20", &[mime.essence_str()]).await?;
    }

My solution is a little bit oversized so, except if the mime_guess function isn't a long-term solution.

Only for the languages :

• Is there a way to comment ? Maybe we could use '#!lang=fr' to had Header, as headers are strictly limited in Gemini protocole.
• Your idea about extension seems well too : ".fr.gmi" but seems a bit loud.
• Could we image a folder by language ? contents/fr/aboutme.gmi an contents/eo/aboutme.gmi That would simplify how contenters can provide multi-language and multi-translated contents.

What do you think about ?

[mbrubeck]

I am leaning towards an optional configuration file to specify MIME types for files in the same directory, similar to this suggestion from the Gemini list:

https://lists.orbitalfox.eu/archives/gemini/2020/002528.html

We'd want to cache the file's contents to avoid re-reading it on every request, but ideally we would automatically re-read it when it changes. (I don't want to force users to restart the server just to publish new content.)

[Ylhp]

I like this solution. Other would be create an option file for each file.

We have head.gmi and de have head.gmi.agt which can not ne served and contain

lang:en
type:text/gemini

And at each request, the server compare the last atime of the file to check whether it must change its behaviour.

[Johann150]

I think it would be easiest to put everything in one configuration file. But if we do that I think agate will likely not stay a "very simple server for the Gemini hypertext protocol" for much longer.

Already a suggestion for the implementation (also applicable for separate files): The check for an updated configuration might best be done asynchronously. But this would mean that the configuration is only applied to the second visit to the site after a configuration change. On the other hand it is not unusual to reload an application (like e.g. nginx) to update the configuration.

Personally I really like the solution of using an external command to get the content type, but I can also see that this might have really poor performance.

[mbrubeck]

But if we do that I think agate will likely not stay a "very simple server for the Gemini hypertext protocol" for much longer.

Yeah, this has been my main reason for hesitation. I created Agate as a toy server to use for myself and to learn about the Gemini protocol. I'm glad that it has grown into something that is useful to other people, and I don't want to reject changes that benefit real-world users. But I'm not sure I can keep up with maintenance if it keeps growing in complexity.

@Johann150, since you are now a more active user and developer of Agate than I am, would you be interested in taking over as maintainer or co-maintainer? This would mean adding you as an owner on crates.io, and either adding you as a committer to my GitHub repo, or making your fork into the main GitHub repo. I would be happy to continue to help out as needed with code reviews, uploading binaries, etc.

[Johann150]

I would be open to increasing the bus factor, i.e. being a co-maintainer, if you like.

[mbrubeck]

@Johann150 I have invited you as a co-owner of this project on GitHub and crates.io. You may also add yourself to the authors list in Cargo.toml. I'll review your PR #16 as soon as possible.

I'm happy to continue reviewing your code if you would like, but please feel free to make whatever changes you like, with or without consulting me. (This includes reviewing and merging PRs from other contributors.) I have limited time for this project and I don't want to be a bottleneck. Thank you very much for your past and future contributions! :)