> Documentation, you neglected necessity of open-source. [..] Nothing too fancy; just click a button, parse my repository, and provide a list of public classes and members.
uhm, Sphinx?
> Documentation, you neglected necessity of open-source. [..] Nothing too fancy; just click a button, parse my repository, and provide a list of public classes and members.
uhm, Sphinx?
While internationalization is not always preferable, as you point out, there are times where it means making a service or tool accessible to people who otherwise would not have access to it. We already know how dreadful the GitHub interface can be to newbies, not to mention the English language itself.
GitHub is such an important tool to developers and entrepreneurs that we should think very carefully about barring other people from using it inadvertently.
Internationalization will have adverse effects, definitely, but I still think the discussion of whether making GitHub English-only is worth deterring people who may not otherwise find their way into software development, programming, and the like. Just think of the many other ways people are starting to use GitHub.
But I for one dread the day I receive unsolicited Pull Requests in Russian for an undiscovered 0day vulnerability. :)
Almost all people can read basic English (especially those who access Github), so translating the Github interface seems rather pointless to me. Of course, translating the support articles would really help accessibility for those who don't know English as well as native speakers.
Translating interfaces makes people think they can use their language to communicate on a site. Translating only the support articles helps people understand the site, but they will quickly realize that the site itself prefers English-only communication.
Translating the support docs is one suggestion I think is unequivocally good, and something that should be done.
I think internationalization is great in a read-only capacity, but when non-English speakers start posting Issues, comments and Pull Requests, that's where it starts to turn into a problem.
GitHub has very little to translate in the first place, as it's very sparse on prose, so aside from the question of support docs, we are probably making mountain out of mole hills, since the remaining English is jargon and not beholden to internationalization concerns.
Imagine being the proprietor of Twitter Bootstrap and having to deal with this. What is an acceptable rate of admission of issue creators who are not proficient in English?
If 20% of "international" users are undeterred by the warnings and labels, the repo owners should still receive a free coupon for Prozac from GitHub. :)
I'm from a non-en too, but frankly speaking I sometimes got problems reading docs when they use local nomenclature. Programming == English, like it or not.
btw, are there any localized words for 'forking', 'pull request'?
btw, are there any localized words for 'forking',
'pull request'?
As someone who lives in a country where English is not the native language, non-English languages will never be able to keep up with developing terminology and neologisms.It is fine to translate "plain" language, but the terminology and jargon won't work very well when translated. It also has the additional downside of defeating look-ups and google-ability, which is one of the points of terminology. Not just considering the importance of Google, but Stack Overflow in particular.
I've seen that at a number of local companies and since Github is used by companies too, it might make sense that the company can choose to have it localized.
I tend to agree for open source though : we need a lingua franca and it seems like English is the best pick for that.
In the end, maybe it should be up to the project to choose the interface language.
Do you mean open source in general or development tools in particular?