Closed
Bug 1240774
Opened 8 years ago
Closed 5 years ago
Generate and expose a UUID identifying MDN pages
Categories
(developer.mozilla.org Graveyard :: API, enhancement)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: jwhitlock, Unassigned)
Details
(Keywords: in-triage, Whiteboard: [specification][type:feature])
What problem would this feature solve? ====================================== MDN requires a way to associate a page with a BrowserCompat (BC) feature, so that the specification and compatibility data can be injected into the page at render and display time. The design used a slug, that was not expected to change, as the identifier. However, there was no agreement on the format of these slugs [1], so new ideas were explored. Instead, a UUID will be used to identify BC resources, including features [2]. If the UUID is generated on the MDN side, and uniquely identifies an MDN page and its localizations, then this can be used as the BC Feature UUID as well. To reuse the UUID, it needs to be available in the Kuma page API [3] during the import process. If the UUID is available in the API, the KumaScript can be used with no parameters for the default case of a feature reference page, and with a UUID or alias parameter when embedding compatibility information on tutorial or other pages. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1078699#c2 [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1230306 [3] https://developer.mozilla.org/en-US/docs/Web/CSS/background$json Who has this problem? ===================== Staff contributors to MDN How do you know that the users identified above have this problem? ================================================================== The initial conversion of MDN pages used slugs as the identifiers, and staff had difficulty using these for Javascript reference pages, because the auto-generated slugs were unintuitive for the long JS URLs. How are the users identified above solving this problem now? ============================================================ The importer was updated to show the conversion KumaScript, so that manual conversion was a copy-and-paste operation. However, manual conversion of pages has halted until UUIDs are available. Do you have any suggestions for solving the problem? Please explain in detail. ============================================================================== Add a UUID column to wiki Document model [4], and populate it in a data migration. Add this UUID to to the JSON data returned by the API. [4] https://github.com/mozilla/kuma/blob/b96ff3b53a60d0b5a0b6d26aa4d63f5cc1653e3e/kuma/wiki/models.py#L174 [5] https://github.com/mozilla/kuma/blob/b96ff3b53a60d0b5a0b6d26aa4d63f5cc1653e3e/kuma/wiki/models.py#L638 Is there anything else we should know? ====================================== This should be done before the BC API uses UUIDs as primary keys, so that the BC importer can import the UUIDs, rather than requiring a data entry job to go from BC data to Kuma data.
Reporter | ||
Comment 1•5 years ago
|
||
The UUID was added in https://github.com/mozilla/kuma/pull/3795, as part of bug 1246967.
Status: NEW → RESOLVED
Closed: 5 years ago
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
•