Rewrite and reformat documentation of languages.yml
#7495
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
This pull-request is a rewrite of the comment-header at the start of
languages.yml
, which currently serves as the file's only canonical documentation. Aside from being ordered arbitrarily, it also contains some falsehoods sitting in plain sight:As we all know,
nil
isn't a valid language type. This field is mandatory.This hasn't been true for a while. These colours are used to identify the languages of search results, and are also visible if
linguist-detectable
is used to includedata
andprose
languages in language breakdown graphs.Other improvements include:
name.downcase
may be obvious to a Ruby programmer, but less so to a novice coder who's only ever seentoLowerCase()
used, for example).a String name
,an Array of
, etc).interpreters
field if they've only ever worked in an IDE). This holds especially true for anybody whose English may not be perfect.Please let me know if anything sticks out as strangely-worded or whatever. I spent so much time juggling words and resmithing paragraphs, I developed tunnel vision. It may need a second pair of eyes that aren't glazing over like mine are right now.
Footnotes
Yes, I'm aware that the
type
field is ordered before the rest of the required fields. That's because it's the most important field of the group, so I'm abusing the same arbitrary logic we employ for primary extensions sorted before an alphabetised list. Deal with it. β©