Let's make GitHub better, together(letsmake.github.com)
letsmake.github.com
Let's make GitHub better, together
http://letsmake.github.com/bettertogether/#
44 comments
Totally. I am Italian, and seriously, most of the blog posts, tutorials and such written in my native language are so bad that only bad programmers can grow out of them.
Also, an open source project maintained in, say, Spanish is one I and others can't easily contribute to. That would be a disaster.
Also, an open source project maintained in, say, Spanish is one I and others can't easily contribute to. That would be a disaster.
Projects would have to pick a language that makes sense, given their goals. Perhaps some would be keener on optimising mainly for the existing set of contributors?
I'm not sure about this, it would restrict the future changes, limiting innovations and putting the project at risk of dying when the developers leave, IMHO.
I wanted to disagree - so I went looking for the source of the original Python (http://www.python.org/download/releases/early/)
And guess what, a couple of grammatical mistakes but otherwise its all in English. Now this may of course be a Dutch thing. But I have a sneaking suspicion that it is one more indication of a trend towards a very few international languages (English, Spanish, Mandarin perhaps) that the "internationally connected elite" can speak and the rest have to learn.
Kind of bothers me but I cannot tell you why.
And guess what, a couple of grammatical mistakes but otherwise its all in English. Now this may of course be a Dutch thing. But I have a sneaking suspicion that it is one more indication of a trend towards a very few international languages (English, Spanish, Mandarin perhaps) that the "internationally connected elite" can speak and the rest have to learn.
Kind of bothers me but I cannot tell you why.
Ah, but much of the original source and documentation for Ruby had Japanese section or was much more comprehensive in Japanese. This was even more true for early Ruby libraries - I can testify to it as of 2001-2003 when I was maintaining several English language libraries and writing a chapter for one of those unfortunate Syngress compilations (I was young and bad at saying no). If you're conflating Ruby and Rails, yes Rails is pretty much English-only - but though it's a common mistake, it's dead wrong if you're discussing actual languages. Even now I occasionally run into libraries with significantly longer Japanese documentation by character count and given relative density that probably means quite a lot longer in terms of actual content.
It is a Dutch thing, they've been learning it from 7 years old or something for decades and a lot of the movies and shows were always subtitled, not overdubbed. The Dutch were far ahead of everyone learning English on the continent, even before English was considered the modern lingua-franca, which personally I think really gathered steam with the adoption of the internet in the mid-90s. I can remember the French desperately trying to cling on to the delusion that French was still relevant.
I'm half-dutch and can only vaguely follow conversations in it, even 20 years ago when I'd go over as a kid everyone spoke it near fluently.
One of my professors at Uni complained that he'd tried to learn Dutch but found it nearly impossible because when he visited there as soon as they found out you were English they'd just speak to you in English.
My friend worked in banking over there for 2 years in Amsterdam, never learnt anything but basic hello/thanks/goodbye.
I'm half-dutch and can only vaguely follow conversations in it, even 20 years ago when I'd go over as a kid everyone spoke it near fluently.
One of my professors at Uni complained that he'd tried to learn Dutch but found it nearly impossible because when he visited there as soon as they found out you were English they'd just speak to you in English.
My friend worked in banking over there for 2 years in Amsterdam, never learnt anything but basic hello/thanks/goodbye.
Dank u wel :)
All I learned. Wait, also how to order a pancake which I remember as something like ick vil crack un pannecooke.
I was very impressed with the Dutch english when I've been over there. They approach it as a practicality and they also get fairly insulted if you ask them if they speak english.
All I learned. Wait, also how to order a pancake which I remember as something like ick vil crack un pannecooke.
I was very impressed with the Dutch english when I've been over there. They approach it as a practicality and they also get fairly insulted if you ask them if they speak english.
It's unfair to those speaking a different language. There's also the extinction of other languages (and all the work that went into them, and all the works that used them, literature and associated culture). It's like the extinction of species in the rainforest, except for memes (in the original Dawkin sense).
The reason is the network effect, in that the more people who use a communications system, the more valuable it is (given that communication is valuable). Language is a communications system.
This forms a natural monopoly: because of the value of larger networks, it is inevitable that one language will dominate - unless there are other barriers partitioning the network, akin to the lack of a telecommunications physical layer in centuries past.
The reason is the network effect, in that the more people who use a communications system, the more valuable it is (given that communication is valuable). Language is a communications system.
This forms a natural monopoly: because of the value of larger networks, it is inevitable that one language will dominate - unless there are other barriers partitioning the network, akin to the lack of a telecommunications physical layer in centuries past.
People in the world speak several different languages. When they want to talk in a way that will be understood in many nations, they utilize a language widely known, at least to the portion of the society that is more literate. At a time it was Greek; later it was Latin, then French. Currently it is English.
Disclaimer: English is not my primary language.
I completely disagree, Github.com should NOT be localized.
I agree that making sure your language doesn't disappear is important, but it has nothing to do with Github. It is your job on a day to day basis.
Having localized versions might lead to messy projects having multiple languages in issues and everywhere. It will not help the open source community as a whole but dilute it. It may be sad, but English is the language of IT and I think it will just lead to a wider and better community to all talk a single language, whatever it is.
Plus, managing multiple locales in an app just sucks, it will lead to problems, they would have less time to work on feature which is the point.
Maybe a localized version of Github Enterprise would make sense, but certainly not Github.com.
I completely disagree, Github.com should NOT be localized.
I agree that making sure your language doesn't disappear is important, but it has nothing to do with Github. It is your job on a day to day basis.
Having localized versions might lead to messy projects having multiple languages in issues and everywhere. It will not help the open source community as a whole but dilute it. It may be sad, but English is the language of IT and I think it will just lead to a wider and better community to all talk a single language, whatever it is.
Plus, managing multiple locales in an app just sucks, it will lead to problems, they would have less time to work on feature which is the point.
Maybe a localized version of Github Enterprise would make sense, but certainly not Github.com.
As a bad analogy - It's like asking everyone to ignore other programming languages because C++ is popularly used and the others are not (even if they are more elegant and better structured)
It makes far more sense for 7300 cultures to learn one additional language than for 7301 cultures to learn 7300 languages. The former being difficult, and the latter being impossible.
> Kind of bothers me but I cannot tell you why.
It shouldn't bother you more than utf8 and tcp/ip. If everybody in the world spoke the same language, the world would be a better place.
The discomfort probably stems from the fact that some languages will die out. That's sad but there is always room for bilingualism.
It shouldn't bother you more than utf8 and tcp/ip. If everybody in the world spoke the same language, the world would be a better place.
The discomfort probably stems from the fact that some languages will die out. That's sad but there is always room for bilingualism.
I'm not sure I can agree that the world would be better if everyone spoke the same language, there's plenty of readily googlable research suggesting that multilingualism has cognitive benefits.
But if we're going to have one universal language, it will be java. Still happy?
But if we're going to have one universal language, it will be java. Still happy?
> But if we're going to have one universal language, it will be java. Still happy?
This is a great retort, the more I think about it. There would be huge efficiences if Java was the only language in the world...and there would be huge holes too, just as if we banned every language and insta-translated all the great foreign works to English.
I think it's safe to say that some of the great works in non-Java languages might never have been possible or thought of if everything was all-Java. Can we say that some of the great non-English works would never have existed if everything was done in English? Probably.
This is a great retort, the more I think about it. There would be huge efficiences if Java was the only language in the world...and there would be huge holes too, just as if we banned every language and insta-translated all the great foreign works to English.
I think it's safe to say that some of the great works in non-Java languages might never have been possible or thought of if everything was all-Java. Can we say that some of the great non-English works would never have existed if everything was done in English? Probably.
If all people spoke the same language, every person on the planet could express their thoughts to everyone else. In my opinion, that would increase the feeling of community for the human race. The analogy to programming languages doesn't fit very well here.
I have worked out what bothers me
In 1471 (apparently) Chinese navy sent an armada (no seriously, thousands of ships, one dedicated to being a grassed over flat hill growing vegetables - really an armada) to tour the Indian China seas wand show their power / negotiate trade agreements. There is even a suggestion some of the fleet reached the Anericas
Anyway ten years later internal Chinese politics meant the Emperor effectively shut down the Chinese navy and ended external exploration - just as Columbus opened up the New World for Europe.
China was a united political body - spoke one language, etc
Eirope was a crazy, disunited, warring agglomeration - that leaped forward in the New World and brought us kickin and screaming into the modern era
Lets imagine we have a lingua Franca, then closer political union across the globe and ... Humanity misses the next leap forward - or more worryingly all of humanity collapses at the same time
In 1471 (apparently) Chinese navy sent an armada (no seriously, thousands of ships, one dedicated to being a grassed over flat hill growing vegetables - really an armada) to tour the Indian China seas wand show their power / negotiate trade agreements. There is even a suggestion some of the fleet reached the Anericas
Anyway ten years later internal Chinese politics meant the Emperor effectively shut down the Chinese navy and ended external exploration - just as Columbus opened up the New World for Europe.
China was a united political body - spoke one language, etc
Eirope was a crazy, disunited, warring agglomeration - that leaped forward in the New World and brought us kickin and screaming into the modern era
Lets imagine we have a lingua Franca, then closer political union across the globe and ... Humanity misses the next leap forward - or more worryingly all of humanity collapses at the same time
Many other regions on the planet had also been in discord and warring for millennia, without producing an Industrial Revolution.
However the unbelievable progress made in the last centuries and today wouldn't be possible without having a lingua franca. The difficulties you'll have programming without knowing English are an excellent example.
However the unbelievable progress made in the last centuries and today wouldn't be possible without having a lingua franca. The difficulties you'll have programming without knowing English are an excellent example.
I disagree. My position is not that English is bad (English has some advantages here and there, but it is hardly the best language I know), it is very practical - and necessary - to learn if you want to work in IT. No doubt about it.
However, confining ourselves to one language makes us all think the same way. Research has proven time and time again, that learning other languages will help us apply different ways to think about problems, because different languages uses different grammar to convey the same meaning.
Effectively, if we continue to strive to eradicate localised IT and software related words from non-English languages and replace them with English words instead, language development will stagnate and all languages will eventually become English. And that is not a positive prospect.
I don't need Github localised, but I would like to localise it for the purpose of creating technical terms in my own language. I fear that most of the localisation into Danish would simply be English words instead, despite the fact that Danish actually has words for 'push' and 'pull' (»puf« and »hal«, respectively).
And English shouldn't be so cocky either, by its current usage, English is slowly becoming less than a language and more of a tool. And with both foreign and native speakers' continue abuse of the language, English will soon be derived of all its beauty, for the purpose of minimising communication.
Are we really that lazy?
However, confining ourselves to one language makes us all think the same way. Research has proven time and time again, that learning other languages will help us apply different ways to think about problems, because different languages uses different grammar to convey the same meaning.
Effectively, if we continue to strive to eradicate localised IT and software related words from non-English languages and replace them with English words instead, language development will stagnate and all languages will eventually become English. And that is not a positive prospect.
I don't need Github localised, but I would like to localise it for the purpose of creating technical terms in my own language. I fear that most of the localisation into Danish would simply be English words instead, despite the fact that Danish actually has words for 'push' and 'pull' (»puf« and »hal«, respectively).
And English shouldn't be so cocky either, by its current usage, English is slowly becoming less than a language and more of a tool. And with both foreign and native speakers' continue abuse of the language, English will soon be derived of all its beauty, for the purpose of minimising communication.
Are we really that lazy?
Well, actually, it turns out that there is much less evidence for the Linguistic Relativity hypothesis than we initially thought:
http://en.wikipedia.org/wiki/Linguistic_relativity#Present_s...
It turns out language does color perception, but not as profoundly as we estimated, and not in all ways.
In any case, even if it did profoundly color perception, who is to say that it does more so than other experiences? Like learning about anthropology or philosophy, or having a life changing event, or taking up art, or doing shrooms? I don't think we know.
A bilingual myself, I've always supported people learning a second language, for some vague impression that it made you a better person. Now I'm not so sure. When most people learn a second language, they don't learn enough to be immersed into a new culture altogether, or to start thinking in that language. Is this really a profound experience? The cost/benefit ratio seems a little skewed. I don't really blame people who know English by birth for not trying to learn another language.
http://en.wikipedia.org/wiki/Linguistic_relativity#Present_s...
It turns out language does color perception, but not as profoundly as we estimated, and not in all ways.
In any case, even if it did profoundly color perception, who is to say that it does more so than other experiences? Like learning about anthropology or philosophy, or having a life changing event, or taking up art, or doing shrooms? I don't think we know.
A bilingual myself, I've always supported people learning a second language, for some vague impression that it made you a better person. Now I'm not so sure. When most people learn a second language, they don't learn enough to be immersed into a new culture altogether, or to start thinking in that language. Is this really a profound experience? The cost/benefit ratio seems a little skewed. I don't really blame people who know English by birth for not trying to learn another language.
> Are we really that lazy?
It has nothing to do with laziness and everything to do with being able to communicate. Would you learn all of japanese, chinese, russian, spanish, german, french, italian, polish, swede and english in order to be able to contribute to projects in these various languages? Unlikely.
We need a "babel fish", and currently that babel fish is simply "learn english". At various places and times in history it's been french, chinese, latin or greek. That is not a problem, it's just how things go so that people can talk with one another across countries and cultures, and work together.
It has nothing to do with laziness and everything to do with being able to communicate. Would you learn all of japanese, chinese, russian, spanish, german, french, italian, polish, swede and english in order to be able to contribute to projects in these various languages? Unlikely.
We need a "babel fish", and currently that babel fish is simply "learn english". At various places and times in history it's been french, chinese, latin or greek. That is not a problem, it's just how things go so that people can talk with one another across countries and cultures, and work together.
I apologise, I did not mean that people who were 'unwilling' to learn other languages are lazy. It is hard to demand that everyone know every language, so a lingua franca (English in this case) is all right.
What I meant to say is that languages are becoming more and more plain. It seems people - and sometimes with language institutions with them - are accepting that the languages should be less complicated, so we can say the same thing with fewer words.
An obvious example is people writing 'u' instead of 'you', but is actually even more obvious in other languages than English. For instance, I am not a fan of people saying 'issues' in Danish, when we have the word »problemstillinger«, simply because the English word 'issues' is shorter. Should English use »arv« instead of 'inheritance' because it is shorter?
Languages' vocabularies shouldn't cherry-pick.
I do not oppose a lingua franca, I merely advocate keeping each language separate.
What I meant to say is that languages are becoming more and more plain. It seems people - and sometimes with language institutions with them - are accepting that the languages should be less complicated, so we can say the same thing with fewer words.
An obvious example is people writing 'u' instead of 'you', but is actually even more obvious in other languages than English. For instance, I am not a fan of people saying 'issues' in Danish, when we have the word »problemstillinger«, simply because the English word 'issues' is shorter. Should English use »arv« instead of 'inheritance' because it is shorter?
Languages' vocabularies shouldn't cherry-pick.
I do not oppose a lingua franca, I merely advocate keeping each language separate.
I can't really get behind you on this. What do you think of the word "niveau" in Danish? Or "risalamande"? Would you advocate their removal? Languages did not sprout fully-formed from the thigh of Jupiter, they evolved organically.
At the same time, I do understand where you are coming from. Having such a large proportion of your population be fluent in English - and thus more influenced by its culture, is potentially an issue for the Danish culture.
At the same time, I do understand where you are coming from. Having such a large proportion of your population be fluent in English - and thus more influenced by its culture, is potentially an issue for the Danish culture.
What you are referring to is history. Languages borrowing terms and lending them out back then is nothing something I have a problem with.
Today, the Internet, globalisation, etc. have decreased the number of languages in the world dramatically (last thing I heard is one language dies every two weeks) and there are approximately ~7000 languages alive.
While I know that most of these languages that are dying are spoken by very few (otherwise it wouldn't die). It is now more important than ever to keep each language unique.
What was great before (loanwords and such) may actually be a problem now.
Today, the Internet, globalisation, etc. have decreased the number of languages in the world dramatically (last thing I heard is one language dies every two weeks) and there are approximately ~7000 languages alive.
While I know that most of these languages that are dying are spoken by very few (otherwise it wouldn't die). It is now more important than ever to keep each language unique.
What was great before (loanwords and such) may actually be a problem now.
First, as you say, these languages were spoken by very few people. I remember reading not long ago, the obituary of a Scottish dialect spoken in a single village. You can't really expect a language with such a small group of speakers surviving the advent of the automobile and the radio for very long. And these languages did not die by a thousand loanwords: the young folk didn't learn them, and the old folk who could speak eventually died.
There is also another factor at play here. "Proper" languages (that is, not dialects) have hundreds of years of written material behind them, and this is critical to ensure a language's survival.
There is also another factor at play here. "Proper" languages (that is, not dialects) have hundreds of years of written material behind them, and this is critical to ensure a language's survival.
The idea that languages influence the way you think about things is sometimes called the Sapir-Whorf hypothesis.
http://en.wikipedia.org/wiki/Linguistic_relativity
http://en.wikipedia.org/wiki/Linguistic_relativity
> Effectively, if we continue to strive to eradicate localised IT and software related words from non-English languages and replace them with English words instead, language development will stagnate and all languages will eventually become English.
This would only be true if a language only consisted in IT and software related words :)
> I don't need Github localised, but I would like to localise it for the purpose of creating technical terms in my own language. I fear that most of the localisation into Danish would simply be English words instead, despite the fact that Danish actually has words for 'push' and 'pull' (»puf« and »hal«, respectively).
Having had the misfortune of spending this week working on a Javascript codebase partly coded in French, let me tell you it's a very bad idea. The disconnect between variable/function names and language identifier is jarring. Please, just code in English, even if your English is bad.
This would only be true if a language only consisted in IT and software related words :)
> I don't need Github localised, but I would like to localise it for the purpose of creating technical terms in my own language. I fear that most of the localisation into Danish would simply be English words instead, despite the fact that Danish actually has words for 'push' and 'pull' (»puf« and »hal«, respectively).
Having had the misfortune of spending this week working on a Javascript codebase partly coded in French, let me tell you it's a very bad idea. The disconnect between variable/function names and language identifier is jarring. Please, just code in English, even if your English is bad.
> However, confining ourselves to one language makes us all think the same way
I have prior knowledge in the area so pardon me if what I'm saying is nonsene, but learning a programming language doesn't have the same benefits of learning any other language in this case?
I mean, if you are used to something like C, learning Haskell or Lisp or Brainfuck is a big mind shift.
I have prior knowledge in the area so pardon me if what I'm saying is nonsene, but learning a programming language doesn't have the same benefits of learning any other language in this case?
I mean, if you are used to something like C, learning Haskell or Lisp or Brainfuck is a big mind shift.
I was actually thinking of spoken languages, and attempts to solve the same issues in one particular programming language. Or in the larger scope of designing a system (where choice of programming language is less relevant).
I often find that choice of programming languages confines people to restrict themselves to certain ways in each language. Which obviously makes sense, as each programming languages were created with a need in mind that was sufficiently being fulfilled in other languages.
There are things you'd write in C, but not in Haskell. Like say, a driver.
It's different with spoken languages, they all try to solve the same issue; communicating. But do so differently.
I often find that choice of programming languages confines people to restrict themselves to certain ways in each language. Which obviously makes sense, as each programming languages were created with a need in mind that was sufficiently being fulfilled in other languages.
There are things you'd write in C, but not in Haskell. Like say, a driver.
It's different with spoken languages, they all try to solve the same issue; communicating. But do so differently.
Quite relevant: http://www.codinghorror.com/blog/2009/03/the-ugly-american-p...
Great article. Quote:
"I know many developers in Poland who prefer (as Joel mentioned) to get English documentation rather than Polish translation and the reason for that is that translations were not always accurate."
That made me remember how before the Web sometimes I could not get an original book but would be able to buy a translated one. Many times the translations made no sense at all and I had to mentally translate it back to English to understand what the original author meant.
"I know many developers in Poland who prefer (as Joel mentioned) to get English documentation rather than Polish translation and the reason for that is that translations were not always accurate."
That made me remember how before the Web sometimes I could not get an original book but would be able to buy a translated one. Many times the translations made no sense at all and I had to mentally translate it back to English to understand what the original author meant.
As another Brazilian, I agree 100% with you, I never, ever install anything in portuguese, or read any blog post in portuguese. I always go for english, the ones who do try to avoid it are usually mediocre developers.
You know what I'm talking about. The people that don't bother learning English and depend on auto translators are the same that don't bother studying anything, solve problems by trial and error, and develop by copy-and-paste and cargo-cult. Sigh...
I am a German guy, and I agree! Everybody in IT should know enough english to use GitHub.
Although Ruby uses English terms, a lot of the development happens in Japanese.
Which is a significant barrier of entry for western developers and may actually be part of the reason why MRI is not nearly as good as it could be (less eyes looking at it).
I've experienced this myself twice so far, with Ruby and with TokyoCabinet (earlier HyperEstraier). Upon investigation of lower-level problems I would eventually hit a brick-wall in the disguise of a japanese mailing list.
This seems to be improving for Ruby nowadays, but I did actually stop using HyperEstraier (years ago, before the rise of SOLR) for this reason.
One counter-example could be nginx where lots of discussion still happens in russian, yet the code-quality remains excellent. This is more of an outlier than a role-model, though. Most projects are not blessed with a lead-developer as talented as Igor.
I've experienced this myself twice so far, with Ruby and with TokyoCabinet (earlier HyperEstraier). Upon investigation of lower-level problems I would eventually hit a brick-wall in the disguise of a japanese mailing list.
This seems to be improving for Ruby nowadays, but I did actually stop using HyperEstraier (years ago, before the rise of SOLR) for this reason.
One counter-example could be nginx where lots of discussion still happens in russian, yet the code-quality remains excellent. This is more of an outlier than a role-model, though. Most projects are not blessed with a lead-developer as talented as Igor.
oh come on, it's not such a bad suggestion. There are many programmers with a poor command of English good ones and bad ones. I see no reason to say "suck it up, learn English" to them. And yes, github might be wise to address that market.
It's worth noting that international support is also useful for people wanting to add issues, not just coders. And that revision control systems can be used for more than just code.
It's worth noting that international support is also useful for people wanting to add issues, not just coders. And that revision control systems can be used for more than just code.
Agree, but this is business. They need more customers.
I'm a native German speaker and this localization thing seems like a really bad idea.
I can understand where the github folks are coming from but it really is a thing not worth putting any effort into. I sympathize with the humanism but programming and programmer communication should be mostly pragmatic.
The open source community is a global thing and English has won a long time ago as the definitive choice for a global language. It seems like it's easy enough to pick up for a lot of people all over the world.
In my opinion it works especially well for technical writing.
I can understand where the github folks are coming from but it really is a thing not worth putting any effort into. I sympathize with the humanism but programming and programmer communication should be mostly pragmatic.
The open source community is a global thing and English has won a long time ago as the definitive choice for a global language. It seems like it's easy enough to pick up for a lot of people all over the world.
In my opinion it works especially well for technical writing.
Actually, as far as I can tell, it has nothing to do with "official" GitHub. It's some guy with the GitHub username "letsmake" using GitHub pages [1].
I really wish GitHub would start doing something about people using that feature to make it look like they're part of (or speaking for) GitHub. It's incredibly misleading some times.
[1] http://pages.github.com/
I really wish GitHub would start doing something about people using that feature to make it look like they're part of (or speaking for) GitHub. It's incredibly misleading some times.
[1] http://pages.github.com/
Sites that allow users [to have significant control over] personalised subdomains are also problematic for things like NoScript and other whitelisting tools. Since I have github.com permitted, all the subdomains inherit that permission.
I'm not even sure what a good model/UI would be to selectively white/blacklist subdomains.
I'm not even sure what a good model/UI would be to selectively white/blacklist subdomains.
That is a problem only because Github uses the root domain for its own pages. They could rather use www.github.com.
To solve your case on NoScript, whitelist the full address https://github.com/ and that will keep http subdomains out.
To solve your case on NoScript, whitelist the full address https://github.com/ and that will keep http subdomains out.
Maybe github should use a different TLD for pages? Like Githubpages.com ?
The linked site is not authored by GitHub. Just hosted there :).
I don't know if i18n is such a good idea here. I've thought about it on a project I'm currently working on, and my conclusion is that sometimes you need to make the audience interact in a common language (in most cases English). If you i18n your UI, it may encourage your users to communicate in their native tongue and it will be a mess.
> 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?
Yes and no - but your point is great in general. I think that there are cases where we who are fluent in English just overestimate the English skills of some people and countries.
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. :)
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. :)
Non-native English speaker here, I volunteer at several companies to translate their interfaces.
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.
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.
The bar to entry to newcomers is probably more of a UX/usability problem than one of internationalization; that I agree with you on.
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.
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.
One way to deal with the problem of people communicating in a language the project does not understand would be to let repo owners set one or two languages for the repo. When users on GitHub en Español see an input box on their repo, it would be labeled: "Este proyecto sólo acepta contribuciones en inglés o alemán." It won't solve the problem completely, but it would at least make expectations clear.
My concern with this obvious suggestion for the problem is that GitHub has done extremely little to improve the Issue system, Pull Requests aside where merging and continuous integration has been improved.
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. :)
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. :)
While I do completely agree with you (coming from a non-english-speaking country), from the "MONEY!" POV, localization makes sense even if it siloes communities, some countries's communities mostly (if not only) communicate in their mother tongue and tend to have little involvement outside that (russian and asian communities tend to do that a lot in my experience, though it may only be because they have the numbers and are thus easier to notice than e.g. italian or french)
I'm not so sure. I mean, what's the point especially in the context of programming? I am aware that contrary to popular opinion, there are a lot of geeks who don't speak English very well, yet localizing opensource IMO doesn't make much sense (except some rare cases of very specific local projects).
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'?
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'?
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.
it was more of a retorical question. in Polish there are even problems with follow/follower - almost every quasi-direct translation is ridiculous or creepy, so in the end every website invents their own or stick with some 'subscribe'. every time I work on a local project for a client I get into the horror of reinventing call2action messages.
It always ends up sounding incredibly corny. There is basically no way around it. :)
Agreed completely. In Argentinian Spanish we say "forkeá este proyecto" or "te mando un pull request" hehe. It think, it would be very problematic if we started translating this jargon.
Well the cultural domination is a real phenomenon. We use forkea (no tilde, accent on the o) in Perú. Even when playing Warcraft as a child, I used to say "construye más farmas" to my brother, using the inflection of the Spanish Language. But we use the same alphabet. I think Japanese and Russian folks are not as comfortable using English as a common language.
From my experience (I'm from non-en), a lot of non-en programmers can understand technical English decently well, but they cannot write it (or at least not enough to express complicated ideas). So they code with comments/issues in their local languages.
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.
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.
In Swedish you usually say "forka", "pulla" thus making the English verbs into Swedish forms, works quite well.
> yet localizing opensource IMO doesn't make much sense (except some rare cases of very specific local projects)
Do you mean open source in general or development tools in particular?
Do you mean open source in general or development tools in particular?
No localization, please. Sure, the languages mentioned came from countries where english is not the main spoken language, but the languages themselves are always in english, and so is everything relating to collaborative software development.
If a user comes to a site that is using her primary language, she will interact with that site using that language. That is very much not desirable at a site like Github.
Other than that, the suggestions listed sound nice to me.
If a user comes to a site that is using her primary language, she will interact with that site using that language. That is very much not desirable at a site like Github.
Other than that, the suggestions listed sound nice to me.
English is a de-facto standard for programming - languages, docs, most of the tools are in English. Books come out in English long before being translated.
This will not change any soon, and (I know it's controversial) but for the good of the devs-to-be, let GitHub remain non-localized.
I always feel the chill when someone pastes a non-English screenshot in places like StackOverflow. Or whenever I want to help some fellow dev in my company who happens to have installed Italian or French version of Firefox/Chrome/etc.!
This will not change any soon, and (I know it's controversial) but for the good of the devs-to-be, let GitHub remain non-localized.
I always feel the chill when someone pastes a non-English screenshot in places like StackOverflow. Or whenever I want to help some fellow dev in my company who happens to have installed Italian or French version of Firefox/Chrome/etc.!
We received a Chinese-language (not sure if Mandarin or what) to a KDE mailing list the other day. We could see it was relevant to us but there was no translation, nothing at all, none of us could understand the problem.
Eventually someone replied asking for them to re-submit an English description of the issue, hopefully they're able to do so. :-/
Eventually someone replied asking for them to re-submit an English description of the issue, hopefully they're able to do so. :-/
+1
If you can't speak english, you can't program for sure. I work with some people who are not very good english speakers. I can see it in their code. Sometimes its a mix of english and their own language. Very bad. NO-HIRE
If you can't speak english, you can't program for sure. I work with some people who are not very good english speakers. I can see it in their code. Sometimes its a mix of english and their own language. Very bad. NO-HIRE
Last year I worked as a freelancer for a company which sold physical stuff over the Internet (ecommerce). All the code I inherited was procedural PHP written with Swedish comments and variable names.
I speak three languages, Swedish is not one of them. That was an awful summer.
I speak three languages, Swedish is not one of them. That was an awful summer.
In such cases even if you make it a policy to use only English, it can still bite you - for example, subtle grammar errors in variable names in a large codebase will be maddening for anyone except the original programmer.
[deleted]
Inclined to agree with you about this, but isn't the post talking about localisation only for the github website UI itself .. a separate issue to the language used in comments, commit messages, code, etc. It just brings down a barrier that might be stopping some people using it.
> "If a user comes to a site that is using her primary language, she will interact with that site using that language."
If the website UI is in their native language, people would most likely also make the READMEs, issues, comments and other things in their native languages. Commit messages might also be affected, since the user would perhaps not give it much thought that they are using their native language...
If the website UI is in their native language, people would most likely also make the READMEs, issues, comments and other things in their native languages. Commit messages might also be affected, since the user would perhaps not give it much thought that they are using their native language...
I have several non-english projects on Github and (although I am proficient enough to read/write basic english) I'd like to see the user interface in my language.
Slightly meta -
If I was a business owner and a customer wrote something like this, I would be absolutely ecstatic.
It shows that you've created an awesome product. So awesome that people want more out of it, and are willing to spend considerable time ($$$) to help you make it better.
This is the real reason profit margins are so important to a good company. It means you can re-invest back into the growth of your product and continue to delight your customers.
Good on ya Github, keep it up.
If I was a business owner and a customer wrote something like this, I would be absolutely ecstatic.
It shows that you've created an awesome product. So awesome that people want more out of it, and are willing to spend considerable time ($$$) to help you make it better.
This is the real reason profit margins are so important to a good company. It means you can re-invest back into the growth of your product and continue to delight your customers.
Good on ya Github, keep it up.
A few items I'd like to see:
- Attachments in the issue tracker. Pictures tell a thousand words and it would be infinitely easier for user submitted issues to have screenshots.
- Better code search.
- More granularity in the notifications. For instance, I'd love the ability to toggle email for my own repos but leave it to web notifications for my watches. I've missed pull requests because of the deluge of messages.
- Better reliability.
It's a great tool. I really enjoy using it, but with a few additions it would be near perfect.
- Attachments in the issue tracker. Pictures tell a thousand words and it would be infinitely easier for user submitted issues to have screenshots.
- Better code search.
- More granularity in the notifications. For instance, I'd love the ability to toggle email for my own repos but leave it to web notifications for my watches. I've missed pull requests because of the deluge of messages.
- Better reliability.
It's a great tool. I really enjoy using it, but with a few additions it would be near perfect.
We just shipped Issue Attachments: https://github.com/blog/1347-issue-attachments
> More granularity in the notifications.
This. If you're part of a big organization with a lot of repos, you'll automatically watch all of them (and forks) as they are created. I'm currently watching 451 repos and have a mess of Gmail filters to (mostly) ignore notifications from repos I don't care about. Priority Inbox helps some in that it makes email actually mostly usable, but Github really needs to fix this.
There's an option to turn off auto-watching and a button to stop watching all repos, but there's not really an easy to to say, "I care about this repo and all it's forks, but nothing else." Or, as you mentioned, a way to watch some repos via email and everything else on the web.
This. If you're part of a big organization with a lot of repos, you'll automatically watch all of them (and forks) as they are created. I'm currently watching 451 repos and have a mess of Gmail filters to (mostly) ignore notifications from repos I don't care about. Priority Inbox helps some in that it makes email actually mostly usable, but Github really needs to fix this.
There's an option to turn off auto-watching and a button to stop watching all repos, but there's not really an easy to to say, "I care about this repo and all it's forks, but nothing else." Or, as you mentioned, a way to watch some repos via email and everything else on the web.
You can add attchements to issues - please look at my
https://github.com/lifeisstillgood/githubkoolaid
(it has one helper script - ghgrab.sh that, well, fires off xwd, and then uploads the resulting screenshot through the github API (mediuated by the excellent ghi)
I have no idea if it works outside of FreeBSD - drop me an issue on github if it does :-) WIth a screenshot!
(it has one helper script - ghgrab.sh that, well, fires off xwd, and then uploads the resulting screenshot through the github API (mediuated by the excellent ghi)
I have no idea if it works outside of FreeBSD - drop me an issue on github if it does :-) WIth a screenshot!
Shameless plug, searchco.de allows you to search over github,
http://searchco.de/?q=irq_create_mapping+url%3Agithub
You just need to add the url:github portion to any search. You can do the same over bitbucket, codeplex, google code, sourceforge and the fedora source tree too. See, http://searchco.de/blog/view/variety-of-updates
http://searchco.de/?q=irq_create_mapping+url%3Agithub
You just need to add the url:github portion to any search. You can do the same over bitbucket, codeplex, google code, sourceforge and the fedora source tree too. See, http://searchco.de/blog/view/variety-of-updates
The #1 missing feature in github for our team is that we can't attach files directly from Issues Web UI. Usually we need this for screenshots, but sometimes data files, logs and other artifacts. Workarounds are aplenty but all painful and problematic. See https://github.com/thisduck/gh-attachment or http://feeding.cloud.geek.nz/2012/06/attaching-files-to-gith... not to mention countless internal homegrown hacks that exist out there.
This lack of attachments makes it a lot harder for non-techies to use Issues (e.g., for casual or QA testing). Don't get me wrong, I absolutely LOVE the minimalist approach of Issues, and it is definitely _almost_ good enough feature set, but this one missing feature makes it difficult for one to imagine the use of issues at-large in broad organizations--an undiscovered area of growth for github.
I would definitely add this to the "I <heart> github, but..." list.
P.S., experiment0, great execution of a "feature request".
This lack of attachments makes it a lot harder for non-techies to use Issues (e.g., for casual or QA testing). Don't get me wrong, I absolutely LOVE the minimalist approach of Issues, and it is definitely _almost_ good enough feature set, but this one missing feature makes it difficult for one to imagine the use of issues at-large in broad organizations--an undiscovered area of growth for github.
I would definitely add this to the "I <heart> github, but..." list.
P.S., experiment0, great execution of a "feature request".
My wish came true in less than one day! Check it out https://github.com/blog/1347-issue-attachments
I don't know why, but for some reason I found that localizing github would in fact not contribute to the better, but to the worse. I know there are a lot of programmers for whom english is not their native language (heck, I'm one of them), but as almost all programming languages are in english, I think it would make sense to keep github in english. My reasons are, more of less, the following:
- As it stands now, the majority of repositories are in english. If github were localized, it would most likely contribute to more non-english repos since the author would be less inclined to give it any thought.
- It would require a lot of extra effort on githubs side to, first of all localize it, but also to keep it updated and correct. They would need translators and probably also need to put a lot of effort into localizing the site (which I'd rather they focused on other things).
I know these may not be the best reasons, but I'd rather people learned english than doing it in their native language (english opens it op to more people, ie more people can benefit/contribute to the project).
But hey, those are just my two cents...
- As it stands now, the majority of repositories are in english. If github were localized, it would most likely contribute to more non-english repos since the author would be less inclined to give it any thought.
- It would require a lot of extra effort on githubs side to, first of all localize it, but also to keep it updated and correct. They would need translators and probably also need to put a lot of effort into localizing the site (which I'd rather they focused on other things).
I know these may not be the best reasons, but I'd rather people learned english than doing it in their native language (english opens it op to more people, ie more people can benefit/contribute to the project).
But hey, those are just my two cents...
What if we spent our time making GitLab (http://gitlabhq.com/) better instead, since it's open source and users can host their own for free?
One of the biggest draws of Github (to me) is that it's one central place for me to go for a wide array of projects that I work with, and where a lot of people I know can host their code to share with the large community of developers already on Github.
By using Gitlab on your own hosting, you lose all of that convenience of having everything in one place. Imagine that every time you want to contribute to a project, you have recreate yet another user account, upload all of your SSH keys again, and more. And then further imagine that you want to fork and work on repos from multiple projects that all have their own Gitlab instances, and now checking on your projects requires visiting N different sites to get the same information that you already get from a single login to Github.
Now I'm just as big of a fan of open source as the next person, but having a single central place to visit for projects is a Good Thing, and IMO Github has proven time and again that they actually care about the open source community as much as we do, and have done so much to foster communication and interaction between developers that their contributions are far more important to me than the value of having my code repositories hosted on an open source platform.
By using Gitlab on your own hosting, you lose all of that convenience of having everything in one place. Imagine that every time you want to contribute to a project, you have recreate yet another user account, upload all of your SSH keys again, and more. And then further imagine that you want to fork and work on repos from multiple projects that all have their own Gitlab instances, and now checking on your projects requires visiting N different sites to get the same information that you already get from a single login to Github.
Now I'm just as big of a fan of open source as the next person, but having a single central place to visit for projects is a Good Thing, and IMO Github has proven time and again that they actually care about the open source community as much as we do, and have done so much to foster communication and interaction between developers that their contributions are far more important to me than the value of having my code repositories hosted on an open source platform.
I agree, and I think GitHub is a fantastic resource for open-source projects, but it's a bit of a lobster trap in the sense that its existence lessons the need for an open-source alternative, but then locks you in to a paid model once you need private repositories.
What we should be looking for is an open-source project that allows people to keep their own projects private on their existing hosting, and allows easy sync with github for public projects.
What we should be looking for is an open-source project that allows people to keep their own projects private on their existing hosting, and allows easy sync with github for public projects.
I slightly agree about CLAs. Contributor Licence Agreements are largely ignored by most small open source projects because they're a pain in the ass and prevent contributors from contributing.
However, I think they could go further than the support discussed here. It would be great to see CLAs tht you could get asked to sign when you make a pull request. You could also make it easy to sign - maybe instead of printing and scanning, you could sign using a PGP key.
If Github incorporated this stuff, every project could seamlessly use CLAs.
However, I think they could go further than the support discussed here. It would be great to see CLAs tht you could get asked to sign when you make a pull request. You could also make it easy to sign - maybe instead of printing and scanning, you could sign using a PGP key.
If Github incorporated this stuff, every project could seamlessly use CLAs.
Paperlex has a public free CLA manager which integrates with GitHub: http://clam.paperlex.com/
I took a quick tour, and I believe this would be too cumbersome compared to an integrated solution.
The famous "hacker faq" recommends using English for a few reasons:
http://www.catb.org/esr/faqs/hacker-howto.html#skills4
Other than that...
Since code is shared across many different countries, we cannot be too wishy-washy about which one to use. English is rated as "the most influential language in the world" in terms of how many countries use it and the socio-economic standing of these countries. I hate to be the one to push English (as a native speaker myself), but as you can see others on this thread recommend it, even though it is not their native tongue. By all means, I do not promote destroying cultures, but learning a common language brings us all closer together. :)
http://www.catb.org/esr/faqs/hacker-howto.html#skills4
Other than that...
Since code is shared across many different countries, we cannot be too wishy-washy about which one to use. English is rated as "the most influential language in the world" in terms of how many countries use it and the socio-economic standing of these countries. I hate to be the one to push English (as a native speaker myself), but as you can see others on this thread recommend it, even though it is not their native tongue. By all means, I do not promote destroying cultures, but learning a common language brings us all closer together. :)
I like the sentiment, but might I point out that the early inventors of television believed that it might end war by showing the great similarities between peoples and nations.
And that from domestic violence to wars, we tend to fight those who are next-door, closest to us in mind body and spirit.
(If you are not too sure about that, think how easily a rural Shinto Chinese would be able to explain the vast differences between Christianity and Islam)
And that from domestic violence to wars, we tend to fight those who are next-door, closest to us in mind body and spirit.
(If you are not too sure about that, think how easily a rural Shinto Chinese would be able to explain the vast differences between Christianity and Islam)
Shinto Chinese?
Yeah that was dumb of me. I may have been thinking Shenism, but I am sure there are some Shinto Chinese.
Anyway the point I am making still holds I think - you can barely squeeze a credit card between Islam and Christianity if viewed from a distance - yet billions are on the edge because of the "vast gulf" between the religious
Anyway the point I am making still holds I think - you can barely squeeze a credit card between Islam and Christianity if viewed from a distance - yet billions are on the edge because of the "vast gulf" between the religious
Hmm my suggestions:
- Please make the "show changes" scale to large code changes.
I've been bitten by hanging browsers a few times while trying to review pull requests in which many files were changed significantly or added. One (simple) way would be to show just the changed files, in collapsed form, which can be expanded.
- Add a way to increase the size of the diff context
Sometimes the given context is not large enough, especially if a file has many similar functions. For example in vimdiff you can "expand the hidden lines" in this case.
- Please make the "show changes" scale to large code changes.
I've been bitten by hanging browsers a few times while trying to review pull requests in which many files were changed significantly or added. One (simple) way would be to show just the changed files, in collapsed form, which can be expanded.
- Add a way to increase the size of the diff context
Sometimes the given context is not large enough, especially if a file has many similar functions. For example in vimdiff you can "expand the hidden lines" in this case.
Disclaimer: I'm the founder of a company that has been working on solving the problems that you have described for the last year.
Having developed internal tools for large enterprise environments with over 50,000 developers with massive code bases (think linux kernel times 10), it has always baffled me why GitHub and others seem to think stuffing all the changes on a single page is a good idea.
Sure it's great when the changes are small but having to deal with large changes is not an unusual edge case. Especially in the enterprise environment where process and politics tends to create backlogs in merging which forces us to have to deal with large changes at once.
Below are some sample screen shots with how we deal with changes.
Viewing pull request detail
http://6b507fb6377c7b2ce0ed-f6f6a52addfcf546a4b633fce1dd247e...
If the changes are really massive, we offer the ability to navigate the changes as a code churn tree. We call this the divide and conquer way of managing large diffs.
http://6b507fb6377c7b2ce0ed-f6f6a52addfcf546a4b633fce1dd247e...
We also make it possible for you to break apart the commits that are included in the pull request with our commits browser. Note the revisions tree on the left that shows you all the revisions.
http://6b507fb6377c7b2ce0ed-f6f6a52addfcf546a4b633fce1dd247e...
As for the diff issue. We have the ability for you to create your own custom diff views. See the following screen shot.
http://6b507fb6377c7b2ce0ed-f6f6a52addfcf546a4b633fce1dd247e...
With the custom diff view, we make it very easy for you to manipulate the diff output.
Having developed internal tools for large enterprise environments with over 50,000 developers with massive code bases (think linux kernel times 10), it has always baffled me why GitHub and others seem to think stuffing all the changes on a single page is a good idea.
Sure it's great when the changes are small but having to deal with large changes is not an unusual edge case. Especially in the enterprise environment where process and politics tends to create backlogs in merging which forces us to have to deal with large changes at once.
Below are some sample screen shots with how we deal with changes.
Viewing pull request detail
http://6b507fb6377c7b2ce0ed-f6f6a52addfcf546a4b633fce1dd247e...
If the changes are really massive, we offer the ability to navigate the changes as a code churn tree. We call this the divide and conquer way of managing large diffs.
http://6b507fb6377c7b2ce0ed-f6f6a52addfcf546a4b633fce1dd247e...
We also make it possible for you to break apart the commits that are included in the pull request with our commits browser. Note the revisions tree on the left that shows you all the revisions.
http://6b507fb6377c7b2ce0ed-f6f6a52addfcf546a4b633fce1dd247e...
As for the diff issue. We have the ability for you to create your own custom diff views. See the following screen shot.
http://6b507fb6377c7b2ce0ed-f6f6a52addfcf546a4b633fce1dd247e...
With the custom diff view, we make it very easy for you to manipulate the diff output.
@wladimir Have a look at the Firefox userscript I wrote very recently: http://userscripts.org/scripts/show/153049 -- feedback welcome!
Of course it doesn't eliminate the big initial fetch from the served, just collapses it once loaded to have more friendly UI.
Thanks for the link, looks useful.
That would be functionality that should be in Github itself. Good to see that I'm not the only one with that pet peeve.
That would be functionality that should be in Github itself. Good to see that I'm not the only one with that pet peeve.
Would be nice to have a mega refactor function that could check for duplicate all over the public repos. So, for instance, my "capitalize function" could be tagged as duplicate and I could see multiple projects having a better one.
I appreciate this guy's effort, but honestly most of his concerns has ever impacted my productivity. Sure, the editor isn't great yet. What I really want to see, and I'm not the first to say this:
* Explicit licenses: If a repo lacks a LICENSE file, this is almost as annoying as it lacking a README, and GitHub's interface should complain to the repo owner. Searching and filtering by license would be nice, too.
* Explicitly "official" forks. It's way too hard to find the right fork when you just want to improve a public gem, for instance. I was there was an explicit "why does this fork exist" field on each repo. acts_as_solr is a particularly morbid example of why this is important.
* Their code search is basically useless. Last I checked, they don't even index branches. They should just buy or reimplement Ohloh.
* Explicit licenses: If a repo lacks a LICENSE file, this is almost as annoying as it lacking a README, and GitHub's interface should complain to the repo owner. Searching and filtering by license would be nice, too.
* Explicitly "official" forks. It's way too hard to find the right fork when you just want to improve a public gem, for instance. I was there was an explicit "why does this fork exist" field on each repo. acts_as_solr is a particularly morbid example of why this is important.
* Their code search is basically useless. Last I checked, they don't even index branches. They should just buy or reimplement Ohloh.
Shameless plug, searchco.de allows you to search over github,
http://searchco.de/?q=irq_create_mapping+url%3Agithub
You just need to add the url:github portion to any search. No branch support yet, but working on it. I doubt they will be able to buy Ohloh though as that's owned by BlackDuck. I also find Ohloh search lacking in some areas such as the following search,
http://searchco.de/?q=%3D~+lang%3Aperl http://code.ohloh.net/search?s=%3D~&browser=Default
http://searchco.de/?q=irq_create_mapping+url%3Agithub
You just need to add the url:github portion to any search. No branch support yet, but working on it. I doubt they will be able to buy Ohloh though as that's owned by BlackDuck. I also find Ohloh search lacking in some areas such as the following search,
http://searchco.de/?q=%3D~+lang%3Aperl http://code.ohloh.net/search?s=%3D~&browser=Default
I thought it worth mentioning that everyone opposed to this idea is capable of communicating in English. I am guilty of being monolingual, but if the most popular online source code management community used a language X that I did not know how to speak (especially if X was considered the lingua franca of software development), it would be a huge barrier of entry to me. While I would do well to learn X, an english localization of that platform would greatly ease my transition and encourage me to communicate with the predominantly-X speaking community. I would like to get the opinions on localization of github from people who are currently unable to communicate in English with a high enough proficiency to read these comments and voice their position here.
So apparently this is the new standard in job applications.
GitHub used to have localization, back before I joined, but it got dropped. Many non-native speakers switched to English anyways, and it just wasn't worth the effort and maintenance hassle.
I think localisation makes sense for the docs. Maybe we can branch off from here and coordinate the efforts. I myself am ready to work on Arabic and would love to have people join me.
I agree, that's where the localisation should go. Github has many things and for a first timer the docs are invaluable, but if you're a non-native speaker having them in your own language is going to help you ramp up to speed on using it that much quicker.
Code search would also be useful, even if just string search. Or filename. E.g. somewhere in this repository there's a file called mysettings.xml
[Yes, I know I could check it out, but still...]
[Yes, I know I could check it out, but still...]
Shameless plug, searchco.de allows you to search over github's public repositories,
http://searchco.de/?q=irq_create_mapping+url%3Agithub
http://searchco.de/?q=irq_create_mapping+url%3Agithub
Code search is available - if somewhat hidden. Add /search to the end of the repository url on github (eg. https://github.com/rails/rails/search ).
On any repo page you can just press t and you can search by filename.
for filename, go to the repository (code) window and press 't' , it will give you a command-t type interface to search for filenames in the project.
From what I remember, Github had localization going on but pulled the plug at some point because it was too much of a clusterfk.
I was surprised not to see any mention of the only thing that irks me: the "Switch account context" dropdown menu being available only on the front page and not in the top bar where your account is displayed. That would save me quite a bit of gymnastic to have that displayed on all pages.
I was surprised not to see any mention of the only thing that irks me: the "Switch account context" dropdown menu being available only on the front page and not in the top bar where your account is displayed. That would save me quite a bit of gymnastic to have that displayed on all pages.
Better search in Starred projects! I can rarely find a project I have starred.
While it may be an intentional shortcoming, I feel GitHub is lacking in general discussion. Sometimes I just want to ask the developer a question about their code. Usually what I do is look for their Twitter account and @mention the question over to them. It would be nice to find a discussion around a particular repo just as we have here on Hacker News.
Let's volunteer to work for a commercial entity for free?
No thanks. They're doing fine, they can easily afford to pay people to do this if it's necessary. Volunteer your time for non-commercial projects that do not have the option of paying people a fair wage for their work.
No thanks. They're doing fine, they can easily afford to pay people to do this if it's necessary. Volunteer your time for non-commercial projects that do not have the option of paying people a fair wage for their work.
This is a great personal effort to bring improvements to a platform we all know and love - I've got many friends overseas who all speak (and most critically - think ) in English to varying degrees.
Localization is never a wasted effort.
I hope they hire you Garen!
Localization is never a wasted effort.
I hope they hire you Garen!
The first thing I do when I come across a site that tries to speak my language? I switch it back to english.
Localization makes sense when you're a shopping site aiming at mom & dad and non-techies.
For technical services (pretty much all SaaS) the translations usually turn out so terrible that everyone turns them off. Also good luck googling for the solution to a problem in any other than the primary language of the site...
Localization makes sense when you're a shopping site aiming at mom & dad and non-techies.
For technical services (pretty much all SaaS) the translations usually turn out so terrible that everyone turns them off. Also good luck googling for the solution to a problem in any other than the primary language of the site...
I know this is a call for help, but I find it funny that their big screenshot in spanish makes no sense to this native speaker.
I'd love to see a "grouped" pull request option. Something that would let me say show me changes from repo1 + repo2 because they depend on each other. Think refactoring code into a smaller repo, etc. I deal with this quite a bit with clients as they grow from small apps into much more complex apps with lots of inner dependencies and tests.
We (my company) actually take this to another level. We provide branch level grouping.
http://6b507fb6377c7b2ce0ed-f6f6a52addfcf546a4b633fce1dd247e...
The reason why we've created this feature was because in the enterprise world, it is not uncommon to construct a release based on branches from various repositories.
We also have a smart attributes technology that will allow you to assign arbitrary meta data to a pull request. With this technology, you'll be able to ask questions like show me all the pull requests that have a priority greater than X.
http://6b507fb6377c7b2ce0ed-f6f6a52addfcf546a4b633fce1dd247e...
The reason why we've created this feature was because in the enterprise world, it is not uncommon to construct a release based on branches from various repositories.
We also have a smart attributes technology that will allow you to assign arbitrary meta data to a pull request. With this technology, you'll be able to ask questions like show me all the pull requests that have a priority greater than X.
Some good points, but I disagree with the following.
- i18n and l10n
For reasons already stated by many others in this HN thread.
- Notifications should be more like email
Please no. I'm already terrified of my email inbox. It's a mess, so many messages. Sometimes I'll leave a message unread or mark it as unread if I want to return to it later but instead it gets buried by newer messages. So now I have a couple of hundred unread emails and I have no idea what they are but they surely can't be important.
Keep notifications how they are. It makes using GitHub stress free. If I read a notification, get rid of it so I never have to see it again. If it was so important, I should remember it anyway or I would have set it as my highest priority and worked on it right away.
- Revamp Inline Editing
Themes? Multiple cursors? Command line? Live linting? ... No thanks, sounds like feature-creep. I like the editor how it is, nice and simple. Want a full-blown editor? Don't use the web interface.
- Infinite newsfeed
There are reasons why many websites choose not to include infinite scrolling, see [1] for some good reasons.
One thing I'd like to see added to GitHub:
- View all public activity history
There's been many times when I want to look at my own history or someone else's and I can't because it stops after the first page.
[1] http://www.quora.com/Infinite-Scrolling/What-are-the-downsid...
- i18n and l10n
For reasons already stated by many others in this HN thread.
- Notifications should be more like email
Please no. I'm already terrified of my email inbox. It's a mess, so many messages. Sometimes I'll leave a message unread or mark it as unread if I want to return to it later but instead it gets buried by newer messages. So now I have a couple of hundred unread emails and I have no idea what they are but they surely can't be important.
Keep notifications how they are. It makes using GitHub stress free. If I read a notification, get rid of it so I never have to see it again. If it was so important, I should remember it anyway or I would have set it as my highest priority and worked on it right away.
- Revamp Inline Editing
Themes? Multiple cursors? Command line? Live linting? ... No thanks, sounds like feature-creep. I like the editor how it is, nice and simple. Want a full-blown editor? Don't use the web interface.
- Infinite newsfeed
There are reasons why many websites choose not to include infinite scrolling, see [1] for some good reasons.
One thing I'd like to see added to GitHub:
- View all public activity history
There's been many times when I want to look at my own history or someone else's and I can't because it stops after the first page.
[1] http://www.quora.com/Infinite-Scrolling/What-are-the-downsid...
You should add the stuff I posted about last year about this time. Basically my beef is forking being not very in the spirt of how it's supposed to work with git. http://zbowling.github.com/blog/2011/11/25/github/
Doesn't chrome have translation capabilities? I don't know if the translation capabilities can avoid translating code but if it could somehow (a do not translate tag or something) then localization could be done, locally...
Actually, more than labels (that would be good anyway) I would LOVE seeing the open/closed state of issues in notifications. I spend a lot of time checking new issues already closed by the other project maintainer.
Issues images, headshot: https://github.com/blog/1347-issue-attachments
And don't tell me that you Githubbers don't lurk over here ;)
And don't tell me that you Githubbers don't lurk over here ;)
"Bifurcar", that term may be correct, but it sounds awful to my ears.
It sounds weird indeed. The literal translation of branching would be «ramificar», which also doesn't seem right. That's the problem: everyone comes up with their own translations that are not what people refer to them in real life.
I say «crear una rama» (create a branch), while most of my friends just say «hacer un branch» (make a branch). And there are also the ugly anglicisms like «branchear» and «forkear».
I say «crear una rama» (create a branch), while most of my friends just say «hacer un branch» (make a branch). And there are also the ugly anglicisms like «branchear» and «forkear».
+1 for "likes" in issues.
Another feature missing: per branch access control
Yes! This would allow developers to set up premium branches: http://premium-branch.org
Didn't GitHub have localization at some point in the past? If I remember correctly, the footer had a world map background with links to other languages.
[deleted]
We did, and then we dropped it because a _very_ small percentage of users were on non-English locales.
Github shouldn't be localized...
Some projects wouldn't be viewed if it ain't in english, no one here almost speaks Chinese do they? :-)
Facebook should be localized, not github.
Some projects wouldn't be viewed if it ain't in english, no one here almost speaks Chinese do they? :-)
Facebook should be localized, not github.
Someone wants a job
I thought this was a GitHub promotion at first, but this is a genius form of self-marketing. Very creative, and very convincing!
I suggest read-only SSH keys for deployments.
Very interesting proposals overall, not too sure about the localization (don't most programmers speak English ?) though.
I think i18n makes sense - for docs. For getting people up and running. For explaining the benefits of github.
I think new pricing strategy could make github better.
I agree. I moved to bitbucket after canceling their small service because jumping from $12 to $22 just for a few more private repos. I wish they had more a of a hobbyist plan with maybe a storage limit or a $1 a repo type pricing. I didn't care for their practice of deleting forum posts every time someone would ask about similar questions. I still recommend them for my clients though.
How do people have so much free time lol?
And all of them use English terms for language identifiers.
English is the lingua franca of IT & software development. As a Brazilian I can tell you that programmers that don't learn at least how to read technical English won't become good practicioners.
And GitHub is a social platform for collaborating on projects. In the vast majority of projects, English is the common language spoken by all participants.
Learn English and get over it.
(I didn't read further into the article. I hope the other suggestions make more sense.)