“Can you convert this PDF to Word?” sounds like a five-minute job. It rarely is. A PDF is a picture of a document: the text may be embedded, scanned, split into columns, or trapped inside text boxes. Converting it to Word is not a format change; it is a layout reconstruction.

This is the workflow I use when a client sends a PDF that needs to become an editable Word file without losing tables, headers, footnotes or numbering.

## Step 1: Inspect the PDF before converting

Open the PDF and check:

- Is the text selectable, or is it a scan?

- Is it one column or two?

- Are there tables, charts, footnotes or endnotes?

- Are there headers, footers and page numbers?

- Are there text boxes, sidebars or callouts?

- What fonts are embedded?

The answers determine the tool and the amount of manual work. A one-column text PDF is easy. A two-column annual report with footnotes is a different project.

## Step 2: Extract the text

For a text-based PDF, use a PDF-to-text tool or the “copy text” function to get the raw content. For a scanned PDF, run OCR first. Check the OCR output for:

- broken line breaks

- merged words

- misread numbers

- lost accents and special characters

- table cells read in the wrong order

Do not paste OCR output directly into the final Word file. Clean it first.

## Step 3: Rebuild the document with styles

Create a new Word document and define styles before pasting content:

- Heading 1, Heading 2, Heading 3

- Body text

- Table text

- Caption

- Footnote text

Using styles makes the document editable and consistent. If you paste formatted text from the PDF, you will spend more time removing inconsistent fonts and spacing than you saved.

## Step 4: Rebuild tables cell by cell

Tables are where most conversions fail. Recreate each table in Word, then check:

- column widths

- header row repetition across pages

- cell padding

- merged cells

- number alignment

- whether the table breaks across pages cleanly

If the table is complex, consider rebuilding it as a Word table rather than an image. A table that cannot be edited is not a real conversion.

## Step 5: Restore headers, footers and page numbers

Add the running header, footer, page numbers and section breaks. Check that:

- the first page is different if needed

- page numbering starts at the right number

- headers do not overlap the body text

- footnotes stay with the correct page

## Step 6: Handle images and captions

Extract images at the highest available resolution. Place them in the Word file, add captions, and check that the text wraps correctly. If the PDF contains charts, decide whether to keep them as images or rebuild them as editable charts. Rebuilding is better for data-heavy documents, but it takes longer.

## Step 7: Compare the two documents side by side

Put the PDF and the Word file next to each other and compare:

- page count

- heading hierarchy

- table structure

- line breaks in headings

- footnote numbering

- image placement

- special characters

Fix the differences that affect meaning or readability first. Cosmetic differences in line breaks are usually acceptable; a missing footnote is not.

## Step 8: Deliver both formats

Send the client:

- the editable `.docx`

- a PDF export for review

- a short note listing any intentional differences (for example, “the original used a non-standard font; I substituted Source Han Serif”)

This prevents a round of “why does it look different?” emails.

## Common problems and fixes

**Scanned PDF with no text layer.** Run OCR, then proofread the output. Do not trust OCR for numbers, names or tables.

**Two-column layout.** Extract each column separately, or use a PDF tool that preserves reading order. Pasting the whole page into Word will interleave the columns.

**Text in boxes.** Rebuild the box as a single-cell table or a text frame. Do not leave the text as a floating image.

**Ligatures and special characters.** Check `fi`, `fl`, `ff`, dashes, curly quotes and non-breaking spaces. Replace them with the correct Unicode characters.

**Footnotes that become endnotes.** Recreate them as Word footnotes and check the numbering.

## What to charge for

A simple text PDF conversion is a small job. A scanned, multi-column, table-heavy document is not. Quote based on:

- page count

- text vs scan

- number of tables and figures

- footnotes and cross-references

- whether the layout must match exactly

If the client says “just convert it,” ask for a sample page first. One page tells you more than a 40-page brief.

---

