Skip to content

Instantly share code, notes, and snippets.

Last active January 26, 2018 13:13
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
Star You must be signed in to star a gist
Save DanielOaks/8126122f74b26012a3de37db80e4e0c6 to your computer and use it in GitHub Desktop.
Proposed IRCv3 language negotiation spec

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

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


Valid language negotiation

S: CAP * LS :draft/languages=5,en-GB,en-US,fr-CA,de,nl
C: CAP REQ language
S: 687 NickName en-GB en-US :Language preferences have been set

Client requested too many languages

S: CAP * LS :draft/languages=2,en-GB,en-US,fr-CA,de,nl
C: CAP REQ language
S: 981 NickName 2 :You requested too many languages

Client requested an invalid language

S: CAP * LS :draft/languages=3,en-GB,de,nl
C: CAP REQ language
S: 982 NickName fr-CA en-US :Requested languages are not supported by this server


  1. BCP 47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment