Page MenuHomePhabricator

For implementations and testers show the associated function in Recent Changes (etc)
Open, LowPublicFeature

Description

Feature summary (what you would like to be able to do and where):
See a link to the associated function when there is a link to an implementation or a test, especially in Recent Changes and Special:ListObjectsByType)

Use case(s) (list the steps that you performed to discover that problem, and describe the actual underlying problem which you want to solve. Do not describe only a solution):
When reviewing Recent Changes (New Pages, etc) it is not apparent which function is affected by a new or changed implementation or test. This means it is necessary to navigate to the object and then to the function. The same applies to List objects by type.

Benefits (why should this be implemented?):

  • The function label provides essential context for an implementation, so it is routinely included in an implementation label. This (partial) duplication could be eliminated, along with the translation overhead.
  • Labels for tests tend to be shorter and rather more cryptic. The function’s label generally provides sufficient context to make sense of the test’s label (because it is provided in a context where the function is obvious to the contributor).
  • Implementations and tests will often not have a label in many languages, especially when new. If the associated function is referenced with a link, contributors are more likely to see the function name in their own language.
  • Arguably, contributors are also more likely to provide function labels in their own language, particularly when a function has a larger number of implementations and tests.
  • Contributors sometimes provide function links in edit summaries. This practice is prone to error (not least because there is no preview) and errors cannot be corrected.

Although an automated edit summary is one solution, we should consider whether a link to an implementation or test should routinely include a link to its function (except in the context of that function, and only once in the context of an implementation or test, such as View history).

It would also be useful to see what Type of object is referenced in these contexts. For example, Z10004 could be described with reference to [[Z610]] and [[Z10000]] (with [[Z14]] being implied by [[Z610]]). One advantage of avoiding an edit summary approach is that new WikiLambda messages can (presumably) be more easily configured to the requirements of different languages. (For example, in this context, Z10000.Z14.Z610 might be rendered into English as “Python implementation of the function Join two strings”.) Also, an edit summary approach does not work in Special:ListObjectsByType and would provide duplicated information in View history.

Event Timeline

To clarify, you'd want an entry on https://wikifunctions.org/wiki/Special:RecentChanges to go from:

N 14:32 <a>Type of −42 is Integer (Z19002)‎</a> (<a>diff</a> | <a>hist</a>) +1,107‎ .. <a>‎GrounderUK</a> (<a>talk</a> | <a>contribs‎</a>) (type of object (Z16829)➕Test case (Z20): Integer (Z16683) ↤ –42) (<a>thank</a>)

… to:

N 14:32 <a>Type of −42 is Integer (Z19002)‎</a>, a <a>Test</a> of <a>type of object (Z16829)</a> (<a>diff</a> | <a>hist</a>) +1,107‎ .. <a>‎GrounderUK</a> (<a>talk</a> | <a>contribs‎</a>) (type of object (Z16829)➕Test case (Z20): Integer (Z16683) ↤ –42) (<a>thank</a>)

(My changes in bold.)

Would this just be on RC/Watchlists? We have to re-do the link replacement system anyway, sadly, as it's not Parsoid-compatible, and the user language caching bug is problematic.

Yes, that sort of thing. My own priorities are Recent Changes and Special:ListObjectsbyType, but I don’t see why the same approach should not be followed elsewhere, depending on the effort required. Note that I would not be adding the links to Z16829 and Z20 in the edit summary if this change were in effect, so that would just be “[[Z16683]] ↤ –42”.

The principal exception would be View history, where repeating the same additional information for every revision is unhelpful. But even here, I would rather see the information repeated than have it missing entirely.

I’m not sure what the scope of “the link replacement system” would be but, in general, it should ideally be possible to choose the level of expansion according to the context. For example, a list of implementations on a function page might just specify whether the implementation is a composition or, if not, its programming language. (Or we could group implementations by programming language, which would be a usability enhancement with just our current three options and increasingly useful with each additional language.)

I hope that answers your questions, but please feel free to dig more deeply!