Comment github détermine-t-il le langage d’un projet?

Je travaillais récemment sur un projet github à la fois en JavaScript et en C ++, et j’ai remarqué que github marquait le projet en C ++. Si vous devez choisir une seule langue, il s’agit probablement de la désignation correcte puisque le code C ++ est compilé en tant que bibliothèque JavaScript, mais cela m’a incité à me demander comment github détermine la langue à utiliser pour chaque projet.

Mise à jour d’avril 2013, par nuclearsandwich (équipe de support GitHub ou “supportocat”):

  • La page d’aide ” Mon référentiel est marqué comme étant la mauvaise langue ” mentionne l’utilisation de la bibliothèque linguist pour déterminer le langage de fichier pour la mise en évidence de la syntaxe et les statistiques de pension. Linguist exclura certains noms de fichiers et chemins d’access des statistiques, à l’ exclusion de certains fichiers et répertoires de fournisseurs .

  • la page d’aide ” Pourquoi ma langue préférée n’est-elle pas reconnue? ” ajoute:

Si la langue de votre choix ne reçoit pas de surlignage de syntaxe, vous pouvez consortingbuer à la bibliothèque Linguist pour l’append.


(Réponse originale, octobre 2012)

Ce fil sur le support GitHub l’ explique:

Il résume simplement la taille des fichiers pour chaque extension. Le plus grand “gagne”.

Nous aimerions éviter d’ouvrir des fichiers et d’parsingr leur contenu, car les deux ralentiraient le processus … mais cela pourrait être la seule méthode de résolution des conflits comme celui-ci.

Comme ce n’est pas précis à 100%, cela a amené certains à append:

Moi aussi, je voterais pour un simple interrupteur manuel pour les cas où la supposition est fausse.


Note: comme Mark Rushakoff le mentionne dans sa réponse (voté en faveur), la conjecture s’est améliorée depuis lors avec le projet linguist (open-source de juin 2011).
Vous pouvez voir qu’il y a encore des problèmes cependant: Problèmes liés aux linguistes GitHub .
Voir ici pour plus de détails :

Une fois la langue détectée, elle est transmise à Albino , un wrapper Pygments qui effectue la mise en évidence de la syntaxe.

Et vous pouvez append des directives de linguiste dans un fichier .gitatsortingbutes .

Actuellement, le projet de linguiste de Github est ce qui est utilisé pour déterminer les statistiques linguistiques, comme décrit dans cet article du blog Github (qui est sorti quelques mois après que cette question ait été posée à l’origine).

Tout d’abord, sachez que vous pouvez remplacer la langue détectée pour les fichiers de votre référentiel en utilisant les substitutions Linguist .

En quelques mots,

  1. Chaque référentiel est étiqueté avec la première langue des statistiques de langue .
  2. Les statistiques de langue comptent la taille totale des fichiers pour chaque langage de programmation ou de balisage détecté. Les fichiers vendus, la documentation et les fichiers générés ne sont pas comptabilisés.
  3. La langue de chaque fichier est détectée par le projet open source Linguist .

Comment Linguist détecte-t-il les langues?

Le linguiste s’appuie sur les stratégies suivantes , dans l’ordre, et renvoie le langage dès qu’il a trouvé une correspondance parfaite (stratégie avec un seul langage renvoyé).

  1. Recherchez les modelines d’Emacs et de Vim .
  2. Nom de fichier connu. Certains noms de fichiers sont associés à des langages spécifiques (pensez à Makefile ).
  3. Cherchez un shebang. Un fichier avec un #!/bin/bash shebang sera classé comme Shell.
  4. Extension de fichier connue. Les langues ont un ensemble d’extensions qui leur est associé. Il y a cependant beaucoup de conflits avec cette stratégie. Les résultats contradictoires (pensez à C ++, C et Objective-C pour .h ) sont affinés par les stratégies suivantes.
  5. Un ensemble de règles heuristiques . Ils utilisent généralement des expressions régulières sur le contenu des fichiers pour essayer d’identifier la langue (par exemple, ^[^#]+:- pour Prolog ).
  6. Un classificateur naïf bayésien formé sur des fichiers d’exemple . Dernière stratégie, la plus faible précision. Le classificateur bayésien prend toujours un sous-ensemble de langues en entrée; il n’est pas destiné à classer parmi toutes les langues. La meilleure correspondance trouvée par le classificateur est renvoyée.

Quels sont les fichiers de documentation et de non-redissortingbués?

Le linguiste considère certains fichiers comme étant vendus , ce qui signifie qu’ils ne sont pas inclus dans les statistiques linguistiques. Celles-ci incluent des bibliothèques tierces telles que jQuery et sont définies dans le fichier de configuration vendor.yml . Vous pouvez également fournir des fichiers de fournisseur ou de désvendeur dans votre référentiel en utilisant des substitutions Linguist .

De même, les fichiers de documentation sont définis dans documentation.yml et peuvent être modifiés à l’aide des substitutions Linguist .

Comment les fichiers générés sont-ils détectés?

Linguist s’appuie sur des règles simples pour détecter les fichiers générés, en utilisant à la fois les chemins d’access et le contenu des fichiers. Les fichiers générés ne sont pas comptabilisés dans les statistiques de langue et ne sont pas affichés dans diffs sur github.com.

Qu’en est-il des langages de programmation et de balisage?

Dans Linguiste, chaque langue reçoit un type. Ces types peuvent être trouvés dans le fichier de configuration principal, languages.yml . Seuls les langages de programmation et de balisage sont comptabilisés dans les statistiques.

Après quelques retouches avec les linguistes, je l’ai remarqué.

Pour les fichiers avec un Shebang , le Shebang est pris en compte lors de la détermination de la langue mais semble être pondéré de manière égale par rapport aux autres jetons . Cela semble être une grosse erreur car le Shebang devrait définir définitivement la langue du fichier.

Cela peut entraîner des problèmes de mise en évidence.