I measured Gemini Live Translate in 3 languages: same rhythm, 2x the characters

Hayato Kamiya — Fri, 04 Sep 2026 06:46:22 +0000

I build a meeting tool where people who speak different languages talk to each other directly. You speak Japanese, the other person hears English; they speak English, you hear Japanese. The speech translation runs on Google's Gemini 3.5 Live Translate (gemini-3.5-live-translate-preview).

Here is a demo with three people in Japanese, English and Spanish. No signup.

I wanted to add live subtitles to that screen. You listen to the translated audio, and you read what the other person actually said in their own words, before translation. Something like putting original-language subtitles on a dubbed film. Not a transcript that appears after they finish talking: the Pixel Recorder kind, where words show up one or two at a time while they are still speaking.

That gave me a hard requirement I could not design around: if the delay is five seconds, the feature is useless.

Subtitles exist so you can react, in the moment, to what was just said. A subtitle for something said five seconds ago arrives after the conversation has already moved on. Under a second, and you can glance at the panel and keep up. Somewhere between those two numbers is the line between a feature and a decoration.

One word before going further, because it runs through the whole post. The transcript does not come back in one piece: it arrives in small instalments, and each instalment is a chunk. Subtitles are those chunks, joined in the order they turn up.

So the question was simple. How fast does Live Translate actually emit chunks, and how big is each one?

I could not answer it from anything I had.

When I built the prototype, there was no reason to measure this

A few months earlier I had built a prototype on Gemini Live (gemini-3.1-flash-live-preview). The question then was whether you could feed it human speech directly and have the model recognize it as text at all. It could, and it did that well.

Later I settled on Live Translate for making human conversation legible. In principle the two should behave alike, so the prototype code looked reusable — but how much of it carried over was an open question. So I rebuilt on top of it with Live Translate.

When I got to the subtitles, I needed latency numbers. I went back to the prototype for them, and they were not there.

The other side had changed.

Gemini Live is a voice version of an AI chat. You speak, the model answers, one turn each. The AI waits for you to finish. It does not matter how long you take; the conversation does not break. So time was never a variable in the prototype. "Speech goes in, text comes out" was the whole question, and there was no reason to record when each chunk arrived.

Subtitles are not like that. The other side is a person, and people do not wait. If the text does not land while they are still speaking, it is worth nothing — so time itself becomes the requirement.

Same model family, similar-looking API, and the requirements swap out completely depending on whether the thing on the other side is an AI or a human. The prototype answered "does this work." What I needed here was "does this arrive in time." Different job.

Making time measurable

To make the subtitles arrive in time, I first had to know how long they were taking. And to measure "how many seconds after speech begins", I have to know when speech began — on my side of the wire.

So I added VAD (voice activity detection): a step that watches the incoming audio locally and catches the moment a voice starts. When it fires, I record that timestamp and tell the API "starting now".

Gemini Live Translate can also work out where speech begins and ends on its own. But then the start of the clock sits on its side, and there is no way to say what the seconds are counted from. Bringing the time reference over to my side is the whole reason the VAD is there.

The check runs every 32 milliseconds, so the gap to the true onset stays inside that. Against the one second or so that a subtitle is allowed, that is fine enough.

After that it is just logging. The start-of-speech signal, each audio send, each transcript chunk coming back, all with timestamps, on a monotonic clock so nothing shifts under you if the system time is adjusted.

The measuring script pulls the connection settings, the endpoint and the model straight out of the code we actually run, so what goes over the wire is byte-identical to a real session. A measurement of a lookalike would prove nothing about production.

Results

Japanese, English and Arabic. I picked Arabic deliberately: it is written right-to-left, and its script is far from both the Latin alphabet and Japanese.

	Japanese	English	Arabic
Audio length	90s	100s	100s
Speech segments	19	22	21
Transcript chunks	67	73	75
Characters per chunk (median)	6	13	9
Same (mean / p90 / max)	6.0 / 10 / 13	12.0 / 20 / 23	9.0 / 14 / 22
Inter-chunk interval (median / p90)	1.023s / 1.267s	1.049s / 1.399s	1.038s / 1.272s
Speech onset → first chunk (median)	0.64s	0.80s	0.57s
Same (p90 / max)	1.03s / 2.88s	1.24s / 4.40s	1.13s / 2.23s
Arrived during speech / after	63 / 4	67 / 6	71 / 4

The three bold rows are the ones that mattered for building subtitles.

