push.tt / Features
In development

Crews that do not share a language

Mixed-language teams are the norm on most frontlines. Translated voice and text would make a channel usable by all of it.

In development. Not shipping. This page describes the design we intend and the constraint that makes it harder for us than for others — deliberately, since that constraint is why you would pick us.

The problem is real and common

A yard with three shift languages currently solves this with whoever happens to be bilingual. That works until the day it matters most.

  • Read incoming traffic in your own language
  • Speak in yours and have it arrive in theirs
  • Keep the original audio, so nothing is lost in the round trip

Why this is harder for us

Translation needs text, and getting text from voice is transcription. We do transcription on the sending device precisely so the server never sees content — which means translation has to happen there too, or the encryption guarantee dies to add a convenience feature.

  • On-device translation keeps the guarantee but limits language coverage to what the device supports
  • Server-side translation would cover far more languages and would require plaintext — an explicit, consented trade, never a default
  • We would rather ship the honest version late than the convenient version quietly

What we will not do

Quietly route your traffic through a translation service and keep the padlock in the interface.

  • Any translation mode that requires server access will be off by default and consent-gated
  • Affected conversations will be labelled in-app for every participant, not just the person who enabled it
  • Accuracy limits will be stated on the feature, because a mistranslated safety instruction is a real hazard

Which languages matter to you?

Coverage priorities come from real deployments. Tell us the pairs your crews actually need.