Note: This is a copy of Sadie's original proposed language negotiation spec that I've updated.
IRCv3 Language Negotiation
Copyright (C) 2014-2015 Sadie "SaberUK" Powell email@example.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.
Notes for implementing work-in-progress version
This is a work-in-progress specification.
Software implementing this work-in-progress specification MUST NOT use the
languages capability name. Instead, implementations SHOULD
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
PRIVMSG except in the case of network pseudoclients such as
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
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
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
ERR_TOOMANYLANGUAGES numeric and the request is unsuccessful.
If a client requests one or more unsupported language codes, the server responds
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
Valid language negotiation
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
Client requested too many languages
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
Client requested an invalid language
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