*I am Alex Chen, a freelance translator and localization specialist. I also handle PDF-to-Word reconstruction for translated documents. If you have a PDF that needs to stay readable after conversion, email me at changhaodai188@gmail.com.*

Most Chinese localization bugs are not translation mistakes. They are review-process mistakes: a placeholder that was never checked, a string that only appears after a failed payment, a Traditional Chinese character hiding in a Simplified build.

This is the QA workflow I use for EN→ZH SaaS and e-commerce content. It is designed for small teams that do not have a dedicated localization department.

## Step 1: Freeze the source and build a glossary

Before translating a word, confirm that the English source is final. Then build a short glossary for the terms that appear on every screen:

| English | Chinese | Note |

|---|---|---|

| workspace | 工作区 | one term everywhere |

| dashboard | 仪表盘 | not 控制台 |

| plan | 套餐 | pricing page |

| seat | 席位 | user management |

| invoice | 发票 | billing |

If the glossary is missing, stop and create one. It is the cheapest QA tool you have.

## Step 2: Translate with context, not just strings

A translator needs to know where a string appears: button, tooltip, error message, email subject, legal page. If you only provide a CSV with keys and English text, the translator will guess. Attach screenshots or a staging link, and mark the strings that have length limits.

## Step 3: Do a bilingual review

The reviewer compares the English and Chinese side by side and checks:

- meaning and tone

- terminology consistency

- placeholders and variables

- numbers, dates and currency

- untranslated English

- mixed Simplified/Traditional characters

This is the step where most defects are found. Do not skip it because the translator is experienced.

## Step 4: Do a monolingual read-through

Hide the English and read only the Chinese. Does it sound like a product a Chinese user would actually use? This catches translationese: sentences that are grammatically correct but sound like they were translated. Common examples:

- 过多的“您的” (overusing “your”)

- 直译的被动句

- 英文语序的长定语

- 不自然的按钮文案

## Step 5: Back-translate critical strings

For checkout, payment, legal and security strings, have a second person translate the Chinese back into English without seeing the source. If the meaning changes, the string needs another pass. This is slower, so reserve it for the strings where a mistake is expensive.

## Step 6: Test in context

Open the Chinese build and use it like a customer:

- sign up

- add a payment method

- trigger a validation error

- change a plan

- cancel a subscription

- open the mobile menu

Check truncation, line breaks, text alignment and whether the Chinese punctuation looks right inside buttons.

## Step 7: Log defects in one place

Use a simple defect log with these columns:

| Screen | String key | Source | Target | Severity | Owner |

|---|---|---|---|---|---|

| Checkout | checkout.pay | Pay now | 立即支付 | High | Translator |

Severity matters. A broken placeholder on checkout is a release blocker; a slightly awkward tooltip is not. Do not let a long tail of low-severity issues delay the launch.

## Common defects I see most often

1. **Broken placeholders** — `{name}` becomes `{名称}` or disappears.

2. **Truncated UI** — the Chinese string is shorter, but the button is narrower.

3. **Mixed variants** — one Traditional character in a Simplified build.

4. **Untranslated strings** — error messages, emails and empty states are missed.

5. **Wrong tone** — casual English becomes overly formal Chinese, or vice versa.

6. **Number and date errors** — `1,000` becomes `1.000`, or the date order flips.

7. **Punctuation mixing** — English commas inside Chinese sentences.

## A lightweight QA stack

You do not need enterprise software to start. A spreadsheet for the glossary, a shared defect log, screenshots of the main flows, and one reviewer who reads Chinese natively will catch most issues. Add a placeholder-check script when you can; it pays for itself on the first release.

## What “done” looks like

A Chinese build is ready when:

- every placeholder matches the source

- the glossary is applied across the product

- no English UI strings remain

- the main flows work on desktop and mobile

- a native Chinese reviewer has signed off

- the defect log is closed or explicitly deferred

---

