Linguist: reports wrong language even after I added gitattributes

Created on 26 May 2018 · 15Comments · Source: github/linguist

This file/project
https://github.com/metabake/pwa-router/blob/master/.gitattributes

shows as Java.

How do I fix it so it says JavaScript or nothing.

That is the file I added above, no joy.

Source

cekvenich

Most helpful comment

This isn't really bullying, but automated machine identification for convenience. What is happening is entirely automatic based purely on the content of your repository as detailed in How Linguist Works.

GitHub doesn't have a concept of a _"repository language"_ (or even a setting for this) and instead uses a concept of analysis to determine _"this repository is made up of these languages with X being the most prominent"_. Linguist is the code that does this. No humans are involved in this initial phase.

This is done for convenience. Imagine having to manually identify the language of every single file (all 1894 of them) in your repo yourself 😶.

As this is entirely automated, the only way you can change the behaviour if you don't like it (it's technically correct) is to override it with the settings you wish to have.

In your case, Linguist has analysed your entire repository and determined the breakdown of the languages and set the language break down in the languages bar accordingly:

screen shot 2018-05-27 at 16 38 26

This breakdown is because those are the types of files in your repository with Java being the largest by bytes of code (click it and see all those files), hence it becomes the language shown when viewing the list of repositories. This is _not_ intended to state the repo language, just the predominant language.

If you really want to represent your repository as predominantly Javascript in the language bar, then you need to either tell Linguist to consider all other files as "vendored", "generated" or "documentation", write more Javascript 😉, or use a complete override for all files and this is done via the .gitattributes file, though this _will_ affect syntax highlighting of those files too. If you think about it, nothing else in the GitHub interface gives you this level of control over the interface appearance and behaviour, so I'd consider this a big win - GitHub could legitimately "bully" you and _not_ make this configurable, but they don't.

So back to your original issue. The quickest and dirtiest solution is to mark all files as Javascript:

* linguist-language=JavaScript

From looking at your commit history, I'm surprised to see you didn't even try this. You were close, but your change only marked all files with the .rb extension as Javascript but your repo doesn't include any .rb files, hence it has no effect.

But as I said, this will also affect syntax highlighting of those non-Javascript files.

If all you want is for the Java here:

metabake org 2018-05-27 16-44-15

... to say Javascript without affecting syntax highlighting of the suppressed files, then you will need to suppress the other files using "vendored", "generated" or "documentation". In this case, "vendored" is probably the right thing to do as you didn't write this code.

This:

platforms/* linguist-vendored=true
plugins/* linguist-vendored=true
public/* linguist-vendored=true

... produces this:

screen shot 2018-05-27 at 17 01 24

... which makes Javascript the predominant language when looking at the list of repos:

screen shot 2018-05-27 at 16 54 24

The paths used here were easily determined by clicking on the respective languages in the language bar and looking for a common path.

You can further manipulate the analysis yourself by using various other paths and override options.

All of this information is included in the README in some form or another, hence the recommendation, and encouragement, via hinting, for you to give it a go in the template. A little bit of tinkering whilst reading the README would have brought you to a similar position, in very little time.

Commits are cheap. Go wild. Experiment. Celebrate success 🎉

That all said, is there something we could have done with the documentation to make this clearer for you to work out for yourself?

lildude on 27 May 2018

👍5

All 15 comments

Please fill in the issue template.

pchaigno on 26 May 2018

Seems like Github staff is going around bullying projects. Why go around mislabeling projects to being with!

cekvenich on 27 May 2018

👎2

@cekvenich: @pchaigno isn't GitHub staff 😄and he's not bullying. I'm not sure I understand what the mislabelling is you're referring to either.

As for the request: we have the template for a few reasons: 1) to help you help yourself, and 2) so we have an idea of where to start investigating any legitimate problems that get through.

In your case, your "problem" isn't a problem, but a preference and a misunderstanding of how Linguist works. This is addressed in the docs mentioned right at the beginning of the template. In short, you're not using .gitattributes correctly and the docs should help you solve the problem.

lildude on 27 May 2018

Oh yes, and if there's something not clear in the docs, please let us know and we'll certainly help clarify and even update the docs.

lildude on 27 May 2018

I said bullying because you guys go to my project and put a wrong label. That is developer bullying.
I now have to add a file. Bullying. That is not a git file, that is you forcing people using github to do things. Bullying.

And then when I ask: OK, take my lunch money, do you want cash or check - you add some other bs.
On a normal project asking for formatting a request is normal. Clearly I felt that a punching back is better than cowering.

cekvenich on 27 May 2018

😄1

Non bullying would be: opting in.
At least allow opt out.
In worse case - show how to manually set. Github culture has a reputation prior to this.

cekvenich on 27 May 2018

This is done for convenience. Imagine having to manually identify the language of every single file (all 1894 of them) in your repo yourself 😶.

As this is entirely automated, the only way you can change the behaviour if you don't like it (it's technically correct) is to override it with the settings you wish to have.

In your case, Linguist has analysed your entire repository and determined the breakdown of the languages and set the language break down in the languages bar accordingly:

screen shot 2018-05-27 at 16 38 26

So back to your original issue. The quickest and dirtiest solution is to mark all files as Javascript:

* linguist-language=JavaScript

But as I said, this will also affect syntax highlighting of those non-Javascript files.

If all you want is for the Java here:

metabake org 2018-05-27 16-44-15

This:

platforms/* linguist-vendored=true
plugins/* linguist-vendored=true
public/* linguist-vendored=true

... produces this:

screen shot 2018-05-27 at 17 01 24

... which makes Javascript the predominant language when looking at the list of repos:

screen shot 2018-05-27 at 16 54 24

The paths used here were easily determined by clicking on the respective languages in the language bar and looking for a common path.

You can further manipulate the analysis yourself by using various other paths and override options.

Commits are cheap. Go wild. Experiment. Celebrate success 🎉

That all said, is there something we could have done with the documentation to make this clearer for you to work out for yourself?

lildude on 27 May 2018

👍5

I have the same problem here: https://github.com/fabiocaccamo/django-admin-interface/

fabiocaccamo on 13 Jun 2018

@fabiocaccamo Please check How Linguist works, Troubleshooting for a solution to your issue, and consider implementing an override.

pchaigno on 13 Jun 2018

People should not be forced to play with your project, stop bullying people. Just don't mess with our projects.

cekvenich on 13 Jun 2018

I already checked the documentation, as you can see in my .gitattributes I just added:
admin_interface/static/ckeditor/* linguist-vendored=true, but it seems that .gitattributes is ignored by linguist, then the vendored path remains indexed.

fabiocaccamo on 13 Jun 2018

@fabiocaccamo admin_interface/static/admin/js/popup_response.js and admin_interface/static/admin_interface/related-modal/related-modal.js are not matched by that rule. Maybe you can try the following: