Instantly share code, notes, and snippets.

Embed
What would you like to do?
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 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.

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.

About

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.

Capability

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.

Command

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.

Numerics

RPL_YOURLANGUAGESARE

:<server-name> 687 <nick> <code>[ <code>]+ :Language preferences have been set

RPL_WHOISLANGUAGE

:<server-name> 690 <nick> <code>[ <code>]+ :can speak these languages

ERR_TOOMANYLANGUAGES

:<server-name> 981 <nick> <count> :You specified too many languages

ERR_NOLANGUAGE

:<server-name> 982 <nick> <code>[ <code>]+ :Languages are not supported by this server

Examples

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

References

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