User:Amire80/chat bot draft

This is a bunch of ideas for making a chat bot for using the Translate extension. It's only a draft. This might become a GSoC project, a pet project, an official WMF project, something else or nothing at all. It's a just a brain dump written quickly on a flight.

The project is to develop a text chat bot that can be used through at least one of the popular instant messaging platforms—Telegram, WhatsApp, Facebook Messenger—to translate messages on sites that use MediaWiki with the Translate extension, such as translatewiki.net, mediawiki.org, Meta Wiki, etc.. This shall be usable with both UI messages translation and page translation.

The bot will send the user a translatable string in the source language, which is not yet translated, or which needs a translation update ("fuzzy") and the user will type and send the translation as a message. The user will have the ability to skip a message without translating.

If a message was already translated, but needs updating because the original message was changed, it will be done with as little typing as possible, for example by editing an existing sent message (possible in Telegram), or by getting the bot to re-send a source message and pre-filling the existing translation.

If the message documentation (also known as "qqq") is available for the message, it will be accessible to the user. If possible, a short preview of the documentation will be shown, and a way to show the complete documentation will be available. This may include a link to open it in the browser. If the message documentation includes images, these may be sent as messages, but this should be optional (some people may want to save on data).

The user will be able to choose the message group, the target language, and the maximum source message length through the chat interface. The preferences will be saved for the next session on the bot's server or in the MediaWiki preferences.

If the platform allows it, custom buttons that a user can tap or click are preferable to commands that must be typed. If commands are used, they must be translatable so that they user will be able to type them without switching the keyboard, but the English commands must always work.

If the chat network allows it, the insertables will be shown as custom buttons that the user can tap to add into the translation message.

The translation memory and machine translation suggestions will be shown as buttons that pre-fill the whole translation.

The bot shall map between the username on the chat network and the username on the MediaWiki installation. An occasional confirmation of the username through a system like OAuth is acceptable, including opening a browser on the user's device, but most communication will be through the chat itself on a mobile device app or on a corresponding desktop app or website.

There is no need to show a confirmation that a translation was not saved so that the chat would be lighter. However, the bot will let the user know that the translation was not saved after a defined timeout. The bot will also let the user that the network is unreachable (for example, by not showing the "sent" notification "v".) If the chat platform supports read confirmation (e.g. "vv" in Telegram), then it will be shown only after the message was saved.

If the user's contribution cannot be saved, for example because of using a blocked account, lack of permissions, AbuseFilter, or other server error, the user must be notified as early as possible, preferably before attempting to submit or even type a translation. An explanation for the error must be shown.

The user interface strings of the bot itself must be translatable on translatewiki.net. It must be possible to update them in the bot's source repository and on the production environment from translatewiki.net using scripts that are publicly available, documented, and as much as possible will be able to run scheduled and unattended.

There must be a way to measure the usage of the platform, for example by using MediaWiki change tags or logging the usage information on the server.

If any of the required features are not possible on the given network, this must be explicitly and publicly documented. If possible, the platform's developers should be informed.

The software can be written in any suitable programming language. Node.js, PHP, Python, or Ruby are preferred because these are the languages that are most commonly known to most MediaWiki developers. Choice of any language must be explained in public documentation.

The code for MediaWiki Telegram bot at GitHub may be reused in any way, but this is not a requirement.

The code should be as common as possible to all the platforms. However, a good and actually deployed implementation of as many features as possible on just one of the three popular platforms is more important than supporting multiple platforms, or having common code.

If several platforms are supported, a table that compares their features must be published and updated as needed.

Stretch goals
It will be nice, but not a hard requirement, to have these in the initial deployment:
 * Support for other chat platforms, such as Signal, Instagram, Snapchat, Kik, Slack, Allo, Line, Wire, Viber, WeChat, etc.
 * IRC and SMS are imaginable, too, although probably challenging.


 * Ability to go back and fix an already-submitted translation with as little typing as possible, for example by editing an existing sent message (possible in Telegram), or by getting the bot to re-send a source message and pre-filling the existing translation.


 * The user will have a way to subscribe to a message group, and have the bot send a message that asks for translations when new translations are needed. This must be easy to disable and re-enable.


 * Review of translations by other users.


 * Quick undo—just undo the translation, as if it wasn't sent at all.


 * Edit the message documentation ("qqq").

Extra-stretch goals
These features are not required, but would be nice to at least keep in mind as possible future enhancements when planning the architecture. If any of these extra-stretch goals makes the architecture too complicated to achieve the goals above, then it can be safely ignored:
 * Capability to edit sentences in any MediaWiki page, not necessarily through Translate.


 * Capability to translate sentences in Content Translation.