1219927 - [Compat] Create macros to import "alternate_name" correctly

Status: RESOLVED WONTFIX

(Developer Documentation Graveyard :: Macros/Templates, defect, P5)

Description

[Florian Scholz (Open Web Docs)]

:: Developer Documentation Request

      Request Type: New Documentation
     Gecko Version: unspecified
 Technical Contact: 

:: Details

This page, for example, has a footnote which is actually a "alternate_name" information and not just a footnote:
https://developer.mozilla.org/en-US/docs/Web/API/RTCIdentityEvent

In the browsercompat API, this gets parsed like this ("note" is populated and "alternate_name"/"alternate_mandatory" is not):

{
  "id": "__basic support-67",
  "support": "yes",
  "prefix": null,
  "prefix_mandatory": false,
  "alternate_name": null,
  "alternate_mandatory": false,
  "requires_config": null,
  "default_config": null,
  "protected": false,
  "note": {
    "en": "Gecko implements this interface under the following name: <code>RTCPeerConnectionIdentityEvent.</code>"
   },
   "links": {
     "version": "67",
     "feature": "_basic support"
  }
}

To change this, we need to:

1) Create macros like CompatAlternateName with two parameters "name" and "mandatory". The output can be like ("This feature is (also) implemented under the following name: <code>RTCPeerConnectionIdentityEvent</code>.").

2) Replace text in footnotes on the pages with this new macro.

3) Tell the browsercompat devs about it, so that we can start implementing the correct parsing for this data.

Comment 1

[Jean-Yves Perrier [:teoli]]

John, Jeremie: is the creation of {{CompatAlternateName}} still the right way to solve this problem?

Comment 2

[John Whitlock [:jwhitlock]]

It's the developers' strong preference that a CompatAlternateName macro is developed and used on some pages. This doesn't have to be used on every page with alternate feature names, but at a minimum on one with a required and one with a non-required alternate name. This would allow testing the full loop (scrape from MDN, import into the API, display on MDN, and edit in the C&M interface).

The alternate solution is to import as a note, and later, when the C&M interface is available, to manually change it to the alternate name fields.  The code to display the alternate name data will have to be implemented with no data backing it up, which means that any bugs will also have to wait to be discovered and fixed later. And, it is possible the manually entered data will be lost on re-scrape from MDN.

Comment 3

[Jeremie Patonnier :Jeremie]

(In reply to John Whitlock [:jwhitlock] from comment #2)
> The alternate solution is to import as a note, and later, when the C&M
> interface is available, to manually change it to the alternate name fields. 
> The code to display the alternate name data will have to be implemented with
> no data backing it up, which means that any bugs will also have to wait to
> be discovered and fixed later. And, it is possible the manually entered data
> will be lost on re-scrape from MDN.

Mmmh, that's a lot of uncertainty that I wish to avoid, if the writing team is okay with creating those macro and updating the content, that's sounds like a good idea. The big question here is the cost in development needed to support those macro vs the time to create update and maintain such macro in MDN content.

John, do you have a rough idea of how many time (hours, days, weeks?) it will required to implement the parsing and data management of such new macro? At some point between Scooter and Motorbike we will work on making the importer more reliable, but figuring how many time it will required will help us making such decision.

Comment 4

[John Whitlock [:jwhitlock]]

It's a 1-2 hour code change to update the importer.

Comment 5

[Jeremie Patonnier :Jeremie]

Ok, so let's go with creating such macro :)

Comment 6

[John Whitlock [:jwhitlock]]

The BrowserCompat project is canceled.  See https://github.com/mdn/browsercompat for current effort. Bulk status change includes the random word TEMPOTHRONE.