*I am Alex Chen, a freelance translator and localization specialist working from English and Russian into Simplified Chinese. If you need a Chinese QA pass before launch, email me at changhaodai188@gmail.com.*

Shipping a Chinese version of your SaaS product is not a word-for-word swap. It is a product change: the UI gets shorter, the punctuation changes, the way users scan a screen changes, and a single broken placeholder can make a checkout page unusable.

I have been translating and reviewing EN→ZH SaaS, e-commerce and technical content for the past two years. This is the checklist I use before a Chinese build goes live.

## 1. Protect every placeholder and variable

Check `{name}`, `{{count}}`, `%s`, `%d`, `<strong>` and any custom tokens before and after translation. A translator can accidentally translate the token itself, duplicate it, or drop it. Run a script that compares the source and target token sets, and fail the build if they differ.

## 2. Check string length in the actual UI

Chinese is often shorter than English, but not always. Button labels, tabs, table headers and mobile cards can still overflow. Test with the longest strings in the product, not the shortest. Pay special attention to:

- onboarding tooltips

- pricing tables

- error messages

- date pickers and filters

## 3. Build a glossary before translating

Pick one Chinese term for each core concept and keep it everywhere: workspace, dashboard, plan, seat, invoice, integration, webhook. If the glossary is missing, the same English term will become three different Chinese terms across the product.

## 4. Choose Simplified or Traditional — and never mix

A single string in the wrong variant looks unprofessional. Decide the target variant at the start, put it in the brief, and run a variant check at the end. Do not let a machine translation engine silently switch variants mid-project.

## 5. Localize dates, numbers, currency and units

`10/12/2026` is ambiguous. Use an explicit format such as `2026年10月12日` for Chinese UI. Check:

- decimal separators

- currency symbols and placement

- file sizes (MB/GB)

- time zones

- percentage formatting

## 6. Handle plurals and counters correctly

Chinese does not mark plural nouns the same way English does, but ICU plural rules and measure words still matter. Check strings such as `1 file` / `2 files`, `1 seat` / `5 seats`, and any counter with a number. Do not leave English plural logic in the Chinese string.

## 7. Use full-width Chinese punctuation consistently

Chinese sentences use `，。！？：；` rather than `, . ! ? : ;`. Mixed punctuation is one of the most common signs of an unfinished localization. Also check quotation marks and brackets, and remove spaces that only exist because of the English source.

## 8. Decide what stays in English

Product names, API terms, code snippets, keyboard shortcuts and brand names often stay in English. Write this down. If the rule is “translate feature names but keep the product name,” make sure the whole build follows it.

## 9. Localize screenshots, onboarding images and alt text

A translated UI with English screenshots is still an English product. Update:

- onboarding images

- empty-state illustrations with text

- help-center screenshots

- image alt text

- video subtitles

## 10. Review legal and consent strings separately

Privacy policy, terms of service, cookie consent and payment consent need a careful human review. Do not let a UI translator improvise legal wording. Use a reviewer who has seen the Chinese legal text before, and keep the English and Chinese versions aligned.

## 11. Do in-context QA, not just file QA

A translation can be correct in a spreadsheet and wrong on the screen. Test the Chinese build in staging:

- create an account

- complete checkout

- trigger validation errors

- open every settings tab

- check mobile layouts

## 12. Keep a defect log and a sign-off

Record every issue with the screen, string key, source text, target text and severity. At the end, get a written sign-off from the product owner. This protects both sides and gives the next translator a useful history.

## A quick pre-launch pass

If you only have one hour, do these five things:

1. Compare placeholder sets.

2. Search for English leftovers.

3. Check the top 20 screens at mobile width.

4. Verify dates, prices and plural strings.

5. Read the checkout and error states out loud.

---

*I am Alex Chen, a freelance translator and localization specialist working from English and Russian into Simplified Chinese. If you are shipping an EN→ZH product and want a second pair of eyes, email me at changhaodai188@gmail.com.*