Characters per chunk — how much text arrives at once. This is the only row that differs by 2× (6 / 13 / 9)
Inter-chunk interval — how long until the next piece of text. Near-identical across all three (1.023 / 1.049 / 1.038s)
Speech onset → first chunk — how long before the first character shows up. Also close (0.64 / 0.80 / 0.57s)

So the cadence and the head start are the same in every language, and only the amount of text per delivery changes.

That difference is really about how much a single character carries. Since the interval is almost exactly a second, the per-second count is the same figure: about 6 characters in Japanese, 9 in Arabic, 12 in English. Turned around, that is roughly 170 / 110 / 85 milliseconds of screen time per character. One Japanese character occupies about as long as two English ones.

The chunk counts (67 / 73 / 75) differ because the clips were 90 and 100 seconds long. Per second they come out at 0.74 / 0.73 / 0.75.

For what it is worth, I ran Japanese twice in independent sessions: median onset 0.66s then 0.64s, interval 1.009s then 1.023s. Run-to-run spread is around ±0.05s.

The rhythm does not depend on the language

Three languages, three scripts, and the interval lands on the same second. That does not look like a coincidence.

The server is not emitting per word. It is emitting per unit of time. It appears to flush roughly once a second with whatever it recognized in that second. That means "one or two words at a time" is a property you get in any language. What changes is how many characters fit in a second.

Onset latency is language-independent too: 0.57s to 0.80s at the median, 1.03s to 1.24s at p90. The outliers (2.2s to 4.4s) were all the first utterance of a session. Warm-up. Every subsequent utterance landed in the 0.4–1.2s band. It recurs once per reconnection, which is worth knowing if your session drops.

So why does that number — characters per second — differ by 2×?

This part is speculation. I suspect the rate at which people exchange information by voice settles in roughly the same place whoever is speaking. The processing happens on the human side, and that side does not change with the language. If so, however differently a language chooses to express things, the amount it can carry per second stays put: a script that packs more into each character needs fewer of them, one that packs less needs more, and the same content goes across either way.

There is research that measured something close to this. A 2019 study of 17 languages across 9 families, with 170 native speakers, found that speech rate (syllables per second) varies a lot between languages, but multiply it by the information density of a syllable and every language lands around 39 bits per second (SD 5.10). Languages with less dense syllables talk faster to make up for it.

That study does not include Arabic, and I measured characters on a screen rather than bits or syllables, so the two do not stack directly. Still, "the interval and the head start line up, and only the characters per second differ" fits that shape of explanation.

Two more things I checked, because they change how the receiving side has to be built:

The stream is append-only. I brought up the Pixel Recorder at the top, and one thing it does is rewrite what it already showed you: as recognition catches up, it goes back and corrects an earlier guess.

If Live Translate did the same, subtitles would have to be built on the assumption that text already on screen can move. That changes the whole display, so it was worth checking first.

I looked for rewrites with a deliberately strict test: does any chunk start with three or more characters matching the tail of what I already have? Two hits across all runs, one in Japanese and one in English. Both turned out to be at the same point in the audio, where the speaker restarted a phrase, and the model transcribed the restart faithfully. Not a protocol resend: a real repetition, reproducing at the same position across four independent sessions. Zero corrections. What arrives simply stacks up in order; nothing behind reaches forward to change what is already there. You join the pieces as they come and never look back.

Chunks arrive while the person is still talking. This one decides whether the feature is possible at all.

If the text only landed once an utterance was over, subtitles could only ever be finished sentences appearing in blocks — the opposite of what I wanted. And in this audio the longest single utterance ran 14 seconds. Wait for the end and the panel sits empty for those 14 seconds, by which point the conversation has moved on.

It does not wait. Over 90% of the text was on screen while the person was still speaking. The rest turns up just after they finish.

Only the on-screen text varies by language

And it was never only the character count. How many chunks the same speech breaks into, and where those breaks fall, both change with the language.

Here is what actually arrived:

English   'Anyway, the true'  /  ' ability of the'  /  ' lovely ghostwriter'
Arabic    'طيب، عشان كده يا جماعه'  /  ' قدرات الكاتب'
Japanese  'ラブリーゴースト'  /  'ライターの真の'

English and Arabic broke at word boundaries, and every continuation carried a leading space (look at the gap in front of ' ability of the'). Join them and that space is your word separator.

Japanese did not. The single word "ラブリーゴーストライター" (lovely ghostwriter) is split into 'ラブリーゴースト' and 'ライターの真の' — cut in the middle of the word, with nothing to signal that it is mid-word.

