Closed
Bug 1180022
Opened 9 years ago
Closed 8 years ago
Should accept kuma macros in comments or links
Categories
(developer.mozilla.org Graveyard :: BrowserCompat, defect)
developer.mozilla.org Graveyard
BrowserCompat
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: teoli, Unassigned)
References
Details
(Whiteboard: [bc:infra])
What did you do? ================ Comments often have macros that automate linking. Among them: {{bug}} and {{domxref}} They also contains links to other pages. What happened? ============== Scaping failed What should have happened? ========================== Scraping succeeded, by replacing the macro to a correct text in the correct format. Is there anything else we should know? ====================================== This is one of the most common cases that we cannot fix without doing monkey work.
Reporter | ||
Comment 1•9 years ago
|
||
See for example: http://browsercompat.herokuapp.com/importer/648
Comment 2•9 years ago
|
||
Yes, this needs to be handled in the importer.
Updated•9 years ago
|
Component: General → BrowserCompat
Updated•9 years ago
|
Summary: Compat importer should accept macros in comments or links → [Compat Data][Importer] Should accept kuma macros in comments or links
Comment 3•9 years ago
|
||
What's the status on that one, solved?
Comment 4•8 years ago
|
||
{{bug}} was fixed in bug 1188049. {{domxref}} was improved at the end of August [1] to include a link to the MDN page. There are still some KumaScript macros that will cause errors. Unknown KumaScript macros are not known to the importer [2], causing 34 errors across 18 pages. Some KumaScript macros are known to the importer, but cause errors if they are using in an unexpected context [3], causing 110 errors on 69 pages. Finally, if a KumaScript macro has the wrong number of arguments, the importer adds an error [4], causing 5 errors on 3 pages. For most cases, these errors can be fixed by changing the page. For example, {{unimplemented_inline("825294")}} can be moved to {{bug("825294")}} in a footnote. {{SVGRef}} is safe if it is separated from the compatibility tables with a <h2 id="See_also">See also</h2> header. :teoli, if this is acceptable, can you close this bug as resolved? If you feel a macro should be fixed in the importer rather than in the page, please file a bug blocking bug 1181140, or comment on a bug already filed against it [5]. These targeted bugs will help prioritize the remaining work. [1] https://github.com/mdn/browsercompat/commit/9de3b4b8f90910543d639c2f098e54f903e71afb [2] https://browsercompat.herokuapp.com/importer/issues/unknown_kumascript [3] https://browsercompat.herokuapp.com/importer/issues/unexpected_kumascript [4] https://browsercompat.herokuapp.com/importer/issues/kumascript_wrong_args [5] https://bugzilla.mozilla.org/showdependencytree.cgi?id=1181140&hide_resolved=1
Blocks: 1181140
Flags: needinfo?(jypenator)
Updated•8 years ago
|
Keywords: in-triage
OS: Other → All
Summary: [Compat Data][Importer] Should accept kuma macros in comments or links → Should accept kuma macros in comments or links
Whiteboard: [specification][type:bug] → [bc:infra]
Reporter | ||
Updated•8 years ago
|
Status: NEW → RESOLVED
Closed: 8 years ago
Flags: needinfo?(jypenator)
Resolution: --- → FIXED
Updated•4 years ago
|
Product: developer.mozilla.org → developer.mozilla.org Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•