Safeguard
Security Guides•

How do you handle vulnerability reports in a language you do not read?

State your preferred languages in security.txt and your policy, then handle other languages with translation and plain, short replies. A practical routine.

Safeguard Security Team
4 min read

Say which languages you prefer, publish that in your policy and security.txt, and still accept reports in others. Use a translation tool for a first read, reply in short plain sentences, and ask the reporter for requests, responses and screenshots, which need little translation.

What the standard says

RFC 9116, the security.txt standard, defines a Preferred-Languages field. It lists the natural languages you prefer for security reports, using language tags, with at least one value if the field is present. The standard says the order does not indicate priority, and that if the field is absent, researchers may assume English. The field may appear only once.

A line looks like this:

Preferred-Languages: en, es

That helps researchers choose, but it does not stop someone writing in another language. Many reporters are fluent in only one, and some very clear technical writing comes from people for whom English is a second language.

A routine for foreign language reports

  1. Machine translate the report for a first read. Technical terms and code survive translation better than prose.
  2. Look at the evidence, not the prose. Requests, responses, URLs and screenshots are often enough to understand the issue.
  3. Reply in the reporter's language when you can, or in short English sentences with simple words. Avoid idioms.
  4. Send your reply with a translated copy if you used a tool, and say you used one.
  5. Ask yes or no questions where possible. They translate cleanly.
  6. Keep the translation out of public tools if the report holds sensitive details. Check your translation tool's data handling first, or use an approved internal option.

Phrases that translate well

Instead ofSay
"We would appreciate it if you could kindly elaborate""Please send the request and response."
"We are looking into this""We received your report. We will write again by date."
"That is out of scope""This system is not in our policy. We will still look at it."
"Can you shed some light on...""Which version did you test?"

Policy wording

In your reporting section, say: "We read reports in English and Spanish. You may write in another language. We will do our best to understand it and reply simply." That sets expectations without turning anyone away. See the how-to-report section of a policy.

Time zones and response

A global audience also means reports arrive outside your working hours. Set your response target in business days and say which time zone you use. Keep it realistic, as described in what to promise researchers.

Caution

Machine translation can change meaning, especially for a threat or a reward. If a message looks hostile, ask a native speaker before replying. Translation mistakes can sour a case that was going well.

Keep the case clean

Record the original text and your translation in the case file, noting that the translation is a tool output. If the case goes to a CVE request or advisory, write those in clear English so that tools and readers understand them. Safeguard's SBOM and dependency scanning outputs are already structured data, which helps when the report concerns a component. You can try a free scan.

Quick check

Do I have to support every language?

No. State your preferred languages and handle the rest as far as your team is able.

Is it safe to paste a report into an online translator?

It depends on the report and the tool. Reports can hold sensitive details, so check where the text goes before using any outside service.

Sources

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.