IETF policy on encodings and languages

[Solderpunk]

On Sun Dec 27, 2020 at 9:41 PM CET, John Cowan wrote:
> On Sun, Dec 27, 2020 at 3:06 PM Arav K. <nothien at uber.space> wrote:
>
>
> > the server can easily recognize from the URL what language is
> > expected and should provide an interface (including human-readable META
> > text) in that same language.  That would mean, for example, that the
> > entire ://fr.example.com site should use a French interface.
>
>
> And if you request gemini://example.com/la/non-exsistens.gmi and there
> is
> no support for Latin error messages, as there probably is not? Then what
> language should be used? With the exception of 1x responses,
> human-readable <META> reflects error situations, where by definition the
> server doesn't know what the user can or cannot understand.

One of the motivations for having the second digits clarifying the exact
nature of the error (besides allowing useful logging on the server side
for identifying problems, and allowing the writing of more robust bots)
was that clients could use them to provide *some* degree of localised
error message.  E.g. if a server written by an English-speaking programmer
sends back "51 Not found", a client with a Finnish language interface could
recognise the 51 status code and say to its users:

> Ei löytynyt!  Palvelin sanoi: "Not found"

which a non-English-reading Finn would perceive as:

> Not found!  Server said: "<mysterious foreign message>"

Which is slightly better than just:

> Server said: "<mysterious foreign message>"

And for people who read *some* English (or whatever language the server
uses for errors) but not very much, having a localised translation of the
error category first might be enough context to enable them to make
enough sense of the full error message to have some understanding of
what's going on.

Cheers,
Solderpunk