Two consequences for the client:

Concatenate verbatim. Do not trim, do not insert separators. Trimming the leading space welds English and Arabic words together. The Japanese mid-word split means a word will sit visibly incomplete for about a second, and there is nothing you can do about that.
Switch text direction per bubble. Subtitles go out the way a messaging app looks: one utterance, one bubble. What comes back is the speaker's own language, so in a multilingual meeting a right-to-left bubble and a left-to-right one sit in the same panel. Pick a direction for the whole panel and one of them breaks, so the UI has to decide bubble by bubble (in HTML, dir="auto" on each one).

So the UI limit cannot be a character count

Here is the rule I was about to write: cap the subtitle panel at N characters, drop the oldest.

With a 2× spread in characters per second, that cap buys a different amount of time in every language. Cap at 60 characters and Japanese keeps 10 seconds on screen while English keeps 5. Tune N until Japanese feels right and English scrolls away before you can read it.

Cap by rendered lines instead, and the difference cancels out:

	Characters per second	Characters per line (mobile)	Characters in 3 lines	3 lines ≈
Japanese	6.0 (full-width)	~20	60	~10s
English	12.0	~40	120	~10s
Arabic	9.0	~35	105	~12s

Capping by lines is, of course, still capping by "characters per line × lines". The difference is that you are not the one choosing the characters per line.

Chunks arrive with no line breaks in them. Where the text wraps is decided by the width of the panel and the font — and the panel is the same width in every language, because it is the width of the screen. Fill it with full-width characters and a line holds about 20; fill it with half-width ones and it holds about 40. The character count per line moves by exactly as much as the characters are wide.

That turned out to move in step with the characters-per-second figure. So three lines hold 60 characters in one language and 120 in another, and in time they both come out at 10–12 seconds. The line count was doing the normalization for me.

If the horizontal side follows the font, so should the vertical. Reserve the height of those three lines in font-relative units, not pixels. Arabic, Devanagari and Thai have taller line boxes, and a px-fixed box clips them.

(Three lines rather than three messages, incidentally, because that 14-second utterance came to about 84 characters, which overflows three lines on its own.)

The three-line panel is running here if you want to see whether the reasoning holds up in practice. Turn subtitles on in the toolbar; they are off by default.

What this does not cover

Of the three recordings I measured, only the Japanese one is an actual person speaking.

For English and Arabic I had no audio to work with, so I took the translated speech the model hands back during a Japanese run and fed that in as the input. Which means those two languages are the model talking to itself: clean, no accent, no disfluency, no one talking fast. Real speakers will chunk differently, and the model card itself notes that accents degrade language detection.

Separately from this measurement, I have confirmed that English speech from a real person is transcribed properly. But that is as far as it goes — I did not measure chunk granularity or latency on it. For every other language I have not even checked that much.

I have not measured Chinese, Korean, Thai, or Hindi. The one-second period looks structural rather than tuned, so I would expect it to hold, but that is a guess and I would rather label it as one.

And this is one speaker at a time. What happens when several people hold separate sessions concurrently is a different measurement.

Where this ended up

The tool is called AWAI: people in different languages sit in the same meeting and talk. The subtitles I measured here are on that screen.

And the demo I have linked a few times is not a mock-up made for this post. The code drawing those subtitles is exactly the production code; the only difference is that the data comes from a recorded replay instead of a live channel. Open a real meeting and the same thing runs.

Subtitles, though, only exist during the meeting. What AWAI is actually for is what is left afterwards: the conversation sorted by topic, with who said what on which subject. If subtitles are "what did they just say", that is "what did we actually talk about". The 0.64 seconds I measured here is one instant at the front of it.

Building for more than one language usually gets framed as absorbing the differences between them. Measured, the differences and the sameness fell into two clean piles.

The text on screen differs — the character count, where it breaks, how tall a line is. The rhythm it arrives in does not. And that seems to be less about Gemini than about people exchanging information by voice at roughly the same rate whatever language they use. The writing system varies; the speaking and listening underneath it does not.

That is the part that stuck with me while building a multilingual meeting tool. The thing that matters when two people talk to each other appears to survive the change of language.

And I only saw it because I wired the translation up myself and measured what came back, one piece at a time. Using it would not have shown me that. If you are building on a streaming speech API, measure it for your own use rather than carrying over what you checked before — what you verified with an AI on the other end goes back up for verification the moment you put it between two people.

DEV Community: Hayato Kamiya