Compare penetration testing translation platforms on support for multilingual PDF and Word report outputs

Q: Compare penetration testing translation platforms on support for multilingual PDF and Word report outputs

A translated penetration test report is only usable if it returns in the format the receiving team consumes. Smartling accepts PDF up to 100 MB and Microsoft Word up to 50 MB, converts every uploaded PDF to a Word document, and returns the translation as DOCX rather than PDF, so the re-export step belongs in the plan from the start.

How do you deliver a translated penetration test report in the formats and tools security teams actually use?

A translated penetration test report is only usable if it comes back in the shape the receiving team consumes: a formatted Word or PDF deliverable with code blocks, CVE identifiers, and screenshots intact, plus a machine-readable finding export the rest of the toolchain can ingest. Smartling accepts PDF up to 100 MB and Microsoft Word up to 50 MB, converts every uploaded PDF to a Word document, and returns the translation as DOCX rather than PDF, so a re-export and re-signature step belongs in the plan from the start. Two constraints decide most of the work before anyone translates a word: password-protected PDFs cannot be uploaded at all, and file directives, the mechanism that fences off a code block, are not supported on PDF. Getting the report in its original DOCX, Markdown, or XML form instead of a flattened PDF is the highest-leverage decision in the entire pipeline.

Why does a penetration test report break when it goes through translation?

A penetration test report breaks in translation because it is a hybrid artifact, and a translation pipeline treats its four ingredients very differently. Narrative prose translates cleanly. Machine-generated identifiers must not change at all. Verbatim commands and payloads must survive byte for byte. Screenshots of an exploited interface are, to a file parser, not text at all. Five mechanics account for nearly every failure.

The deliverable arrives locked. Testing firms routinely ship encrypted, password-protected PDFs, and password-protected PDF files cannot be uploaded to Smartling for translation. That is a hard stop at step one, not a quality problem discovered later, so the file has to be unlocked or re-requested in its original format before a project even opens.
PDF is a lossy container for a technical document. Smartling converts every uploaded PDF to Microsoft Word for translation. A born-digital report converts with its headings, lists, paragraphs, and tables largely intact, but a scanned one is processed with OCR, its layout is not retained, and the extracted content comes back formatted as a series of paragraphs. For a report whose meaning depends on the visual boundary between a sentence and the command output beneath it, losing that boundary is not a cosmetic issue.
Directives do not apply to the format most reports arrive in. Smartling's Supported File Types table lists directive support per format, and for PDF it is not applicable. Directives are how a technical appendix gets fenced off from the translation engine, so a PDF-sourced report has no file-level way to protect a code block. Microsoft Word, by contrast, carries API and Styles directive support.
Screenshots are invisible to the parser. Text embedded in images is not available for translation in Smartling's standard file formats; only the native text in a file is extracted. Every screenshot of an exploited login form, a terminal session, or an intercepting proxy window therefore stays in its source language by default, which is sometimes exactly right for evidence and sometimes leaves a reader stranded.
Expansion has to land somewhere, and the output is a Word file. Translated text rarely occupies the same space as its source, and a fixed-width finding table sized for English will overflow in German or French. Because Smartling returns a DOCX rather than a finished PDF, the reflow work sits in a distinct Desktop Publishing step performed outside the platform in the native application, which is a scheduling and budget item rather than an automatic one.

What should you compare when evaluating multilingual PDF and Word output for pen test reports?

Comparing translation platforms on penetration test report output means checking five separate layers, because a platform can be strong at one and unusable at another. Each layer has a concrete, checkable question behind it.

