Requesting a Feature or Reporting a Problem

Where to send a feature request or a bug report, what to include so we can act on it, and what happens to it afterwards — statuses, the roadmap and the changelog.

Written By Dennis Dueck

Last updated About 1 hour ago

Tell us what you need

Church Translation is built from what churches ask for. There is no product team guessing — the free trial, automatic language switch-off and the keyword booster all started as a request from a church like yours. Here is how to send yours, and what happens to it.

Where to post

Go to https://feedback.churchtranslation.org. You will be asked to sign in the first time you post or vote — that is what lets us follow up with you.

Pick the board that fits:

  • Feature Request — something Church Translation should do, or do differently.
  • Bug report — something that should work and doesn't.
  • Other feedback — anything else: a question, an idea that isn't a feature yet, praise, frustration.
The feedback portal with the three boards and the Create a new post button

Before you write, search. If someone has already asked for it, upvote their post and add a comment with your situation instead of opening a new one — one post with ten churches behind it moves faster than ten posts.

From inside the dashboard

If you are already in the admin dashboard, there is a shorter way. Click the chat bubble in the bottom-right corner and choose Feature request/ Bug report — it opens the same feedback portal, and you are already signed in with your church account. Send us a message in the same panel reaches us directly; use it for anything you'd rather not post publicly. Latest updates below it is the changelog.

The admin dashboard with the chat bubble open: Send us a message, Feature request/ Bug report, Search for help

This is only in the admin dashboard — the visitor app has no feedback bubble; visitors use the portal link above.

What to include in a feature request

The form asks three questions. Answer all three — they are what we actually decide on:

  1. What would you like to do? The task, not the button. "I want to see which languages were used last Sunday" is better than "add a chart".
  2. How would this help your church? Who is affected and how often. "We keep paying for Ukrainian though nobody has picked it since spring" tells us more than "it would be useful".
  3. How do you imagine it working? Optional, but if you have a picture of it, describe it. We may build it differently — knowing what you pictured helps.

For a bug report: what you were doing, what happened, what you expected, and a photo or screenshot of the screen. The time, the language and whether it was during a live service help too.

What happens next

Every post starts as In Review — we read all of them, usually within a few days. From there it moves to one of:

  • Planned — we intend to build it; it appears on the roadmap.
  • In Progress — being built.
  • Completed — live. The changelog entry explains what shipped.
  • Rejected — we won't build it, and the post says why. This is not a judgement on the idea; usually it is cost, or it would make Sunday morning harder for someone else.

You are notified when a post you wrote or voted for changes status. The roadmap at feedback.churchtranslation.org/roadmap shows everything that is planned or in progress; the changelog at /changelog shows what shipped and when.

How we choose

Church Translation is a small team, so we cannot build everything. What gets built first is what hurts the most churches on a Sunday morning — a problem during a live service outranks a nice-to-have, and a request three churches have upvoted outranks one nobody else has felt. The best thing you can do for your request is to be specific about the pain.

Something urgent during a service?

The feedback portal is not monitored live. For a problem while you are translating, start with Sunday Morning Troubleshooting, and file the bug report afterwards — with the time, so we can find it in the logs.