Note: This is a copy of Sadie's original proposed language negotiation spec that I've updated.
Copyright (C) 2014-2015 Sadie "SaberUK" Powell petpow@saberuk.com
Unlimited redistribution and modification is allowed provided that the above copyright notice and this permission notice remains intact.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
This is a work-in-progress specification.
Software implementing this work-in-progress specification MUST NOT use the
unprefixed languages capability name. Instead, implementations SHOULD
use the draft/languages capability name to be interoperable with other
software implementing a compatible work-in-progress version.
The final version of the specification will use an unprefixed capability name.
This specification allows clients to request that messages from the server are
sent in a specified language. It does not define any translation behaviour for
NOTICE or PRIVMSG except in the case of network pseudoclients such as
services.
Available languages are sent using the draft/languages capability. The value of the
capability is a comma-delimited list of tokens. The first token is an positive
integer which specifies the number of language codes which can be requested.
The next tokens are the BCP 47 codes
of the languages supported by the server, in the order which they are used by
default.
Language codes MAY be advertised with a leading tilde ("~") to advertise that
this language is incomplete. When requesting such a code, clients MUST strip the
leading tilde before requesting the language.
Languages are requested with the LANGUAGE <code>[ <code>]+ command. This
command may be used before registration (similar to the CAP, NICK, and
USER commands).
It is recommended that clients request similar language codes (e.g. requesting
es as well as es-419) to ensure that the correct language is used.
If a language request is successful, the server responds with the
RPL_YOURLANGUAGESARE numeric. It is recommended that the user's language
preferences be broadcast across all servers on the network.
If a client requests more languages than the server allows, the server responds
with the ERR_TOOMANYLANGUAGES numeric and the request is unsuccessful.
If a client requests one or more unsupported language codes, the server responds
with the ERR_NOLANGUAGE numeric and the request is unsuccessful.
:<server-name> 687 <nick> <code>[ <code>]+ :Language preferences have been set
:<server-name> 690 <nick> <code>[ <code>]+ :can speak these languages
:<server-name> 981 <nick> <count> :You specified too many languages
:<server-name> 982 <nick> <code>[ <code>]+ :Languages are not supported by this server
S: :irc.example.com CAP * LS :draft/languages=5,en-GB,en-US,fr-CA,de,nl
C: CAP REQ language
C: LANGUAGE en-GB en-US
S: :irc.example.com 687 NickName en-GB en-US :Language preferences have been set
S: :irc.example.com CAP * LS :draft/languages=2,en-GB,en-US,fr-CA,de,nl
C: CAP REQ language
C: LANGUAGE fr-CA en-GB en-US
S: :irc.example.com 981 NickName 2 :You requested too many languages
S: :irc.example.com CAP * LS :draft/languages=3,en-GB,de,nl
C: CAP REQ language
C: LANGUAGE fr-CA en-GB en-US
S: :irc.example.com 982 NickName fr-CA en-US :Requested languages are not supported by this server