English is considered by most to be a lingua franca for the developer community. From time to time issues written in another language are opened on GitHub projects that I manage, which I personally cannot read. I must then waste a lot of time trying to decipher Google's machine translation of a potentially complex and technical question.

Obviously I want to be as inclusive as possible, but deciphering the (often vague) issues from someone who is new to software development or the open-source community is difficult enough already, without the language barrier.

Most of the time (but not always), a non-English-speaking developer will run their text through Google Translate before posting. However this does little more beyond saving me a click, as I still have to attempt to decipher the machine translation. In fact this is not always successful, and I usually have to say something like "sorry, I do not understand what you are trying to say" and close the issue.

Should I have a policy on this? The way I see it, I have a few options:

  • No policy (current paradigm)
  • Require all issues to be in English, using machine translation when necessary
  • Require all issues to be written in intelligible English
  • Prefer English, but encourage a subset of widely-used non-English languages to encourage more efficient communication with other speakers of those languages. Forbid machine-translated content.

The way I see it, the last option is actually preferable to the current paradigm of machine-translating everything into English (and then presumably back into peoples' native languages).

For widely spoken languages, there is a good chance that another speaker of that language could find their issue and help them (note that Stack Overflow itself now has dedicated Spanish, Portuguese, Russian, and Japanese language communities). I could even add language labels where appropriate.

  • I would run it through a machine translator. If the translation is understandable, great! (also write a note saying you're sorry, but you only speak English). If the translation is not understandable, write a note saying you're sorry, you only speak English, and the computer could not translate the writing well. (notice I've written that in a slightly strange way, so it's hopefully simple to translate)
    – user253751
    Jul 7, 2020 at 9:56

2 Answers 2


Open-source maintenance is often volunteer work. As a volunteer, you do not owe your time to anyone and can always say “no”. So it is absolutely legitimate to close any issue that is not comprehensible, ideally with a polite message in simple English that has a good chance of surviving machine translation. I would consider such a response to be more polite than leaving the issue open but ignored.

Note that the conversation on a GH issue is not locked when the issue is closed. Should (other) community members be able to successfully clarify the problem it can always be re-opened.

I understand the desire to be welcoming to everyone. To some degree that is certainly possible, but this approach doesn't scale. It is reasonable to expect that people who bring their problems to a community do their share of the work and present the problem in a manner that can be answered effectively. There needs to be a balance of two forces: limited capacity by experts who are interested and able to answer these problems, and a reputation of helpfulness in the wider community. If you set the bar too high and close issues due to formal problems, the project may get a reputation for toxicity. But trying to answer everything may lead to burn out, and loss of interest in the project. Excessive helpfulness may also attract help vampires.

I think that asking for comprehensible English language is a reasonable requirement. While language barriers are really unfortunate, you cannot single-handedly solve them. Do not create a policy that would make anyone feel obliged to decipher non-English issues.

This problem will only solve itself if your project becomes so popular that national/language-specific communities appear with their own help resources. E.g. my initial exposure to web development was through German-language resources. Consider also the history of the Ruby programming language, where it took some time for a non-Japanese community to form. But before something like that happens, you'll have to be content with the many English speakers on this world.


In my eyes the best option is indeed the last option. You could use labels to indicate the language of the issue and encourage other people to translate these issues.
Some issues can be translated by a machine, but others cannot. You don't want to miss out on the issues made in a foreign language. Denying all not English issues will give you less information about issues in the application. Adding 'language_name' and 'needs translation' labels to the issue will give a possibility that these issues will be translated by a community member. If it won't you don't really have a loss, and when it will be translated you just gained a helpful issue.

I have seen some repositories that do it like this in the past. About five times I translated an issue from Dutch or German to English.

TL;DR - Encourage people to write issues in English - Encourage people to translate the issues not written in English.

  • 2
    I agree with this but would add to close the issue nonetheless. You don't want to clutter your issue tracker with open issues you can't fix because you can't understand them. You should view closing such issues the same way as closing questions on Stack Exchange: it's not a graveyard, it's a period of stability that allows the issue to be improved such that it can be re-opened later. Oct 22, 2017 at 7:14
  • 1
    You could always make the tag "Closed Until Translated" Oct 25, 2017 at 5:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.