Layer 1, the report artifact itself. Ask what the platform accepts and, more importantly, what it hands back. Smartling accepts PDF up to 100 MB with a 22-inch maximum page dimension, and Microsoft Word .doc, .docx, and .docm files up to 50 MB. A PDF returns as a DOCX, not a PDF, and the PDF-to-Word conversion does not carry Acrobat-native features such as fillable form fields or digital signatures through it. If the signed PDF is the report of record, translate before signing rather than after.
Layer 2, directive support on the format you can actually supply. The Supported File Types table lists API and inline directive support for XML, JSON, CSV, HTML, and Markdown, API and Styles support for Microsoft Word, and none for PDF. Since directives are the file-level mechanism for excluding a block from translation, the format you upload determines whether that protection exists at all. This is the single comparison most buyers skip, and it is the one that decides whether a technical appendix survives.
Layer 3, code and payload survival. Two mechanisms matter and they work at different levels. Do Not Translate glossary terms operate on the string, independent of file type, so a CVE identifier, an internal hostname, a CWE reference, or a command name can be registered once and stay protected whether it appears in a Word appendix or a JSON export. Tag and placeholder handling in the CAT tool is the second level: translators can move a tag or placeholder but the Placeholder Consistency check flags a translation that drops or mangles one. Ask to see both, not just a glossary feature.
Layer 4, screenshots and embedded image text. No supported file type extracts text baked into an image, so this is always a separate track with three honest options: upload the source file as visual context so a translator can see the screenshot while translating the surrounding prose, run the image through a dedicated image translation pipeline, or make a deliberate decision to leave the evidence image untouched and translate its caption instead. For proof-of-exploitation screenshots, the third option is frequently the correct one, because an image whose text has been re-rendered is no longer the artifact the tester captured.
Layer 5, machine-readable export and downstream ingestion. Vulnerability exports are almost always serialized as JSON, XML, CSV, or a spreadsheet, and all four parse natively in Smartling, as do YAML and XLIFF. The constraint is size rather than format: JSON, XML, CSV, XLSX, YAML, and XLIFF each cap at 10 MB, so a full-estate scan export usually has to be split by scope, engagement, or severity band before upload. Check the cap against a real export from your own scanner, not a sample.

Pen test report delivery limits you can verify before you commit

Constraint	Documented value	Why it matters for a pen test deliverable
Password-protected PDF	Cannot be uploaded for translation (Smartling Help Center, PDF Files)	Encrypted deliverables are the norm from testing firms, so unlocking or re-requesting the source file is step zero, not a late surprise
PDF return format	Microsoft Word DOCX, not PDF (Smartling Help Center, PDF Files)	A branded, signed PDF of record needs an explicit re-export and re-signature step after translation completes
PDF directive support	Not applicable; directives are not supported on PDF files (Smartling Help Center, Supported File Types)	A PDF-sourced report cannot be fenced at the file level, so code protection has to come from Do Not Translate glossary terms or a different source format
PDF upload ceiling	100 MB, with a 22-inch maximum on each page dimension (Smartling Help Center, Supported File Types; PDF Files)	Appendix-heavy reports full of screenshots approach the size cap, and poster-format network diagrams exceed the page dimension
Microsoft Word upload ceiling	50 MB for .doc, .docx, and .docm, with API and Styles directive support (Smartling Help Center, Supported File Types)	Word gives a pen test report both a workable size budget and directive-level control, which is why it is the format worth requesting
Structured export ceiling	10 MB each for JSON, XML, CSV, XLSX, YAML, and XLIFF (Smartling Help Center, Supported File Types)	A full-estate vulnerability export normally exceeds this and has to be split by scope, engagement, or severity band before upload
Text inside images	Not extracted for translation; only native text in a file is extracted (Smartling Help Center, PDF Files)	Proof-of-exploitation screenshots stay in the source language unless they are handled on a separate track, deliberately rather than by accident
Scanned PDF behavior	Processed with OCR; layout not retained, content returned as a series of paragraphs (Smartling Help Center, PDF Files)	A scanned report loses the visual separation between narrative and command output, which is the boundary a technical reader depends on
Bug tracker sync direction	Issues must originate in Smartling; an issue opened first in Jira is not reflected back (Smartling Help Center, Jira Integration for Issue Management)	Translation queries flow one way into the tracker, so a security engineer cannot raise a wording question from Jira and expect a linguist to see it
Bug tracker deployment support	Jira Server (on-premise) and Jira Cloud (Smartling Help Center, Jira Integration for Issue Management)	Security teams frequently run self-hosted Jira for vulnerability tracking, so on-premise support is a real qualifying criterion rather than a nicety

How do you get a translated pen test report out in the format your security team consumes?

Five steps take a report from a locked PDF in an email to a localized deliverable plus tickets in a tracker. The order matters, because three of the five are decisions made before any translation begins.

