"Ruby came from Japan. Lua came from Brazil. Python came from the Netherlands."<p>And all of them use English terms for language identifiers.<p>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.<p>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.<p>Learn English and get over it.<p>(I didn't read further into the article. I hope the other suggestions make more sense.)
I'm a native German speaker and this localization thing seems like a really bad idea.<p>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.<p>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.<p>In my opinion it works especially well for technical writing.
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.<p>> 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.<p>uhm, Sphinx?
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.<p>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.<p>Other than that, the suggestions listed sound nice to me.
Slightly meta -<p>If I was a business owner and a customer wrote something like this, I would be absolutely ecstatic.<p>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.<p>This is the real reason profit margins are so important to a <i>good</i> company. It means you can re-invest back into the growth of your product and continue to delight your customers.<p>Good on ya Github, keep it up.
A few items I'd like to see:<p>- Attachments in the issue tracker. Pictures tell a thousand words and it would be infinitely easier for user submitted issues to have screenshots.<p>- Better code search.<p>- 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.<p>- Better reliability.<p>It's a great tool. I really enjoy using it, but with a few additions it would be near perfect.
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 <a href="https://github.com/thisduck/gh-attachment" rel="nofollow">https://github.com/thisduck/gh-attachment</a> or <a href="http://feeding.cloud.geek.nz/2012/06/attaching-files-to-github-issues.html" rel="nofollow">http://feeding.cloud.geek.nz/2012/06/attaching-files-to-gith...</a> not to mention countless internal homegrown hacks that exist out there.<p>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.<p>I would definitely add this to the "I <heart> github, but..." list.<p>P.S., experiment0, great execution of a "feature request".
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:<p>- 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.<p>- 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).<p>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).<p>But hey, those are just my two cents...
What if we spent our time making GitLab (<a href="http://gitlabhq.com/" rel="nofollow">http://gitlabhq.com/</a>) better instead, since it's open source and users can host their own for free?
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.<p>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.<p>If Github incorporated this stuff, every project could seamlessly use CLAs.
The famous "hacker faq" recommends using English for a few reasons:<p><a href="http://www.catb.org/esr/faqs/hacker-howto.html#skills4" rel="nofollow">http://www.catb.org/esr/faqs/hacker-howto.html#skills4</a><p>Other than that...<p>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. :)
Hmm my suggestions:<p>- Please make the "show changes" scale to large code changes.<p>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.<p>- Add a way to increase the size of the diff context<p>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.
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:<p>* 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.<p>* 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.<p>* Their code search is basically useless. Last I checked, they don't even index branches. They should just buy or reimplement Ohloh.
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.
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.
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<p>[Yes, I know I could check it out, but still...]
From what I remember, Github had localization going on but pulled the plug at some point because it was too much of a clusterf<i></i>k.<p>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.
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?<p>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.<p>Localization is never a wasted effort.<p>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.<p>Localization makes sense when you're a shopping site aiming at mom & dad and non-techies.<p>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'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.
Some good points, but I disagree with the following.<p>- i18n and l10n<p>For reasons already stated by many others in this HN thread.<p>- Notifications should be more like email<p>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.<p>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.<p>- Revamp Inline Editing<p>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.<p>- Infinite newsfeed<p>There are reasons why many websites choose not to include infinite scrolling, see [1] for some good reasons.<p>One thing I'd like to see added to GitHub:<p>- View all public activity history<p>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.<p>[1] <a href="http://www.quora.com/Infinite-Scrolling/What-are-the-downsides-of-using-automatic-scrolling-pagination" rel="nofollow">http://www.quora.com/Infinite-Scrolling/What-are-the-downsid...</a>
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. <a href="http://zbowling.github.com/blog/2011/11/25/github/" rel="nofollow">http://zbowling.github.com/blog/2011/11/25/github/</a>
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: <a href="https://github.com/blog/1347-issue-attachments" rel="nofollow">https://github.com/blog/1347-issue-attachments</a><p>And don't tell me that you Githubbers don't lurk over here ;)
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.
Github shouldn't be localized...<p>Some projects wouldn't be viewed if it ain't in english, no one here almost speaks Chinese do they? :-)<p>Facebook should be localized, not github.