Timeline for Stop guessing/auto-detecting a language when you KNOW it will be incorrect
Current License: CC BY-SA 4.0
45 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 8 at 16:12 | answer | added | Josh WolsbornStaffMod | timeline score: 24 | |
| Oct 8 at 16:10 | history | edited | Josh WolsbornStaffMod |
edited tags
|
|
| Jun 7, 2022 at 10:51 | history | edited | This_is_NOT_a_forum | CC BY-SA 4.0 |
(OK, bumped, but it was referenced in an MSO question today (<https://meta.stackoverflow.com/questions/418564/>)) [<https://en.wiktionary.org/wiki/autodetect#Verb> <https://en.wiktionary.org/wiki/let%27s#Etymology>]. Added some context. [(its = possessive, it's = "it is" or "it has")].
|
| Apr 1, 2021 at 19:52 | history | edited | Adam LearStaffMod |
edited tags
|
|
| Apr 1, 2021 at 19:52 | answer | added | Adam LearStaffMod | timeline score: 13 | |
| S Feb 21, 2021 at 15:04 | history | bounty ended | reneMod | ||
| S Feb 21, 2021 at 15:04 | history | notice removed | reneMod | ||
| Feb 15, 2021 at 18:19 | answer | added | animusonStaffMod | timeline score: 5 | |
| S Feb 15, 2021 at 14:37 | history | bounty started | reneMod | ||
| S Feb 15, 2021 at 14:37 | history | notice added | reneMod | Draw attention | |
| Oct 29, 2020 at 11:56 | comment | added | Luuklag | Fair enough @JoshGoebel | |
| Oct 29, 2020 at 11:55 | comment | added | Josh Goebel | @Luuklag Perhaps. :) Was hoping to get one or two beta users first. :) | |
| Oct 29, 2020 at 5:30 | comment | added | Luuklag | @JoshGoebel you might be better off writing that as an answer for increased visibility. | |
| Oct 28, 2020 at 23:59 | comment | added | Josh Goebel |
@zcoop98 Thanks. Also perhaps now relevant: github.com/joshgoebel/se_highlightjs Supports lang-X hints, bumps the version of Highlight.js to the very latest, and doesn't require use of a CDN. :-)
|
|
| Oct 28, 2020 at 21:13 | history | edited | This_is_NOT_a_forum | CC BY-SA 4.0 |
Active reading [<https://en.wikipedia.org/wiki/Visual_Basic_.NET>]. Used more standard formatting (we have italics and bold on this platform).
|
| Oct 28, 2020 at 14:56 | comment | added | zcoop98 |
Oh yeah! Wanted to plug this relevant user script by @LionelRowe that does implement lazy loading of highlight.js language libraries. It only works when the language is specifically specified by a lang-X identifier (rather than a tag), however, it does succeed in highlighting languages currently unsupported by SE.
|
|
| Oct 28, 2020 at 1:05 | comment | added | Josh Goebel | Updated the question to mention lazy-loading and also include a small primer on auto-detect and why this situation (a missing language grammar) is a worst-case situation and why it's likely to result in such bad outcomes. | |
| Oct 28, 2020 at 0:54 | history | edited | Josh Goebel | CC BY-SA 4.0 |
mention lazy-loading
|
| S Oct 28, 2020 at 0:27 | history | suggested | 41686d6564 |
Added relevant tag
|
|
| Oct 28, 2020 at 0:23 | review | Suggested edits | |||
| S Oct 28, 2020 at 0:27 | |||||
| Oct 28, 2020 at 0:01 | comment | added | Josh Goebel |
ending the practice of tags lacking a specified highlighting language triggering auto-detect As you say that might be too radical. Really a list of all valid language tags is necessary... so that when given a tag the JS can query "is groovy a language tag or a generic concept tag"? And if it's a language (one that's simply not in the default bundle) then that would either key the lazy-load - or simply turn off highlighting for that block.
|
|
| Oct 27, 2020 at 23:54 | comment | added | Josh Goebel |
@zcoop98 if the language specified/ detected wasn't already loaded This wording is a bit confusing. A language grammar must first be loaded before it can be auto-detected... so there is no such thing as "This looks like Groovy, so now lazy load Groovy". But if a post was hinted groovy then SE could choose to lazy load Groovy and use that explicitly. Or if a post was tagged groovy (among other things) then SE could lazy load groovy before highlighting and then auto-detect would consider groovy as a possibility when doing the analysis.
|
|
| Oct 27, 2020 at 23:48 | history | edited | Josh Goebel | CC BY-SA 4.0 |
Use correct terminology of "hinting" for language labels
|
| Oct 27, 2020 at 22:34 | comment | added | 41686d6564 | The term is called hints (language hints) and it has its own tag. See this answer (which is also relevant to this post) for usage of the term. | |
| Oct 27, 2020 at 22:08 | comment | added | zcoop98 |
Especially since, in the specific case you mentioned, specifying groovy simply points to the language specified by the tag groovy, which is default/ auto-detect.
|
|
| Oct 27, 2020 at 22:06 | comment | added | zcoop98 |
One way to approach this is by ending the practice of tags lacking a specified highlighting language triggering auto-detect... but that may do more harm then good, since there are plenty of tags where a language simply doesn't make sense, especially the ones denoting concepts rather than libraries or languages (eg. array). I think you nailed it in your comment- the best case scenario from a usage POV would be to lazy load it if the language specified/ detected wasn't already loaded.
|
|
| Oct 27, 2020 at 17:38 | comment | added | Josh Goebel | Absolutely. Lazy-loading is the answer if the goal is to correctly highlight as many languages as possible as correctly as possible. Though SE has mentioned the monetary bandwidth costs as well, not just the bundle size from a time perspective. Creative client-side caching would help a lot there I think because once you downloaded a grammar a single time there’s no need to ever download it again. At least not until a new version of library is used. | |
| Oct 27, 2020 at 17:22 | comment | added | Makyen | It would also be possible to lazy-load a more complete set (or just a differentset) of grammars based on either the specified language or the language specified as the default for the tag (currently, there's a very limited list of permitted tag default syntax highlighting languages, so that would need to change). Being able to load more languages, or even the entire language set, doesn't require that the entire language set be downloaded for every page. It's more complicated, but SE already has a mechanism in place in the JavaScript to lazy-load additional packages when needed/desired. | |
| Oct 27, 2020 at 16:58 | history | edited | Josh Goebel | CC BY-SA 4.0 |
Add a small primer on why this is especially bad for auto-detect
|
| Oct 27, 2020 at 15:06 | comment | added | Josh Goebel | Automatic detection can always lead to random behavior... No... the hope is you get predictable behavior based on relevant content (when there is enough signal in the snippet) - not random behavior. But when you remove the "right" answer (purposely don't load a grammar, etc.) and then make the highlighter choose from a bunch of sub-optimal answers [none of them good matches]... you're far more likely to get randomness since you have no idea what the correct signal even is. | |
| Oct 27, 2020 at 14:56 | comment | added | Josh Goebel | As for Groovy, StackOverflow could just enable the Groovy grammar. I'm pretty sure it's a space/size concern not a reliability concern. Every language makes their site slower to download... our library is almost 1mb if you include every language, yet ~50kb for a small popular set of languages. Does the highlight.js auto-detection gets things more often wrong if the number of possible languages increases? That's certainly a possibility (more to choose from) though SE could mitigate it greatly with smarter usage of tags to clue the auto-detection. | |
| Oct 27, 2020 at 14:54 | comment | added | Josh Goebel |
Auto-detect allows post authors to use less effort - you don't need to think about tagging every snippet. This can often work very well when paired with post tag context... i.e. a post tagged "javascript" is far more likely to be javascript than say sql. (Though SE still has tons of room to improve here also.) I'm not suggesting we remove ALL auto-detection, only auto-detect where it's known in advance the outcome is likely to be poor. (such as when a grammar is requested that SE has chosen not to load)
|
|
| Oct 27, 2020 at 14:29 | comment | added | NoDataDumpNoContribution | I fully agree with the question, but I wonder what the automatic detection is then good for? It seems to be only good for cases where the content creator itself has no clue what the language is of the code, he/she just provided. And then we would again get potential random behavior. Automatic detection can always lead to random behavior, or not? As for Groovy, StackOverflow could just enable the Groovy grammar. Does the highlight.js auto-detection gets things more often wrong if the number of possible languages increases? | |
| Oct 27, 2020 at 13:01 | comment | added | Josh Goebel | That's a big reason we default to "no highlight"... it's a warning that's hard to miss - doesn't require reading - yet provides immediate feedback to the user. :-) And if someone was a regular SO user they'd very quickly learn what no highlighting signaled: an unsupported language or a typo in language name. Inconsistent highlighting is a lot harder to "see" at a glance, making it far worse feedback. Perhaps even impossible without multiple examples. | |
| Oct 27, 2020 at 12:54 | comment | added | Mast | If only people would actually read the warnings. | |
| Oct 27, 2020 at 12:41 | comment | added | Josh Goebel |
SE's current behavior doesn't do anything to help with this confusion though. There is a reason our default behavior (as a library) is to fallback to NO highlighting when an incorrect or unknown language is provided. It provides feedback... makes it clear something is wrong, ie that the language "is not supported". Perhaps the user typed it wrong. We also log an error to the console, but SE could of course make a visual warning if they chose: groovy is not a supported language currently - [link to supported list]. They could even do this during composition.
|
|
| Oct 27, 2020 at 12:36 | comment | added | Luuklag | that is also in part because people don't check which languages are supported, and hence assume that certain behaviour is supported whilst it isn't. Which then in the end leads to confusion. | |
| Oct 27, 2020 at 12:36 | history | edited | Josh Goebel | CC BY-SA 4.0 |
re-order tp tru and get better summary in the index view
|
| Oct 27, 2020 at 12:33 | comment | added | Josh Goebel | I think the most important thing here is to avoid the appearance of "random" behavior with the highlighting. When someone goes to the trouble to manually specify the correct language the last thing they should expect to see is entirely random highlighting. | |
| Oct 27, 2020 at 12:28 | history | edited | Yaakov EllisStaffMod |
edited tags
|
|
| Oct 27, 2020 at 12:26 | history | edited | Josh Goebel | CC BY-SA 4.0 |
deleted 26 characters in body
|
| Oct 27, 2020 at 11:40 | history | edited | Luuklag |
edited tags
|
|
| Oct 27, 2020 at 11:27 | history | edited | Shadow Wizard | CC BY-SA 4.0 |
added 7 characters in body; edited tags
|
| Oct 27, 2020 at 9:43 | history | edited | Luuklag | CC BY-SA 4.0 |
added 26 characters in body
|
| Oct 27, 2020 at 9:37 | history | asked | Josh Goebel | CC BY-SA 4.0 |