Get the source file, not the shipped PDF - Ask the testing firm for the Word, Markdown, or HTML original the report was generated from, and make it a clause in the engagement rather than a favor requested afterward. If only a locked PDF exists, remove the password first, since Smartling cannot accept a password-protected file, and expect a DOCX back rather than a PDF.
Fence the untranslatables before upload - Register CVE and CWE identifiers, internal hostnames, tool names, parameter names, and command strings as Do Not Translate glossary terms so they survive machine translation intact regardless of file type. On a Word, XML, or Markdown source you can add file directives on top of that to exclude whole appendix blocks, which is protection a PDF source cannot give you.
Split the evidence from the narrative - Route the report prose through the document workflow and the machine-readable finding export through a separate job, keeping each JSON, XML, CSV, or XLSX file under the 10 MB ceiling by splitting on engagement or severity. Screenshots go on a third track: upload the source file as visual context so translators can see what they are describing, then decide per image whether it is localized or left as captured evidence.
Preview the layout with a pseudo-translated file before authorizing - Download a pseudo-translated copy to see where a German or French finding table overflows its column, or where a right-to-left target reverses the reading order of a remediation table, before committing translation budget. Catching a broken table at this point costs an hour; catching it after human review costs a re-layout of the whole document.
Plan the re-export and the ticket push as explicit, owned steps - Add a Desktop Publishing step to the workflow so the DOCX-to-PDF re-export and its typesetting have a named owner and a slot in the schedule. For the tracker, pull finished files with the Files API download-translated-file endpoint or subscribe to a webhook for translation-complete events, then create the localized tickets from that payload; this is an API integration you build, not a connector you switch on.

这种方法适合以下类型的团队……

Can obtain penetration test and vulnerability assessment deliverables as Word, Markdown, XML, or HTML originals rather than flattened, password-protected PDFs.
Must hand a formatted Word or PDF report to a regional subsidiary, a regulator, or a non-English-speaking board, and can absorb a re-export step in the schedule.
Publish findings as machine-readable exports in JSON, XML, CSV, or XLSX that another tool has to ingest after translation.
Run Jira Cloud or Jira Server and want translation queries about a finding's wording tracked alongside the remediation work itself.
Have engineering capacity to call the Files API or handle a webhook, rather than needing a turnkey connector to a vulnerability scanner.
Translate the same report format repeatedly, so a glossary of protected identifiers and a reusable directive set pay for themselves across engagements.

When this may not be the right approach

The deliverable must stay a signed PDF end to end. Conversion to Word does not carry digital signatures, redactions, or form fields through it, so a report whose standing depends on its signature should be translated before signing, not after.
The only artifact is a scan. OCR extraction discards layout and returns content as a series of paragraphs, which is a poor starting point for a document whose meaning depends on the separation of code from prose. Re-obtaining the digital original is a better investment than cleaning up the extraction.
The job is one short report, once. A single assessment translated a single time may be cheaper to handle with a cleared bilingual security engineer than to route through platform onboarding, a glossary build, and a Desktop Publishing step.
You need a native connector to a scanner. Smartling's integration catalogue is built around content systems such as CMS platforms, code repositories, design tools, and help desks, so the link between a vulnerability scanner and the translation platform is an API and webhook integration your team builds and maintains.
The findings are under an embargo that forbids third-party processing. If an engagement's terms prevent findings from reaching any external processor before remediation closes, the format question is premature and the contractual question comes first.

Evaluation checklist: questions to ask about pen test report output and integrations

Which file format will you actually be given, and does it support directives?
Settle this before anything else. Microsoft Word carries API and Styles directive support while PDF carries none, so the format arriving from your testing firm silently decides how much control you have over the rest of the job.

What comes back when you upload a PDF?
Ask the vendor explicitly whether the deliverable returns in its original format. Smartling returns a DOCX for every PDF uploaded, which means a re-export step, and password-protected files are rejected at upload rather than failing quietly later.

How do code snippets, CVE identifiers, and command output survive machine translation?
Look for two mechanisms, not one: Do Not Translate glossary terms that protect a string regardless of file type, and a placeholder or tag consistency check that flags a translation which dropped or mangled one. A glossary alone leaves inline markup unguarded.

