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. This is currently in development by Amir E. Aharoni and others.

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 can serve as a proof of concept. This code may be reused in any way, but this is not a requirement, and this project can (and probably should) 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 or messenger 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, and some scenarios of editing Wikipedia and sites related to it could be relevant for editing through a chat app.

The target audiences are:

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

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.

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. The skipped message will not show in the next batch, but there must be a way to come back to it (TODO: define clearer behavior for this).

If the message was already translated before the current chat user sent the message, the edit conflict will be handled (TODO: 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 same for assistant languages: If the user defined assistant languages, there must be an option to show existing translations into them.

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.

The default target language for translations will be picked from the default messenger app language (if available), user's last translations, or user's Babel boxes. If there are multiple choices, they should be shown as buttons if the platform allows it. The server with validate the language codes, so that no damage will be caused by empty, invalid, or non-existing language codes. Relevant redirects will be defined, for example iw -> he.

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, if the platform allows it. Similarly, the translation memory and machine translation suggestions should be shown as buttons that pre-fill the whole 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. (See Phab task.)

The translation will be checked by the existing validation tools: balanced parentheses, presence of $-sign parameters, PLURAL, and GENDER, etc. If the platform allows it, this will be done before the submission. If a translation with such problems is submitted, the system will ask the user to fix it.

The bot shall map between the username on the chat network and the username on the MediaWiki installation (see Phab task). 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 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.

The bot must be usable by multiple people at the same time.

The bot must not submit auto-generated smilies, stickers, and emoji as translations. Some messenger clients auto-converts strings to emoji. If the platform allows it, it must be prevented in the first place. If not, it must be documented how to disable it in the client. The messages must also be validated when submitted, and messages with emoji must be filtered.

Translatable messages will be loaded in batches. The default should be globally configurable (10 sounds sensible), and customizable per user. When a workset is over, a message will be shown asking whether the user wants to load more messages to translate or to finish the session for today.

When there are no more messages to translate in the currently selected message group, a message must be shown.

The user must have an optional way to see the message key.

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.

Send stickers or simple congratulations messages upon completing milestones, such as 10, 100, 1000 translations, or getting a message group to 100% (or 25%, 50%, 75%), etc.

If the chat platform supports auto-synchronization different platforms, for example if it works as an Android app, a Windows app, and a website, the bot functionality must be as similar as possible on all the platforms.

Localization

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 and documented. The updating of translations in the source repository will be able to run as scheduled and unattended as possible.

The messages that the bot sends to the user must resemble a human conversation as much as possible. The language must be precise, but the style must not be too technical. Many languages use gender in the second person, so the bot's messages must be aware of it. The user's gender specification will be read from the MediaWiki account if possible, and it must also be possible to easily change it in the chat.

Maintenance

The service will initially run on a Wikimedia Labs or Tool Labs server. If it proves to be useful and stable, it will be moved to a properly dedicated server.

It must be possible to start a similar bot service from scratch using the same codebase. Procedures and scripts for installing, starting, restarting, shutting down, and upgrading the server will be published just like the rest of the code. Commands for configuring the bot in each chat network will be published and reusable (for example, in the case of Telegram these are the commands that must be sent to the BotFather for setting up the bot account).

Metrics

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.

• Which users made the most translations.
• Which users translate mostly or exclusively through the chat platform.
• Are translations through chat platforms more likely to be reverted than translations through desktop? (And what is the comparison between the different chat platforms?)
• Which messages are most likely to be skipped?
  • The system should self-learn these and avoid sending them.
• What circumstances cause people to translate more?
• What circumstances cause people to give up and mute the bot or leave completely, and how to avoid it?

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.

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.

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

• Edit sentences in any MediaWiki page, not necessarily through Translate. One example is searching for sentences with possible spelling errors and fixing them manually or marking them as correct.
• Add values to Wikidata, similarly to the Wikidata Game.

• Translate sentences in Content Translation.
• Proofread scanned text for Wikisource. (For example, display lines from scanned books.)
• Bridge Flow with a chatbot, so that it would be possible to read and write Flow discussions in a chat interface.