The sample features a message translation automation. The app is added to designated channels by running a configurator workflow. Once added to specific channels, the app will translate any message there when a user adds a reaction to the message (ex: 🇺🇸, 🇪🇸, 🇫🇷, 🇯🇵, and more)!
To learn the full list of the supported languages, head to the DeepL API's document site.
Guide Outline:
- Included Workflows
- Setup
- Creating Triggers
- Datastores
- Testing
- Deploying Your App
- Viewing Activity Logs
- Project Structure
- Resources
- Reacjilator: Runs when a user reacts to a message in a channel where the app is added. If the reaction is a supported flag emoji (ex: 🇺🇸, 🇪🇸, 🇫🇷, 🇯🇵), then the app will respond in the message thread with a translated message in a language corresponding to the flag a user reacted with.
Before getting started, first make sure you have a development workspace where you have permission to install apps. Please note that the features in this project require that the workspace be part of a Slack paid plan.
To use this sample, you need to install and configure the Slack CLI. Step-by-step instructions can be found in our Quickstart Guide.
Start by cloning this repository:
# Clone this project onto your machine
$ slack create my-app -t slack-samples/deno-message-translator
# Change into the project directory
$ cd my-appThis sample requires a valid DeepL API access token for text translation. Head to the DeepL API site and create your own API account.
Please note that API accounts are different from DeepL's regular accounts. Even when you already have an account for using the text translation on the website, a separate account for API access needs to be created.
Once you create your API account, copy the API token string on the account summary page, which is used for the next section.
When developing locally, environment
variables found in the .env file at the root of your project are used. For
local development, rename .env.sample to .env and add your access token to
the file contents (replacing ACCESS_TOKEN with your token):
# .env
DEEPL_AUTH_KEY=ACCESS_TOKENDeployed apps use environment
variables that are added using slack env. To add your access token to a
Workspace where your deployed app is installed, use the following command (once
again, replacing ACCESS_TOKEN with your token):
$ slack env add DEEPL_AUTH_KEY YOUR_ACCESS_TOKENWhile building your app, you can see your changes appear in your workspace in
real-time with slack run. You'll know an app is the development version if the
name has the string (local) appended.
# Run app locally
$ slack run
Connected, awaiting eventsTo stop running locally, press <CTRL> + C to end the process.
Triggers are what cause workflows to run. These triggers can be invoked by a user, or automatically as a response to an event within Slack.
When you run or deploy your project for the first time, the CLI will prompt
you to create a trigger if one is found in the triggers/ directory. For any
subsequent triggers added to the application, each must be
manually added using the trigger create command.
When creating triggers, you must select the workspace and environment that you'd
like to create the trigger in. Each workspace can have a local development
version (denoted by (local)), as well as a deployed version. Triggers created
in a local environment will only be available to use when running the
application locally.
This app requires a reaction_added event trigger. You can enable it by running the following command:
slack trigger create --trigger-def triggers/reaction_added_trigger.tsTriggers are unique to each installed version of your app. This means that Shortcut URLs will be different across each workspace, as well as between locally run and deployed apps.
Note: triggers won't run the workflow unless the app is either running locally or deployed!
Once this app's bot user is added to a channel, adding reactions such as :jp:
and :fr: results in posting translation results of the target message as
replies in its thread.
For storing data related to your app, datastores offer secure storage on Slack
infrastructure. The use of a datastore requires the
datastore:write/datastore:read scopes to be present in your manifest.
For an example of how to test a function, see functions/translate_test.ts.
Test filenames should be suffixed with _test.
Run all tests with deno test:
$ deno testOnce development is complete, deploy the app to Slack infrastructure using
slack deploy:
$ slack deployWhen deploying for the first time, you'll be prompted to create a new event trigger for the deployed version of your app. Please note that you need to add the production app's bot user to all the channels you'd like to enable the app.
Activity logs of your application can be viewed live and as they occur with the following command:
$ slack activity --tailContains apps.dev.json and apps.json, which include installation details for
development and deployed apps.
Datastores securely store data
for your application on Slack infrastructure. Required scopes to use datastores
include datastore:write and datastore:read.
Functions are reusable building blocks of automation that accept inputs, perform calculations, and provide outputs. Functions can be used independently or as steps in workflows.
Triggers determine when workflows are run. A trigger file describes the scenario in which a workflow should be run, such as a user pressing a button or when a specific event occurs.
A workflow is a set of steps (functions) that are executed in order.
Workflows can be configured to run without user input or they can collect input by beginning with a form before continuing to the next step.
The app manifest contains the app's configuration. This file defines attributes like app name and description.
Used by the CLI to interact with the project's SDK dependencies. It contains script hooks that are executed by the CLI and implemented by the SDK.
To learn more about developing automations on Slack, visit the following: