IETF policy on encodings and languages

[John Cowan]

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.

> We probably also want to disallow using example.com/...?lang=<lang> or
> anything similar, even if it's just in the Best Practices document.
>

I have no idea why you would want to disallow that.  Changes to the query
string *are* changes to the URL, so that a particular language could be
equally well indicated using the domain, the path, or the query, depending
on the server's conventions.

It's the server's responsibility, but also their prerogative, to provide
> an interface in multiple languages.  If they don't, and if the users of
> that server choose not to as well, then it is up to the client (and the
> user controlling it) to translate stuff.


That's ideal, but it's a big burden on the client, which has to use
something as general as Google Translate to convert the Russian error
message being returned by the server to the Welsh expected by the user.

text/gemini's lang parameter helps here.
>

Not really: again, we are talking about the language of error messages.

Another point is that people often google for the meaning of error
messages, and that's made easier if they always look the same, or at least
some part of them always looks the same.



John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
Where the wombat has walked, it will inevitably walk again.
   (even through brick walls!)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201227/fa656b98/attachment-0001.htm>