User:Amire80/chat bot draft

This is a bunch of ideas for making a chat bot for using the Translate extension or for more general MediaWiki editing. 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.

A prototype for such a bot can be found at the MediaWiki Telegram bot GitHub repo. It has practically no security, lacks most of the features described on this page, and isn't currently enabled in production, but it did work as a simplistic proof of concept. This code may be reused in any way, but this is not a requirement, and this project can be written from scratch.

Intro
The general idea is to make it possible to edit at least some parts of MediaWiki sites without leaving one's favorite chat app. Chat apps are possibly the most ubiquitous apps on smartphones. A lot of typing happens in them, but none of it goes to Wikimedia sites at the moment.

The target audiences are: The initial 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.
 * People who use a chat app frequently and would want to contribute something to a Wikimedia site.
 * People who already edit a Wikimedia site and also use a chat app frequently.

User-facing features
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"). The user will type and send the translation as a message.

The user will have the ability to skip a message without translating.

If the message was already translated before the current chat user sent the message, the edit conflict will be handled (how?)

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 for reading. 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 mobile data charges).

The user will be able to choose the message group (a.k.a. project), 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 commands in the fallback language must always work (this is almost always English, although not necessarily).

If the chat platform allows it, the insertables will be shown as custom buttons that the user can tap to add into the translation message. Similarly, the translation memory and machine translation suggestions should 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 light and not flooded by repetitive confirmation messages. However, the bot will let the user know if the translation was not saved after a defined timeout. The bot will also let the user know 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 and WhatsApp), 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.

Maintenance and product management features
The user interface strings of the bot itself will be mostly shown as chat messages. They 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. The updating of translations in the source repository will be able to run as scheduled and unattended as possible.

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. Example queries:
 * How many users are there in the chat interface, as opposed to platforms (mostly desktop web).


 * In which languages is the chat app most popular.

If any of the required features are not possible on the given chat platform/network, this must be explicitly and publicly documented. If possible, the platform's developers should be informed.
 * Which users made the most translations.

Internals and software engineering
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, but other languages (Erlang?..) are acceptable if there's a good reason for this. Choice of any language must be explained in public documentation.

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, Twitter, Snapchat, Kik, Slack, Allo, Line, Wire, KakaoTalk, 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.
 * Another idea, not even related to translation, is to bridge Flow with a chatbot, so that it would be possible to read and write Flow discussions in a chat interface.