Localizing an App Store Screenshot PSD into 15 Languages Overnight with Cowork

Put the translation itself into each text layer's name

The natural way to localize is to rewrite each text layer's content into the translated string. I do that too, but in addition, I set each text layer's name to the translated string itself.

The reason is so that opening the Photoshop layers panel tells you at a glance "which sentence in which language" you are looking at. If a layer name stays headline_1, you cannot read the content in a language whose glyphs do not render. With the translation in the name, even a language like Thai — whose glyphs my environment lacks and which cannot be rasterized — can still be checked and copied from the panel.

If you are returning a PSD that assumes manual polishing afterward, this small step helps the downstream work the most.

I created a group per language and named each group like th_ไทย or ko_한국어 — the language code plus the language's own endonym. Using the native name rather than the English name (Korean) removes ambiguity when handing each language to a reviewer.

The font and glyph wall — stumbling on Thai and Korean

This is where the real work begins. Even after rewriting the text, if the environment has no font that can draw those glyphs, you get tofu boxes the moment you rasterize. The work environment had restricted networking and could not fetch the Noto fonts, so I first checked how far the already-installed fonts could go.

So I decided that Thai would not be rasterized into the PSD, but kept only in the layer name (the translation) and an Excel handoff. In the end, the 15 Latin-script languages plus Arabic and Chinese rendered, while parts of Thai and Korean were left "name only" due to missing glyphs.

Because the fonts were meant to be swapped to the production set (Noto / IPAex) later, it was more realistic not to chase perfection here but to hand over the file with the swap points clearly marked. Polishing the official look is something you do in an environment where the glyphs are present.

Deciding by count, not by eye

At first I rendered one sample board per language and looked at it on screen to see whether any tofu boxes had appeared. Up to five languages, that was enough.

It fell apart on the twelfth. In the Korean headline exactly one glyph was missing — and at preview zoom I could not tell a dropped glyph from a glyph that simply looks like that. I noticed the next morning and rebuilt that language alone.

So I stopped deciding by eye and started counting before rendering. Open the font's cmap, and check that every codepoint in the string I am about to pour in is actually there.

from fontTools.ttLib import TTFont
 
 
def covered_codepoints(font_path: str) -> set:
    """Return the set of codepoints the font carries in its cmap."""
    font = TTFont(font_path, fontNumber=0, lazy=True)
    points = set()
    for table in font["cmap"].tables:
        points.update(table.cmap.keys())
    font.close()
    return points
 
 
def missing_chars(text: str, covered: set) -> list:
    """Return the characters that cannot be drawn, deduplicated, in order."""
    seen, missing = set(), []
    for ch in text:
        if ch.isspace() or ch in seen:
            continue
        seen.add(ch)
        if ord(ch) not in covered:
            missing.append(ch)
    return missing

DejaVu Sans turned out to carry 5,955 codepoints. The Latin, Cyrillic, and Arabic headlines came back with zero missing; Korean was short 8 characters and Thai 7. The table I had filled in by eye in the previous section now falls out in one pass.

Then Arabic taught me that having the codepoints does not mean you can draw the text. Arabic letters change shape depending on their neighbors, so you need a layout engine that shapes them. If Pillow was built without libraqm, that shaping never runs and you get a picture of disconnected letterforms sitting side by side.

The awkward part is that nothing raises. Only the width quietly shifts.

Measuring the same font, the same string, and the same size, swapping only the layout engine, this is what I got on my machine.

For Latin and Cyrillic the gap stays under 1%, which is just kerning. Arabic comes out 28.2% wider. The auto-shrink I add in a later section works off measured width, so trusting a width measured in an unshaped environment means shrinking lines that never needed shrinking.

So I folded the codepoint check and the double width measurement into one function.

from PIL import ImageFont
 
# If shaped and unshaped widths diverge by at least this much, a human confirms the shrink decision
SHAPING_GAP_PCT = 3.0
 
 
def widths(text: str, font_path: str, size: int) -> tuple[int, int]:
    """Return the drawn width without shaping (BASIC) and with it (RAQM), side by side."""
    out = []
    for engine in (ImageFont.Layout.BASIC, ImageFont.Layout.RAQM):
        font = ImageFont.truetype(font_path, size, layout_engine=engine)
        out.append(font.getbbox(text)[2])
    return out[0], out[1]
 
 
