Page MenuHomePhabricator

Allow page previews to display in wiktionary
Open, MediumPublic

Description

Background

Currently page previews are not available in wiktionary. We would like to account for page previews within wiktionary by providing the primary definition from the wiktionary entry.

Acceptance Criteria

Previews on wiktionary must contain the following:

  • wiktionary definition (if available)
    • for pages that do not contain a definition, the generic card must not display
    • Image (if available) - we can still have the default to "any" image
    • If a page has no description and no image, the generic card will display
  • Descriptions will be on by default for all logged-in and logged-out users
  • Logged-in users may turn off descriptions within their user preferences

Event Timeline

Jdlrobson moved this task from Incoming to Epics/Goals on the Readers-Web-Backlog board.

Adding the epic tag as "wiktionary definition (if available)" is going to be a little complicated and this is more than one card.

Qse24h closed this task as a duplicate of T164723: New git repository: <repo name>.
Qse24h closed this task as a duplicate of T164723: New git repository: <repo name>.
Qse24h closed this task as a duplicate of T164723: New git repository: <repo name>.
Qse24h closed this task as a duplicate of T164723: New git repository: <repo name>.
Qse24h closed this task as a duplicate of T164723: New git repository: <repo name>.
Qse24h closed this task as a duplicate of T164723: New git repository: <repo name>.
Qse24h closed this task as a duplicate of T164723: New git repository: <repo name>.
Qse24h closed this task as a duplicate of T164723: New git repository: <repo name>.
Qse24h closed this task as a duplicate of T164723: New git repository: <repo name>.

Is there any chance that page preview be available for the Wiktionary projects?

No plans that I'm aware of yet but the first thing to do to get towards that would be making the summary endpoint in rest work with wiktionary content in Mobile-Content-Service

We have a Wiktionary definitions endpoint, but that works only for English Wiktionary (examples bar, and). Other language Wiktionaries may use different page structures, which makes them more difficult to parse.

If we really want the summary endpoint for wiktionary to include the parsed definitions then we would have to implement a lot of different parsers or come up with a way to simplify this.

I wouldn't hold the existing Wiktionary definition endpoint up as an example to emulate. IMO the only sane way of moving forward on Wiktionary integration, given the lack of consistency in page structure or content, is to come up with a set of markup reflecting elements we're interested in (definitions, examples, etc.), and then work with Wiktionary communities to incorporate that markup into pages so that clients can reliably query for what they're interested in. There's a task for this: T138709

The main blocker here, I think, is someone deciding that Wiktionary integration is enough of a priority to justify spending the time to lay this groundwork.

Also, there's no concept of a primary definition in any Wiktionary as far as I'm aware, so that would have to be defined in a product spec.

@Mholloway an approximation for the primary definition could be the first gloss/sense of an entry, skipping all obsolete/archaic senses which are sometimes listed first (presumably to illustrate the semantic development). in case of several part of speech headers this is trickier, since there's often no clear ordering

This task has been assigned to the same task owner for more than two years. Resetting task assignee due to inactivity, to decrease task cookie-licking and to get a slightly more realistic overview of plans. Please feel free to assign this task to yourself again if you still realistically work or plan to work on this task - it would be welcome!

For tips how to manage individual work in Phabricator (noisy notifications, lists of task, etc.), see https://phabricator.wikimedia.org/T228575#6237124 for available options.
(For the records, two emails were sent to assignee addresses before resetting assignees. See T228575 for more info and for potential feedback. Thanks!)