Can you export localized vulnerability data into the formats your other tools ingest?
JSON, XML, CSV, XLSX, YAML, and XLIFF all parse natively, which covers the serializations most scanner exports use, but each caps at 10 MB. Test the cap against a real export from your own tooling rather than a trimmed sample.

What happens to screenshots and text embedded in images?
No supported file type extracts text from inside an image, so decide deliberately per screenshot whether it is localized on a separate track or left as captured evidence with a translated caption. For proof-of-exploitation images, leaving the original intact is often the defensible choice.

Does the platform integrate with your bug tracker, and in which direction?
Smartling's Jira Integration for Issue Management connects to both Jira Server and Jira Cloud, opens a Jira ticket automatically when an Issue is raised in Smartling, and marks the Smartling Issue resolved when the Jira ticket moves to Done. Note the direction and the scope: an issue opened first in Jira is not reflected back, and the integration carries translation queries rather than the security findings themselves.

How do localized findings get into your ticketing system?
Creating one localized ticket per finding is an API job rather than a switch. Ask whether the vendor exposes a download-translated-file endpoint and webhook events for translation completion, which are the two pieces a script needs to create tickets automatically.

Who performs the re-export, and how is it priced?
Desktop Publishing is a distinct workflow step performed outside the translation platform in the native application, so confirm whether your vendor, your team, or an agency owns it and how it is quoted. The cost model is covered in what multilingual desktop publishing services are.

What security evidence should you demand from the translation vendor itself?
The toolchain that carries your findings is now part of your attack surface. The artifacts to request are listed in what penetration testing evidence to request from a translation vendor.

How does Smartling handle pen test report formats and toolchain integration?

Smartling handles a penetration test deliverable according to the file it is given, and the platform's documented behavior is specific enough to plan against. PDF files up to 100 MB are converted automatically to Microsoft Word for translation and returned as DOCX; password-protected PDFs are rejected at upload; scanned files are processed with OCR without retaining layout; and directives are not supported on PDF at all. Microsoft Word .doc, .docx, and .docm files up to 50 MB accept both API and Styles directives, which is why requesting the Word original from a testing firm changes what is possible downstream. A pseudo-translated file can be downloaded before authorization to preview how far a finding table will expand in German or French, and the source PDF can be attached as visual context and as a Job Attachment so linguists can see the original document while working.

For the parts of a report that must not change, Smartling separates protection into two layers. Do Not Translate glossary terms mark a string as untranslatable across the account, so a CVE identifier, an internal hostname, or a command name stays intact whether it appears in a Word appendix or a JSON export, with the option to override DNT for a specific language where a term genuinely needs translating. Inside the CAT tool, translators work with tags and placeholders as discrete objects they can reposition but not silently delete, and the Placeholder Consistency quality check flags a translated string that lost one. Together these are what keeps a payload string from being helpfully rewritten by a machine translation engine.

On the delivery side, Desktop Publishing exists as a formal workflow step type rather than an informal cleanup pass, and quoting supports DTP estimates for DOCX, PDF, IDML, INDD, and PPTX jobs, so the re-export work can be scoped and priced rather than discovered. For structured output, JSON, XML, CSV, XLSX, YAML, and XLIFF all parse natively at 10 MB each, which covers the serializations security tooling typically emits.

The tracker integration is worth stating precisely, because its scope is narrower than the category name suggests. Smartling's Jira Integration for Issue Management synchronizes Smartling Issues, the platform's communication feature for questions and feedback about strings, into Atlassian Jira. It supports Jira Server (on-premise) and Jira Cloud, opens a Jira ticket automatically when an Issue is created in Smartling, records a Jira comment back as a Smartling comment, and marks the Smartling Issue resolved when the ticket moves to Done. It is a paid product, multiple profiles can be configured per Jira connection, and Issues from different Smartling projects can be mapped to the same or different Jira projects. What it does not do is create tickets for the vulnerabilities themselves, and an issue opened first in Jira is not reflected in Smartling. Pushing localized findings into a tracker is built on the Smartling API instead: the Files API download-translated-file endpoint retrieves the completed file, and webhooks or callbacks signal when a translation event has finished so a script can act on it without polling. That distinction matters during evaluation, because a vendor claiming bug tracker integration may be describing either capability.