def preflight(lang: str, text: str, font_path: str, size: int, covered: set) -> dict:
    missing = missing_chars(text, covered)
    if missing:
        return {"lang": lang, "verdict": "name-only", "missing": missing, "width": None, "gap": None}
 
    basic, raqm = widths(text, font_path, size)
    gap = round((basic - raqm) / raqm * 100, 1) if raqm else 0.0
    # A few percent is letter spacing. A double-digit gap means the language depends on shaping itself
    verdict = "raster+eye" if abs(gap) >= SHAPING_GAP_PCT else "raster"
    return {"lang": lang, "verdict": verdict, "missing": [], "width": raqm, "gap": gap}

There are only three verdicts. name-only means skip the raster and hand the text over through the layer name and Excel; raster means draw it as-is; raster+eye means draw it, then have a person look at exactly one exported board. Run against my headline strings, English, German, and Russian came back raster, Arabic raster+eye, Korean and Thai name-only — the same ordering I had written into the table by hand.

The difference is only what happens when the next language arrives. Adding a sixteenth means I look at the rows that landed in raster+eye, and nothing else.

Codepoint coverage decides whether it can be rastered; shaping decides whether it needs my eyes. Since splitting it into those two stages, I have not rebuilt a language over glyphs once.

Kill the "do nested groups survive a save-and-reopen" risk on a small file

Onto the nested structure of five artboards x per-language groups, I add new pixel layers (the rasterized translations). Editing a complex hierarchy with psd-tools can corrupt the structure when you save and reopen. On a 220MB production file, where saving alone takes minutes, you would notice that far too late.

So before the production run, I verified on a tiny PSD that "add a pixel layer into a nested group + subgroup, save, then reopen" was safe.

from psd_tools import PSDImage
 
def verify_roundtrip(path: str, expected_boards: int) -> None:
    """Reopen a saved PSD and check mechanically that the structure survived."""
    psd = PSDImage.open(path)
    boards = [l for l in psd if l.kind == "group"]
    assert len(boards) == expected_boards, f"artboards: {len(boards)} != {expected_boards}"
 
    added = [l for l in psd.descendants() if l.kind == "pixel" and l.name.startswith("t_")]
    assert added, "the pixel layers we added are gone after reopen"
    for l in added:
        assert l.bbox != (0, 0, 0, 0), f"{l.name} lost its coordinates"
 
    print(f"ok: boards={len(boards)} added_layers={len(added)}")
 
verify_roundtrip("mini_test.psd", expected_boards=5)

Writing the assertions removes any room to glance at the output and call it "probably fine." Only after confirming that the five artboards were preserved and that the added layers' kind and coordinates read back correctly did I proceed to the production build. The heavier the operation, the more it pays to do one round trip on a miniature first.

psd-tools fails on non-ASCII layer names (the mac_roman problem)

The rendering itself passed, but saving threw an error. The cause: psd-tools tries to write layer names in the legacy mac_roman encoding, so names containing non-ASCII characters like 한국어 or Русский failed to encode.

This trap collided head-on with my plan to put translations and endonyms into the layer names.

A PSD layer name is actually a dual structure. One is the legacy Pascal string in the layer record (ASCII-oriented, written as mac_roman). The other is the luni (Unicode Layer Name) additional-info block, which holds UTF-16BE correctly. Photoshop prefers luni when reading.

In other words: put a safe ASCII placeholder in the legacy slot, write the real name into luni, and both saving and display work.

from psd_tools.psd.tagged_blocks import TaggedBlocks, TaggedBlock
from psd_tools.constants import Tag
import re
 
def safe_ascii(name: str, index: int) -> str:
    """For the legacy slot: drop non-ASCII, fall back to a serial name if empty."""
    ascii_only = re.sub(r"[^\x20-\x7E]", "", name).strip()
    return ascii_only or f"layer_{index}"
 
def set_layer_name(record, name: str, index: int) -> None:
    """Legacy name stays ASCII; the real name goes into luni (UTF-16BE)."""
    record.name = safe_ascii(name, index)          # only values mac_roman can encode
 
    blocks = record.tagged_blocks or TaggedBlocks()
    blocks[Tag.UNICODE_LAYER_NAME] = TaggedBlock(
        key=Tag.UNICODE_LAYER_NAME,
        data=name,                                  # 'ko_한국어' verbatim
    )
    record.tagged_blocks = blocks
 
for i, (record, translated) in enumerate(zip(layer_records, translations)):
    set_layer_name(record, translated, i)

Since separating the two, saving has never failed once. If you choose a design that "puts multiple languages into the names," this save path is the one thing to verify first. Two of my three rebuilds traced back to this single point.

Translations overflow — adding auto-shrink to the font size

Japanese headline copy is short, and the same meaning in English or German is reliably longer. Render an overflowing layer as-is and the text either clips or collides with the element beside it.

