IETF policy on encodings and languages

On Sun, Dec 27, 2020 at 03:41:14PM -0500, John Cowan wrote:
> 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.

If the server has a Latin section, it is expected to have a complete
Latin interface.  And the language that the user is expecting is
generally encoded into the URL itself, as others have mentioned: the
server knows that the /la/ section is requested, so it can use Latin
error messages.

> 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.

Because we don't want the query string to be used as it is in HTML, i.e.
for arbitrary parameters.  Using ?lang=<lang> is setting an arguably
dangerous precedent.
 
> 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.

You're right, clients can't do translation.  But the idea is that if you
came across a site that only had <insert language you don't understand>,
and you really wanted to see it, you would translate it manually.
Similarly, if you use the <language> interface / section of a site, it's
your responsibility (not the server's) to translate it.  If the site
offers a language interface / section that you do understand, use that.
Otherwise, you'll have to translate.

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

You're right, never mind.

> 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.

That's the whole point of the status code.  The user's client can also
present a generic description of the status code (in the user's language
of choice) in addition to the error message from the META line.  The
user can reasonably expect that the error messages are in the language
of the interface / section specified in the URL, e.g. requesting
gemini://example.com/la/~foo could return 51 "non est usor".  If the
user doesn't understand Latin and has still for some reason requested
the Latin interface URL, they can still get a good idea of what's going
on thanks to the code 51, which their client can/should explain as
"Permanent Failure - Not Found".

~aravk | ~nothien
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201228/53b7
6d84/attachment.sig>

---

Previous in thread (11 of 24): 🗣️ Petite Abeille (petite.abeille (a) gmail.com)

Next in thread (13 of 24): 🗣️ Solderpunk (solderpunk (a) posteo.net)

View entire thread.