integrate the skills
split the review skills into self- and other- the self- variant makes informational comments the other- variant makes nice comments Google docs is a failure
This commit is contained in:
iacore
@@ -1,26 +1,18 @@
|
||||
---
|
||||
name: translation-review-comment
|
||||
description: Editorial polish pass for CN→EN Buddhist translation — voice, flow, readability. Applies patterns distilled from 473 editor comments across 3 manuscripts. Use AFTER translation-review for terminology/accuracy checks.
|
||||
name: other-review
|
||||
description: Editorial polish for CN→EN Buddhist translations you did NOT translate — voice, flow, readability. Load self-review first for terminology/accuracy.
|
||||
---
|
||||
|
||||
# Translation Review — Comment (Editorial Polish)
|
||||
{% Serves AGENTS.md Workflow B2 (Other-Review) %}
|
||||
|
||||
Editorial polish for CN→EN Buddhist translation manuscripts. Focuses on voice, flow,
|
||||
and readability — the layer beyond terminology and accuracy. Distilled from 473
|
||||
editor comments by Wade across 3 manuscripts:
|
||||
# Other-Review — Editorial Polish（审他稿）
|
||||
|
||||
| Document | Comments | Period |
|
||||
|----------|----------|--------|
|
||||
| 61 人生佛教在当代的弘扬 | 121 | 2026-06-19–20 |
|
||||
| 附录 我的判教观 | 151 | 2026-06-13–16 |
|
||||
| 16 觉醒的艺术 | 201 | 2026-04-17–05-24 |
|
||||
Review someone else's CN→EN translation. Focus on voice, flow, readability.
|
||||
You did NOT translate this — suggest, don't command. Load `self-review` first
|
||||
for terminology/accuracy checks.
|
||||
|
||||
## When to Use
|
||||
|
||||
After `translation-review` (terminology, accuracy, line parity). This skill targets the
|
||||
"Pass 3" layer — does the English read as natural prose, or as translationese?
|
||||
|
||||
Apply to `.dj` files with `patch` or to Google Docs comment threads.
|
||||
Do NOT edit `bilingual.dj` — output to `review-comments.dj` instead.
|
||||
Use `patch` (mode='replace') for any file edits — not regex-replace.
|
||||
|
||||
## Core Principles
|
||||
|
||||
@@ -35,6 +27,14 @@ Three principles drive all the specific rules below:
|
||||
content that is. But restructure freely for natural English flow — don't mirror
|
||||
Chinese word order when it produces awkward English.
|
||||
|
||||
These patterns were distilled from 473 editor comments across three manuscripts:
|
||||
|
||||
| Document | Comments | Period |
|
||||
|----------|----------|--------|
|
||||
| 61 人生佛教在当代的弘扬 | 121 | 2026-06-19–20 |
|
||||
| 附录 我的判教观 | 151 | 2026-06-13–16 |
|
||||
| 16 觉醒的艺术 | 201 | 2026-04-17–05-24 |
|
||||
|
||||
## Rule Checklist
|
||||
|
||||
Apply these in order. Each rule includes the signal (what to look for) and the fix
|
||||
@@ -401,7 +401,7 @@ This matters for three reasons:
|
||||
any criticism. The translator should feel their effort is seen and valued
|
||||
3. It names the translator explicitly — "随喜师兄" — making the praise personal,
|
||||
not generic. When reviewing, use the translator's name from the document title
|
||||
(e.g. 妙蕊, 法轩, Fiona)
|
||||
(e.g. from the document title)
|
||||
|
||||
## Workflow
|
||||
|
||||
@@ -475,7 +475,7 @@ Quoted text: `even discarded. Consequently, while countless companies emerged, t
|
||||
|
||||
## Pitfalls
|
||||
|
||||
- Don't apply this skill before `translation-review` — terminology must be correct first.
|
||||
- Don't apply this skill before `self-review` — terminology must be correct first.
|
||||
- Don't over-correct: some formal constructions are appropriate for certain passages.
|
||||
Judge per context.
|
||||
- When converting nouns to verbs, keep the meaning intact — don't simplify away
|
||||
@@ -1,11 +1,20 @@
|
||||
---
|
||||
name: translation-review
|
||||
description: Review Chinese-English translations for quality issues - terminology, grammar, consistency, formatting. Two workflows - CSV/XLSX batch review (write .dj suggestions) and .dj comparison line-by-line review (surgical patching).
|
||||
name: self-review
|
||||
description: Review your own CN→EN translations — three-pass review (terminology → mechanical → flow). Edit commented.dj with patch. For reviewing someone else's work, load other-review.
|
||||
---
|
||||
|
||||
# Translation Review
|
||||
{% Serves AGENTS.md Workflow B1 (Self-Review) %}
|
||||
|
||||
Two workflows, used depending on input format.
|
||||
# Self-Review（自审）
|
||||
|
||||
Review YOUR OWN translations. You created the English — you can edit freely.
|
||||
For reviewing someone else's work, load `other-review` instead.
|
||||
|
||||
Two input formats: CSV/XLSX batch, or `.dj` comparison file.
|
||||
|
||||
`bilingual.dj` is script-generated ground truth — **never edit it.**
|
||||
Copy to `commented.dj` for all review work. Always use `patch` (mode='replace')
|
||||
for edits — not regex-based string replacement in `execute_code`.
|
||||
|
||||
## Workflow A: CSV/XLSX batch review
|
||||
|
||||
@@ -54,25 +63,15 @@ translated: <current English>
|
||||
|
||||
One entry per problem category, not per row. Mention affected row numbers.
|
||||
|
||||
## Workflow B: .dj comparison file review
|
||||
## Workflow B: .dj file review (self-review)
|
||||
|
||||
Use when input is a `.dj` comparison file (Chinese/English alternating line pairs).
|
||||
Use when you translated the text and want to review your own work.
|
||||
|
||||
### Two modes — always clarify which one
|
||||
### File rules
|
||||
|
||||
AGENTS.md defines two workflows. Before starting, determine which mode you're in:
|
||||
|
||||
1. **Translation review** (Workflow A in AGENTS.md): agent translated the text.
|
||||
Authoritative `target.dj` does not exist yet. Review everything:
|
||||
terminology, grammar, formatting, consistency, calques, missing content.
|
||||
Produces `translation-findings.dj` and applies patches.
|
||||
|
||||
2. **Proofread** (Workflow B in AGENTS.md): English comes from an existing DOCX
|
||||
manuscript. It is authoritative. Only flag manuscript-level mechanical issues:
|
||||
typos, double words, numbering mismatches, garbled text, duplicate text.
|
||||
Produces `edit-suggestions.dj` ONLY — do NOT apply patches without asking.
|
||||
Do NOT flag: terminology choices, djot formatting,
|
||||
translation style, calques, word order. These are translation-review concerns.
|
||||
1. `bilingual.dj` — extracted from script. **Never edit.**
|
||||
2. `cp bilingual.dj commented.dj` — all edits go here
|
||||
3. `{% ... %}` comments document non-obvious translation choices
|
||||
|
||||
### 1. Read the full file
|
||||
|
||||
@@ -119,7 +118,9 @@ category of error. Don't try to catch everything in one scan.
|
||||
- Fix both glossary comments AND body text
|
||||
- See `references/terms-db-alignment.md` for batch-lookup patterns
|
||||
|
||||
### 3. Dump findings to `translation-findings.dj`
|
||||
### 3. Dump findings
|
||||
|
||||
Write to `translation-findings.dj` for issues that don't fit as inline fixes:
|
||||
|
||||
```
|
||||
Finding N — Title (line numbers)
|
||||
@@ -130,29 +131,14 @@ Finding N — Title (line numbers)
|
||||
|
||||
### 4. Apply fixes with `patch`
|
||||
|
||||
Surgical string replacement. Verify every patch with `cat` — never rely on `read_file` (session dedup).
|
||||
Surgical string replacement in `commented.dj` with `patch` (mode='replace').
|
||||
Never use regex-based string replacement in `execute_code` for .dj edits.
|
||||
`patch` is safer, surfaces conflicts, and produces a reviewable diff.
|
||||
Verify with `cat` — never rely on `read_file` (session dedup).
|
||||
|
||||
### 5. Add inline translation notes to bilingual.dj
|
||||
### 5. Add inline edit suggestions
|
||||
|
||||
After findings are written, insert djot comments (`{% ... %}`) into `bilingual.dj` after translation pairs to document non-obvious translation decisions. This serves as a durable reference for future editors and bilingual readers.
|
||||
|
||||
What to annotate:
|
||||
- **Terminology choices**: why a particular rendering was chosen (e.g. 人生佛教 → "Buddhism for Human Life" vs "Humanistic Buddhism")
|
||||
- **Cultural bridges**: how an idiom or reference was adapted for English readers (e.g. 天龙八部 → expanded to "devas, nāgas, and the rest of the eight classes of beings")
|
||||
- **Structural decisions**: heading patterns, name handling, parallelism preservation
|
||||
- **Sanskrit handling**: which terms get diacritics, which get glosses, why
|
||||
|
||||
Format:
|
||||
```
|
||||
source line
|
||||
target line
|
||||
{% explanation of translation choice %}
|
||||
(blank)
|
||||
```
|
||||
|
||||
The comment sits on its own line between the target line and the blank separator. Use `execute_code` to insert comments programmatically — key by source line number (1-indexed), build new file line by line. Verify with `head`/`tail`.
|
||||
|
||||
Do NOT annotate literal/obvious translations (names, dates, simple connectives). Aim for ~1 comment per significant pair.
|
||||
Copy `bilingual.dj` → `commented.dj`, then apply inline corrections + `{% %}` comments.
|
||||
|
||||
### 6. Final sweep
|
||||
|
||||
@@ -204,8 +190,11 @@ Do not run extraction pipelines until scope is clear.
|
||||
- **InDesign PDFs insert extra spaces** around drop caps and special characters.
|
||||
Normalize multi-space to single space before comparison.
|
||||
|
||||
## Pitfalls
|
||||
### Pitfalls
|
||||
|
||||
- **Never edit `bilingual.dj`** — it's script-generated ground truth. Copy to `commented.dj` first.
|
||||
- **Use `patch`, not regex** — for all `.dj` edits. `patch` surfaces conflicts and produces diffs.
|
||||
- **`commented.dj` comments must not split paragraphs** — always place `{% %}` after the FULL EN paragraph, not mid-sentence. Scan for merged comments after insertions and split them. Collapse triple+ blank lines created by comment insertions.
|
||||
- **Clarify scope before diving into extraction pipelines** — if the user says
|
||||
"proofread this" or "校对这篇文章", ask what specifically they want checked
|
||||
before running pandoc/pdftotext. Getting interrupted mid-pipeline wastes
|
||||
@@ -217,7 +206,6 @@ Do not run extraction pipelines until scope is clear.
|
||||
- **Verify patches with `cat`** — `read_file` dedup makes it unreliable
|
||||
- **Re-read before fixing** — user may have made interim edits
|
||||
- **Batch terminology lookups** — when checking many terms against the terms DB, run them in one `execute_code` script that loops over a query list and calls `search.py` via `subprocess.run`. One terminal call per term floods the context with repetitive output.
|
||||
- **Proofread ≠ translation review** — when the user says "校对" or "proofread" and the input is a DOCX manuscript with existing English, you are in proofread mode. Do NOT flag translation quality, terminology, or djot formatting. Do NOT apply patches to bilingual.dj unless asked. Write `edit-suggestions.dj` with manuscript-level issues only. If the user later asks for translation review of the same article, write findings to a separate `translation-findings.dj`.
|
||||
|
||||
## Human Review Protocol (审议)
|
||||
|
||||
@@ -249,6 +237,8 @@ Categories:
|
||||
- `references/terms-db-alignment.md` — Batch-aligning glossary terms against the MPI terms database
|
||||
- `references/translation-pitfalls.md` — Recurring CN→EN mistranslation patterns (关爱→compassion, 生生增上, etc.)
|
||||
- `references/proofreading-patterns.md` — DOCX/PDF extraction techniques, block-based pairing, common manuscript issues
|
||||
- `references/docx-md-extraction.md` — Extracting `.docx.md` (pandoc markdown) to bilingual, TOC guards, CN/EN boundary regex
|
||||
- `references/edit-suggestions-in-bilingual.md` — Inline edit suggestions + `{% %}` comments, two-file comparison (commented.dj / bilingual.dj)
|
||||
- `references/deliberation-protocol.md` — Oriental Translation Workshop review protocol: tiers, rejoicing, tone
|
||||
- `references/common-issues-taxonomy.md` — Structured taxonomy of accuracy and readability issues with examples
|
||||
|
||||
@@ -0,0 +1,171 @@
|
||||
# Extracting `.docx.md` to `source.dj` + `bilingual.dj`
|
||||
|
||||
When the input is a `.docx.md` file (already pandoc markdown, not plain text), the
|
||||
extraction differs from the standard DOCX→plain workflow. The markdown preserves
|
||||
formatting artifacts that need specific handling.
|
||||
|
||||
## CN/EN boundary detection in merged lines
|
||||
|
||||
Pandoc markdown often merges CN and EN text on heading lines where the DOCX had
|
||||
multiple runs in the same paragraph:
|
||||
|
||||
```
|
||||
# **三、重视文化教育，重塑人生价值** Prioritize Cultural Education; Reshape Life Values {#三、...}
|
||||
```
|
||||
|
||||
The boundary regex must account for whitespace on BOTH sides of `**` markers:
|
||||
|
||||
```python
|
||||
# WRONG: \** then \s* — fails when there's space BEFORE * (值 *Realizing)
|
||||
r'[\u4e00-\u9fff](?:\*{0,2})\s*([A-Za-z])'
|
||||
|
||||
# WRONG: \s* then \** — fails when there's space AFTER ** (值** Prioritize)
|
||||
r'[\u4e00-\u9fff]\s*\**([A-Za-z])'
|
||||
|
||||
# CORRECT: whitespace on both sides of optional *
|
||||
r'[\u4e00-\u9fff]\s*\**\s*([A-Za-z])'
|
||||
```
|
||||
|
||||
Include CJK punctuation ranges in the character class:
|
||||
`[\u4e00-\u9fff\u3000-\u303f\uff00-\uffef]`
|
||||
|
||||
## Anchor stripping
|
||||
|
||||
Strip BOTH `{#anchor}` (pandoc heading anchors) AND `[text](#link)` (markdown TOC links)
|
||||
before further processing:
|
||||
|
||||
```python
|
||||
def strip_anchors(s):
|
||||
s = re.sub(r'\{#[^}]*\}', '', s) # {#anchor}
|
||||
s = re.sub(r'\[([^\]]*)\]\([^)]*\)', r'\1', s) # [text](#link) → text
|
||||
return s
|
||||
```
|
||||
|
||||
## TOC handling — two critical guards
|
||||
|
||||
### Guard 1: Don't pair TOC CN entries with following EN lines
|
||||
|
||||
TOC entries often look like CN-heading-followed-by-EN (the standard pair pattern),
|
||||
but the following EN is actually the next TOC entry or heading:
|
||||
|
||||
```
|
||||
[一、营造禅意氛围，优化工作环境\t1](#anchor)
|
||||
[二、重视慈善关爱...]
|
||||
...
|
||||
1、Create a Chan(Zen) Atmosphere; Optimize Your Environment
|
||||
2、Focus on Compassion and Care; Build Good Relationships
|
||||
```
|
||||
|
||||
If the last CN TOC entry is followed by a blank line then the first EN TOC entry,
|
||||
the "CN → blank → EN" heading pattern will consume the first EN TOC entry.
|
||||
Guard against this:
|
||||
|
||||
```python
|
||||
def is_toc_line(line, cn_raw):
|
||||
if re.search(r'\[.*\]\(.*\)', line): # markdown link
|
||||
return True
|
||||
if re.search(r'\t\d+', cn_raw): # tab + page number
|
||||
return True
|
||||
return False
|
||||
```
|
||||
|
||||
Skip the CN→EN and CN→blank→EN patterns when `is_toc_line()` returns True.
|
||||
These CN TOC entries should stay unpaired (en='') and get their EN from the
|
||||
separate EN TOC list.
|
||||
|
||||
### Guard 2: Pair TOC EN entries forward, not backward
|
||||
|
||||
EN TOC entries appear as standalone non-CJK lines. They must be paired with
|
||||
the FIRST unpaired CN (not the last):
|
||||
|
||||
```python
|
||||
# CORRECT: forward iteration
|
||||
for j in range(len(pairs)):
|
||||
if not pairs[j][1] and has_cjk(pairs[j][0]):
|
||||
pairs[j] = (pairs[j][0], en)
|
||||
break
|
||||
|
||||
# WRONG: reverse iteration (pairs last-first, shifting everything)
|
||||
for j in range(len(pairs)-1, -1, -1):
|
||||
...
|
||||
```
|
||||
|
||||
## Orphaned trailing `*` from italic splits
|
||||
|
||||
When a line has italicized EN text (`*Realizing Ultimate Value*`) and the split
|
||||
point is at the `R` (after the opening `*` is consumed by the CN cleanup), the
|
||||
EN text retains a trailing `*`: `Realizing Ultimate Value*`. Strip it:
|
||||
|
||||
```python
|
||||
def clean_en(s):
|
||||
s = re.sub(r'^\d+[、,.]\s*', '', s)
|
||||
s = re.sub(r'\*+$', '', s) # orphaned italic close
|
||||
return s.strip()
|
||||
```
|
||||
|
||||
## `clean_cn` — operation order matters
|
||||
|
||||
Strip leading numbers BEFORE heading markers. A line like `1. # **营造禅意...`
|
||||
starts with a digit, so `^#+\s*\**` won't match until the number is gone:
|
||||
|
||||
```python
|
||||
def clean_cn(s):
|
||||
s = re.sub(r'^\d+\.\s*', '', s) # leading number FIRST
|
||||
s = re.sub(r'^#+\s*\**', '', s) # then heading markers
|
||||
s = re.sub(r'\**\s*$', '', s) # trailing **
|
||||
s = re.sub(r'\t\d+$', '', s) # trailing page number
|
||||
return s.strip()
|
||||
```
|
||||
|
||||
## Full extraction recipe
|
||||
|
||||
1. Read `.docx.md` text
|
||||
2. For each line: strip anchors, detect CJK/EN
|
||||
3. CJK lines: try `split_cnen()` first (merged CN+EN). If that gives EN, use it.
|
||||
Otherwise look ahead for EN on next line or next+blank — but SKIP if TOC-like.
|
||||
4. EN-only lines: pair forward with first unpaired CN.
|
||||
5. Clean: strip heading markers, leading numbers, trailing page numbers.
|
||||
6. Write `source.dj` (CN only) and `bilingual.dj` with proper markdown structure.
|
||||
|
||||
## bilingual.dj output format
|
||||
|
||||
Must follow the project convention (see reference bilingual.dj in any completed article):
|
||||
|
||||
```
|
||||
# CN Title
|
||||
# EN Title
|
||||
|
||||
---CN Subtitle
|
||||
---EN Subtitle
|
||||
|
||||
CN Author
|
||||
EN Author
|
||||
|
||||
- CN TOC item 1
|
||||
- CN TOC item 2
|
||||
...
|
||||
|
||||
- EN TOC item 1
|
||||
- EN TOC item 2
|
||||
...
|
||||
|
||||
CN body paragraph
|
||||
EN body paragraph
|
||||
|
||||
CN section heading ← plain text, no # prefix
|
||||
EN section heading
|
||||
|
||||
...
|
||||
|
||||
CN sub-heading ← plain text, e.g. "1. 创造精神财富"
|
||||
EN sub-heading
|
||||
```
|
||||
|
||||
- Title: `# ` prefix on both CN and EN
|
||||
- Subtitle: `---` prefix (3 dashes, no space after)
|
||||
- Author: plain text, one pair
|
||||
- TOC: `- ` bullet, CN block then EN block (not interleaved), blank line between blocks
|
||||
- Body headings: plain text, no `#` or `##` markers. Hierarchy conveyed by numbering:
|
||||
`一、二、三、` for major sections, `1. 2. 3.` for sub-sections
|
||||
- Body paragraphs: interleaved (CN line, EN line, blank)
|
||||
- `source.dj` uses `# Title`, `---subtitle`, `## section headings` — different from bilingual.dj which uses plain body headings
|
||||
@@ -0,0 +1,65 @@
|
||||
# Edit Suggestions in bilingual.dj
|
||||
|
||||
When the user asks to add edit suggestions directly into bilingual.dj, use this
|
||||
two-tier approach.
|
||||
|
||||
## Two files
|
||||
|
||||
- `bilingual.dj` — clean: inline corrections applied, NO `{% %}` comment lines
|
||||
- `commented.dj` — same content + `{% ... %}` comment lines interleaved
|
||||
|
||||
This lets the user diff them side by side.
|
||||
|
||||
## Inline corrections
|
||||
|
||||
Apply directly to the English text. These are fixes the reviewer is confident about:
|
||||
|
||||
- Typos, mechanical issues (Chinese punctuation in EN, double periods, stray `*`, unbalanced quotes)
|
||||
- Grammar fixes (subject-verb agreement, missing articles)
|
||||
- Wording improvements (clunky literal translations → idiomatic English)
|
||||
|
||||
Apply with `patch` (mode='replace'). Verify uniqueness before
|
||||
replacing — many EN paragraphs are long single lines, so match a unique
|
||||
substring. Never use regex-based string replacement in `execute_code`.
|
||||
|
||||
## `{% %}` comment lines
|
||||
|
||||
For translation decisions worth documenting but not "correct" per se:
|
||||
|
||||
```
|
||||
CN paragraph
|
||||
EN paragraph
|
||||
{% reason for the choice, alternative renderings %}
|
||||
(blank)
|
||||
```
|
||||
|
||||
The comment goes AFTER the EN line (before the blank separator). One comment per
|
||||
issue. Keep them terse.
|
||||
|
||||
What to comment on:
|
||||
- Literal translation of idioms (`单线程` → "single-threaded")
|
||||
- Translation choices that differ from literal meaning (`精神利益` → "nourishing the spirit")
|
||||
- Standard Buddhist terminology (`正命` → "Right Livelihood")
|
||||
- Glosses added/dropped (`道场` — "(Dojo)" parenthetical removed)
|
||||
- Idiom translations (`甘之若饴` → "as sweet as syrup")
|
||||
- Paired terms where one rendering influences the other (`魔性` → "demon-nature" to parallel "Buddha-nature")
|
||||
- Scripture citations with Sanskrit titles (`普贤行愿品` → "Gaṇḍavyūha Sūtra")
|
||||
|
||||
What NOT to comment on:
|
||||
- Obvious corrections (typos, grammar)
|
||||
- Names, dates, simple connectives
|
||||
- Standard renderings with no interesting choice
|
||||
|
||||
## Pitfalls
|
||||
|
||||
- **Never split a paragraph mid-sentence** with a `{% %}` comment. Comments go
|
||||
AFTER the full EN paragraph, before the blank separator. If a string
|
||||
replacement inserts `\n{% %}` in the middle of a paragraph, it breaks the
|
||||
interleaved structure.
|
||||
|
||||
- **Check for merged comments**: after inserting, scan for `{% ... %} ` followed
|
||||
by EN text on the same line. These must be split so the EN text continues on
|
||||
the next line.
|
||||
|
||||
- **Collapse triple+ blank lines**: comment insertions can create extra blanks.
|
||||
Run `re.sub(r'\n\n\n+', '\n\n', text)` after all insertions.
|
||||
+9
-2
@@ -21,7 +21,14 @@ The DOCX English is the authoritative target text. No PDF needed.
|
||||
For articles where the body has strict CN→EN→CN→EN alternation, the simple
|
||||
extraction in that script (CN line, blank, EN line, blank) works directly.
|
||||
|
||||
**Block-based extraction** (for articles with mixed ordering): when the DOCX has
|
||||
### A2. Bilingual from `.docx.md` (pandoc markdown output)
|
||||
|
||||
When working with an already-converted `.docx.md` file (pandoc markdown, not plain
|
||||
text), use the techniques in `references/docx-md-extraction.md`. Key differences
|
||||
from plain-text extraction: merged CN+EN on heading lines, `{#anchor}` and
|
||||
`[text](#link)` artifacts, TOC pairing guards.
|
||||
|
||||
### B. Bilingual from PDF (when PDF is the typeset target)
|
||||
sections that order CN content before EN content (CN heading → CN body → EN heading →
|
||||
EN body), the simple alternation fails. Use block-based extraction instead:
|
||||
|
||||
@@ -73,7 +80,7 @@ under the chapter headings where the issues occur. Use diff-style `-/+` notation
|
||||
- Garbled Chinese text (merged duplicate edits in source DOCX)
|
||||
- Repeated words (`the The`)
|
||||
- Chapter numbering mismatches (e.g. `九` ↔ `VIII`)
|
||||
- Translator notes in headings (`（善鑫翻，妙一审）`)
|
||||
- Translator notes in headings (`（某某翻，某某审）`)
|
||||
- Missing quotes around dialogue/speech
|
||||
|
||||
## Common source DOCX issues
|
||||
Reference in New Issue
Block a user