How to Write a Bug Report in English When It Is Not Your First Language
To write a useful bug report in English, describe one problem with numbered steps, what you expected, and what actually happened. Use short sentences and copy error messages, interface labels, and version numbers exactly. You can draft the explanation in your strongest language, translate it, and then check that the English still describes the same actions and observations.
You do not need elaborate English or a theory about the broken code. A report that lets another person follow what you did is useful even when its grammar is simple. This guide is for ordinary software problems reported to a developer, product team, or open-source project.
What information matters more than polished English?
The reader needs enough context to recognize the problem and investigate it. Start with what you can observe.
| Part of the report | What to include | A short sentence pattern |
|---|---|---|
| Title | The action and the visible failure | After I select Save, the new name disappears. |
| Starting conditions | The page, account role, or data needed | I am signed in with a test account. |
| Steps | One action per numbered line | Open Settings. Select Profile. |
| Expected result | What you thought the action would do | I expected the new name to remain after reloading. |
| Actual result | What you saw instead | The previous name appears after reloading. |
| Frequency | What happened in the attempts you actually made | This happened in two of three attempts. |
| Environment | Relevant app, device, browser, and version information | App version: [copy the exact version]. |
| Evidence | A relevant screenshot, recording, or error message | The attached image shows the result after step 4. |
Mozilla's bug-writing guidance emphasizes precise reproduction steps and expected versus actual results. It also recommends a separate report for each issue. Apply that distinction before improving the wording: “the page is broken” leaves the reader with several possible problems, while a specific action and result give them a place to begin.
How do you turn notes in your own language into a clear report?
Write the sequence first, translate second, and check the facts last.
- Describe the starting screen and anything already set up.
- List the actions you performed in order.
- Write the expected result separately from the observed result.
- Add exact technical text and the environment information you have.
- Translate the explanatory sentences into English.
- Follow the English steps yourself, when doing so is safe, and check that they match the original event.
Do not ask a translation tool to make a vague description “sound technical.” Ask for plain English with one action per step, and keep a copy of your original notes. If a translated sentence adds a cause, a test result, or a device you never mentioned, remove that addition.
For example, “The database fails to save my profile” claims a cause. “The old profile name appears after I reload the page” reports an observation. You can add a suspected cause in a separate paragraph if you have a reason, clearly labeled as unconfirmed.
What should you copy exactly instead of translating?
Preserve information that someone may need to search, compare, or enter into a system:
- Error messages and error codes.
- App versions, build identifiers, browser versions, and operating-system versions.
- File names, function names, commands, and relevant code.
- Exact interface labels as displayed in your language.
- Identifiers approved for sharing with the people receiving the report.
Put technical text in code formatting where the reporting tool supports it. If the interface is localized, identify a button by its actual label, explain what it does in English, and show its position in a suitable screenshot. Do not replace the original label with a guessed English product label.
For a non-English error message, keep the original and add a clearly marked English explanation. That gives the developer both your understanding and the text that actually appeared.
Check words that reverse meaning: does, does not, before, after, only, and sometimes. A fluent-looking translation of “fails only when offline” into “fails when online” creates a different bug.
Which English sentence patterns are easiest to reuse?
Use direct descriptions and consistent names. Google's guidance for a global audience recommends standard sentence structures and consistent terminology to reduce ambiguity and mistranslation.
| What you need to explain | A useful pattern |
|---|---|
| The trigger | After I [action], [result]. |
| A condition | This happens when [condition]. |
| A limitation in your testing | I have tested this only on [environment]. |
| An intermittent problem | I saw this [number] times in [number] attempts. |
| Something unknown | I do not know whether this affects other accounts. |
| A comparison | The same steps worked in [version or environment I actually tested]. |
| A clarification request | Which version and starting screen should I use for this test? |
Use one name for the same object throughout the report. If you call a screen “Profile” in step 1, avoid calling it “account area” in step 3 unless those are different places.
You rarely need to begin with an apology for your English. If you are uncertain about a specific term, explain it directly: “By reload, I mean refreshing the browser page.”
What does a complete example look like?
The following is an invented example of an ordinary application issue, not a claim about a real product. Replace every observation and placeholder with your own information.
Title: Profile name returns to its previous value after reloading
Starting conditions:
- I am signed in with a test account.
- The current profile name is Sample A.
Steps:
1. Open Settings, then Profile.
2. Change the profile name from Sample A to Sample B.
3. Select Save.
4. Reload the page.
Expected result:
The profile name remains Sample B.
Actual result:
The profile name is Sample A again.
Frequency:
This happened in two of three attempts with the same test account.
Environment:
- App version/build: [exact value]
- Browser and version: [exact value]
- Operating system: [exact value]
- Interface language: [language]
Evidence:
- [An approved screenshot showing the result after step 4]
Impact:
I cannot keep an updated profile name after reloading.
Unknown:
I have not tested another account or another browser.
The example deliberately leaves unknown information unknown. Do not copy its frequency, environment, or successful Save action unless those are things you observed.
What if the developer cannot reproduce the problem?
Compare conditions before repeating the same explanation. Ask which app version, account role, starting data, language setting, and sequence the developer used. State one relevant difference at a time.
If you write code, a small example can help. Stack Overflow's reproducible-example guidance describes an example that is minimal, complete, and actually reproduces the problem. Test the reduced example: removing a detail may also remove the failure. Supply code as text when the project requests it, rather than making the reader reconstruct it from an image.
If you do not write code, you can still reduce the case: a small permitted test file, a short sequence, or a test record with only the necessary fields. Follow your team's rules for sample data.
For an intermittent issue, report the attempts you made and the last action you remember. “I cannot reproduce it now” is useful context. Do not invent a reliable sequence or change “sometimes” to “always” to make the report seem stronger.
How should you handle screenshots, recordings, and private information?
Choose evidence that shows the relevant step or result and is appropriate for the reporting channel. Check the whole image, including browser tabs, notifications, account details, and the address bar, before sharing it.
Use approved test data where possible. Do not paste passwords, session tokens, or private customer content into an ordinary report or translation tool. If logs are requested, ask which section and which private upload method to use. Keep a note of redactions so the recipient understands what has been removed.
Potential security issues need a different route. Follow the project's security policy rather than posting exploit details or exposed data in a public issue. GitHub's private-reporting documentation explains that private vulnerability reporting is available when enabled by the repository, and directs reporters to the security policy when it is unavailable. Ask for an appropriate private contact if the route is unclear.
If repeating the action could move money, delete important data, or affect a live service, explain the observation and ask for a safe test environment. Translation assistance is not permission to repeat a consequential operation.
Where should you submit the report, and what should you do afterward?
Use the team's or project's designated channel and fill in its template. GitHub's issue-creation guide describes choosing an available issue template and entering the title and description. Templates may request details beyond the generic example here.
Before submitting, search for an existing report of the same behavior. Compare the trigger and result, not just a similar title. If you find one, follow the project's instructions for adding useful evidence instead of creating a parallel discussion.
Keep the report link or identifier. When someone asks a question, answer that question first and identify what you tested. For example:
I tested the same steps on build [exact value]. The old name still appears after step 4. I have not tested the mobile app.
If a developer provides a proposed fix, repeat the agreed safe test and report the environment and result. A changed status label is different from a test you performed yourself.
What changes in common situations?
The report comes from a customer: separate the customer's observation from your own reproduction. “The customer reports…” and “I reproduced…” describe different evidence.
Your app is in another language: include the interface language and retain the displayed labels. Describe the function and location of the control in English without inventing its English name.
The problem happens during a call: note the last action, time, and visible result, then write a short report afterward. Include the time zone if a timestamp matters to the investigation.
There are several symptoms: explain which steps connect them. If you do not know whether they share a cause, say so and follow the team's preference for separate reports and links.
The issue blocks work: state the task you cannot complete and any workaround you actually tried. Ask the team to assign priority rather than guessing that every frustrating problem has the highest severity.
What if you cannot access the tracker or a translation tool?
Keep a plain-text draft with the title, numbered actions, expected result, actual result, environment, and questions. Use a local note or paper if necessary, following your organization's rules for sensitive information.
Save permitted evidence and label it so you can match it to the steps later. Record what you remember while the event is fresh, but mark uncertain details. When access returns, use the project's template and review the draft before sending it.
A short factual report can be understandable without automated translation. Ask a colleague to check one ambiguous sentence rather than waiting until the entire report sounds fluent.
Where does Leyo help?
Use Leyo Translate to turn your own explanation into short English sentences and understand the wording, pronunciation, and context of a developer's follow-up. Work on the narrative around the evidence, keeping original errors, identifiers, and code available for comparison.
After translating, check that the steps, conditions, frequency, and expected-versus-actual distinction still match your notes. Share only information permitted by your team. Leyo can help with the language; the observations and test results must still come from what happened.
Frequently asked questions
Do I need fluent English to write a bug report?
No. A clear sequence and accurate observations matter more than sophisticated wording. Use short sentences and explain any term whose meaning is uncertain.
Should I translate an error message into English?
Keep the original message exactly and add a labeled English explanation if useful. The original text may be needed for searching or investigation.
What is the difference between expected and actual behavior?
Expected behavior is what you thought the action would do. Actual behavior is what you observed. Put them in separate fields so the reader can see the mismatch.
Can I report a bug that happens only sometimes?
Yes. Describe the attempts and conditions you know, including when you could not reproduce it. Be clear about uncertainty instead of claiming it always happens.
Can AI write the report for me?
It can help organize or translate your notes. Review the result for added assumptions, altered identifiers, reversed conditions, and tests you never performed. Do not supply confidential data without permission.
Is a screenshot enough?
Usually it needs context: what you did, what you expected, and where the image fits in the sequence. A screenshot can show a result while numbered steps explain how you reached it.
