See which help center articles have audio in every language

Build me an audio coverage desk for our Intercom help center. The support content team needs one screen that answers a recurring question: which of our help articles have a listenable audio version, in which languages, and which recordings went stale after somebody edited the article.

The main screen is a coverage grid. Rows are our Intercom help center articles, loaded with List All Articles and paginated through with the starting_after cursor. Columns are the target languages we support, which I configure in settings. Every cell shows one of three states: done, missing, or stale. Done means we have an audio file for that article in that language. Missing means we do not. Stale means the article's updated_at in Intercom is newer than the timestamp we captured when we generated that audio file, so the recording no longer matches the text. Intercom timestamps are UNIX epoch seconds, so compare them as numbers. Show a coverage count per row and per column, and an overall coverage percentage at the top.

Let me sort the grid by most viewed articles first, so we narrate the pages that actually matter before the long tail. Intercom does not expose a view count on the article object itself, so source popularity from the content data export instead: Create Content Data Export for a date range, poll Show Content Data Export until the job finishes, then Download Content Data Export, which returns a gzipped CSV of article statistics. Run that from an explicit Refresh popularity button, store the per-article view counts in app state along with the date they were fetched, and reuse them until refreshed. If that export is not available on the workspace's plan, fall back to sorting by most recently updated and say so plainly in the UI. Also offer alphabetical and largest-coverage-gap sorting.

Clicking a missing or stale cell opens a fill panel and runs this pipeline in exactly this order. First, pull the full article body with Retrieve an Article. Second, strip the HTML down to clean readable text, dropping tags, image markup and boilerplate while keeping heading and paragraph boundaries. Third, get the text into the target language BEFORE any audio is generated. This ordering is the thing to get right: Azure AI Speech does not translate, it only synthesizes, so reading English source text with a Spanish voice produces English spoken in a Spanish accent, not a Spanish article. If Intercom already holds a translated version of the article for that locale, use that wording. Otherwise translate the stripped text with the built in AI, and cache the translation so a later re-record does not pay to translate it again.

Fourth, convert the translated text into SSML, because real-time synthesis takes application/ssml+xml. Escape XML entities, set xml:lang and the voice name for the target locale, and insert short breaks at heading boundaries so sections do not run together. Fifth, route by length. Real-time text to speech truncates output audio at ten minutes, so estimate duration from the word count at roughly 150 words per minute. Send anything comfortably under the limit to Synthesize Speech, choosing the audio format with the X-Microsoft-OutputFormat header. Send anything longer to Create Batch Synthesis, which needs a client-chosen synthesisId in the path (3 to 64 characters, letters, digits, dash, underscore or dot, starting and ending alphanumeric), then poll Get Batch Synthesis until the status is Succeeded or Failed. Be conservative with the threshold and route anything over about 1,400 words to batch.

Sixth, get the audio into Google Drive, and do it promptly, because batch synthesis output expires after timeToLiveInHours, which defaults to 168 hours. Drive is what makes the file durable. Upload with Upload File (Multipart) when the file is 5MB or smaller, and switch to Upload File (Resumable) above that, since a long narration will exceed the multipart limit. Give files predictable names such as article-slug-locale.mp3, in a Drive folder I choose in settings. Seventh, call Create Permission with role reader and type anyone to get a shareable link, and store that link on the cell.

After a recording succeeds, let me optionally append an audio player link to the published article with Update an Article. Make this an explicit choice rather than something that always happens, with a global default I can set in settings. When it does run, append to the existing body instead of replacing it, and write into the correct locale's translated content so we never overwrite the English article with a Spanish player link.

Give me a language and voice settings screen. Build the voice picker from List Voices, which exposes locale, gender, styles and sample rates, filtered to the locale being configured, and let me preview a short sample before committing. Let me set and save a default voice per language so pronunciation and tone stay consistent across everything we narrate, storing the chosen voice name and output format. Record which voice was used on each generated file, so I can tell which files predate a voice change.

Let me batch select a whole row (one article across every language) or a whole column (one language across every article) and fill the gaps in one pass. Queue the work, show live per-cell progress, and keep going when a single cell fails rather than aborting the entire run, surfacing the reason on the cell that failed. Pace the queue against the documented limits: Azure batch synthesis allows 100 requests per 10 seconds per Speech resource, and Intercom allows roughly 1,000 requests per minute per app.

Persist, for each article and language pair: the Drive file id and shareable link, the article updated_at captured at generation time (this is what the stale check compares against, so it must be stored at generation, not recomputed later), the voice used, the generated timestamp, the audio duration, and the cached translation. Also persist the target language list, the per-language default voice, the Drive destination folder, and the most recent popularity snapshot. Alongside the grid and the settings screen, include an activity log of recent fill jobs with their status, so the team can see what ran, what failed, and why.