So I added a step that steps the font size down until it fits, with a floor at 50% of the original. Below that, a screenshot stops being readable.

from PIL import ImageFont
 
MIN_SCALE = 0.50
STEP = 0.95
 
def fit_font(text: str, font_path: str, base_size: int, max_width: int):
    """Return the largest font size that fits max_width, or None if it never fits."""
    size = base_size
    floor = int(base_size * MIN_SCALE)
 
    while size >= floor:
        font = ImageFont.truetype(font_path, size)
        width = font.getbbox(text)[2]
        if width <= max_width:
            return font, size, size < base_size   # (font, actual size, was it shrunk)
        size = int(size * STEP)
 
    return None, floor, True   # does not fit even at the floor -> hand back to a human

The third return value is the point. I log only the places where shrinking happened, so they can be eyeballed afterward.

Of 31 total edits, 2 to 11 locations per language ended up shrunk; languages with long words, like English and German, needed more. Nothing failed to fit even at the 50% floor this time, but when it does, the function returns None, halts the run, and pushes the decision — shorten the translation itself — back to a human. Deciding in advance where automation stops is what keeps it from quietly making bad calls.

I also standardized how numbers appear across languages: small badges read "100K+" while big headlines read "100,000+". All 16 languages' translations are laid out side by side in an Excel file. The pipeline for producing that kind of tabular summary in Cowork is the same one described in Cowork x Python data analysis automation.

Folding the work into five steps

Looking back on that night, the reproducible procedure folds into five steps. Next time I swap screenshots, following this order removes all hesitation.

1. Fix the canonical file: if several PSDs arrive, pick one by resolution and size (here, 1440x13333px, 220MB)
2. Dump the structure: count artboards and text layers with psd-tools (5 boards x ~40 layers)
3. Pre-judge glyphs and shaping: sort every language into raster, raster+eye, or name-only using the cmap check and the double width measurement
4. Verify saving on a small PSD: make sure adding layers into nested groups survives a reopen
5. Build and export: render with translations in the layer names, then export per-store sizes

Glyphs rendered cleanly for 13 of 15 languages, about 87%. The remaining two (Korean and Thai, about 13%) were left name-only due to missing glyphs and pushed to a finishing pass in an environment with the fonts present.

Seeing it as a ratio makes the boundary explicit: how far automation reaches, and where manual work begins. I strongly recommend deciding up front where you stop and hand the file to a human. Chase perfection across every language in one pass and you will usually stall at the glyph wall.

Exporting for Play Console and App Store Connect

The polished PSD is finally resized and exported to each store's recommended dimensions. Google Play Console and App Store Connect demand different aspect ratios and pixel counts, so preparing a process that generates multiple sizes from one master makes the next version's screenshot swap reusable as-is.

This time I kept the master PSD as the source of truth and automated export as a language x size product. Pushing the exported images into the store connects to the flow I described in Automating App Store Connect with Claude in Chrome.

This kind of "putting it on the shelf" work is exactly where systematization pays off most. The substance of an app I make by hand, while the layout that carries it to people around the world I hand to the tooling to buy back time — that line is, for me, the realistic landing point for running multilingual store operations as an individual.

Update — the editable PSD as a landing point

The work continued after I wrote this, with a few steps forward.

The glyph problem I started with was resolved not by rasterizing directly into the PSD, but by switching to exporting an editable PSD with live text layers (localized_editable.psd). The flow is: drag each language's group into the original screenshot PSD, hide the Japanese layers, swap the font, then export. Whether the glyphs render is confined to the final font-application step.

For that font swap, I prepared a per-language recommended-font cheat sheet (FONT_GUIDE.md). It maps the design's Bold, Medium, and Light weights to Noto Sans / Noto Sans KR, SC, TC, Thai, and Arabic, with IPAexGothic for Japanese. For a unified look across languages, standardizing on the Noto family felt safest.

In the end I reviewed all 16 languages and confirmed there are no mistranslations and that the app name follows the official ASO name (with only minor wording variance between a category label and body text in Russian, not a meaning error).

What I feel having reached this point is that, rather than chasing a perfect raster in a constrained environment, handing things over as "an editable state plus a font-swap instruction sheet" is in the end the fastest and most reliable. Set the exit of your automation at "something a human can finish," not at "the finished thing." That alone removes one place to get stuck.

If you want to try this next, start by handing one PSD to Cowork and dumping the list of its text layers. How many artboards, how many strings? The moment you see those numbers, the reason not to do it by hand becomes obvious.