Pseudo-translate a file

Pseudo-translation fills every target with a deliberately mangled copy of its source so you can run the product in a "foreign" language before a single word has been translated. This page does the whole job in the tab: the file is parsed, rewritten and handed straight back as a download. Nothing is uploaded, and your original file is not modified.

Each target becomes [!! + the accented source + about thirty percent padding + !!]. Vowels and n gain accents, case is preserved, placeholders and inline tags are copied through untouched, and every rewritten segment is set to draft.

When you need this

Run it the day the resource file is first extracted, and again before every release that touches the UI. It answers three questions no code review answers reliably: which strings never made it into the resource file, which layouts collapse when the text grows, and which fonts are missing glyphs. All three are cheap to fix in development and expensive to fix after a translator has already worked on the file.

It is also the fastest sanity check on a filter you just configured: a segment without brackets is a segment the filter is not extracting.

Steps

  1. Drop the file. Drop an XLIFF, SDLXLIFF, MQXLIFF, XLSX or CSV file on the zone above. It is parsed, mangled and re-written in this tab, and downloads as name.pseudo.ext.
  2. Read the counter. The line under the drop zone says how many segments were rewritten. Locked segments and empty sources are skipped, so it is lower than the segment count.
  3. Put it through your normal pipeline. Import the pseudo file back into the tool or build that produced the original, and generate the application or document exactly as you would for a real language.
  4. Look at the result. Any string without the [!! and !!] brackets is hard-coded. Clipped text is a layout that cannot take the expansion; empty boxes are glyphs the font lacks.
  5. Fix and run it again. The output is deterministic, so re-running over the same source produces an identical file and a diff shows only the strings that actually changed.

What to check afterwards

Both brackets have to be visible on screen. A missing [!! means the string was concatenated onto something else; a missing !!] means it was truncated. That is what the markers are for.

In the file, confirm that placeholders came through byte-for-byte: {name}, %1$s, {{count}} and the rest are recognized by the same code the QA placeholder check uses, and accenting them would turn a layout test into a crash. Inline tags are reused as their original markup, so the pseudo file still round-trips.

The gotcha

The expansion is measured on translatable characters only. Placeholders and tags do not grow when a real translator gets the file, so padding for them would overstate the case — but it also means a placeholder-heavy string barely grows. Hello {name}, you have {n} messages gains padding for the words and none for the tokens, and the German rendering will be longer than the pseudo version. For strings you know are tight, test with a real sample.

The same caution applies to scripts: accented Latin proves your font has accented Latin. It says nothing about CJK, Arabic, Hebrew or Indic coverage, or about right-to-left mirroring — for those, put a real sample in the UI. And keep the pseudo file out of the delivery chain: the draft state and the .pseudo in the filename are there so no translation memory ever absorbs it.

What XLIFF 2.0 changes about units, segments and inline tags