After I started pulling screenshots from the store, in store order, the source was clean. Then I was watching a Japanese-channel video and noticed something off — the captions were Japanese, but the UI inside the phone was Korean.
The locale gap
The app-download shorts are built like this: screenshots come from a shared base (the Korean App Store cuts), and per-language hooks and captions are overlaid on top. The screenshots themselves were shared. So a Japanese short was a Korean app screen with Japanese captions.
Digging in, it was dumber than that. The code that fetches screenshots from ASC had a locale preference of ["ko", "en-US", ...] and grabbed only the first match. Japanese was never even asked for. And yet 34 of 41 apps had already uploaded Japanese App Store screenshots. The source had been sitting there the whole time; the pipeline just never requested it.
The fix: request the locale, fall back if missing
I changed screenshot collection from a single ko pick to also pulling ja — Korean stays on the existing path, Japanese lands additionally in shots_asc/<slug>/ja/. At render time, if the language is Japanese the cut path is swapped to the Japanese screenshot, and the 4 apps with no Japanese cuts fall back to Korean.
One run pulled in 143 Japanese screenshots across 34 apps. Zero store work — it was a pure pipeline defect. Already-published videos stay as-is; new content ships with Japanese screens from here.
The honest part
As with the dead /ja links post, localization isn't "translate and done." The real trap wasn't a missing asset — it was an asset that existed but went unused. When a pipeline treats one language as the first-class citizen, the others quietly inherit that language's screens. In a pipeline that fans out per language, every stage has to ask "am I actually requesting this language's assets?" The assets were already there.