Template:PersonCall: Difference between revisions
From Bodhicitta
(VSCode edit) |
(VSCode edit) |
||
| (One intermediate revision by the same user not shown) | |||
| Line 23: | Line 23: | ||
<!-- | <!-- | ||
Full width, no sidebar. | Full width, no sidebar. | ||
NOTE — avoid colons inside these comment blocks. SMW's RemoteRequest.php | |||
runs a colon-split over every HTML comment it finds in a remote query | |||
response, so a colon here produces PHP warnings during rebuildData runs. | |||
The page used to run a 3/9 split with relations and categories in a sticky | The page used to run a 3/9 split with relations and categories in a sticky | ||
rail. Measured across all 1,695 person pages, that rail held a median of TWO | rail. Measured across all 1,695 person pages, that rail held a median of TWO | ||
items | items. 82% of pages carried 1-3, and only 1.2% carried 15 or more. Four out | ||
five pages were paying for a sticky-sidebar instance, a mobile drawer, and | of five pages were paying for a sticky-sidebar instance, a mobile drawer, and | ||
narrowed article column in order to show about two links. | a narrowed article column in order to show about two links. | ||
A sidebar also earns its keep elsewhere on this wiki by holding things a | A sidebar also earns its keep elsewhere on this wiki by holding things a | ||
reader returns to while moving through long content | reader returns to while moving through long content, such as a TOC or chapter | ||
navigation. Person pages have no such content | navigation. Person pages have no such content, only a short biography and | ||
then tiles. Names and relationships are attributes OF the subject, so they | |||
now read in sequence with it rather than in a parallel column. | |||
Reading order is deliberate | Reading order is deliberate. Who they are, what they looked like and their | ||
life, who they were connected to, then what they made. The works queries come | life, who they were connected to, then what they made. The works queries come | ||
last because they run deep on well-covered figures | last because they run deep on well-covered figures, and they are the point of | ||
the page. | the page. | ||
-->{{#ask:[[{{SUBPAGENAME}}]] | -->{{#ask:[[{{SUBPAGENAME}}]] | ||
|?BdrcLink |?Bio |?BiographicalInfo |?BioTib |?BnwShortPersonBio |?FirstImage |?HarLinkRaw |?HasDnzPage |?HasRtzPage |?ImagesRaw |?MainNameChi |?MainNameDev |?MainNameJap |?MainNameKor |?MainNamePhon |?MainNameTib |?TolExcerpt |?TolLinkRaw |?Yearbirth |?Yeardeath |?Subclass |?GyatsaBioTib |?AltNamesTib |?AltNamesWylie |?AltNamesOther |?PersonType |?Languagetranslation |?EmanationOf |?Studentof |?Teacherof | |||
|named args=true | |named args=true | ||
|link=none | |link=none | ||
| Line 56: | Line 52: | ||
|template=PersonRemote | |template=PersonRemote | ||
}}<!-- | }}<!-- | ||
The Names and Connections band is rendered by the PersonRemote template on | |||
Commons, from the printouts requested above. It used to be six local ask | |||
queries here, which both duplicated data that arrives in the remote fetch | |||
anyway and depended on SetRemoteValues having imported it. | |||
--> | |||
<div class="my-4"><!-- | <div class="my-4"><!-- | ||
One filter box for the whole page, sitting above every section. | One filter box for the whole page, sitting above every section. | ||
It is deliberately NOT per-section | It is deliberately NOT per-section, because the handler in tws.js binds to every | ||
.filter-input on the page, and an input with no contentId targets | .filter-input on the page, and an input with no contentId targets | ||
.filterableContent globally — so one box per section would have each box | .filterableContent globally — so one box per section would have each box | ||
| Line 137: | Line 88: | ||
The buckets have to be mutually exclusive, because the underlying data | The buckets have to be mutually exclusive, because the underlying data | ||
overlaps | overlaps, because an item with |Performer= is ALSO auto-categorised under the | ||
performer's name. Splitting naively double-renders those tiles — measured on | performer's name. Splitting naively double-renders those tiles — measured on | ||
People/Ringu Tulku, 303 "authored" + 294 "performer" for a true union of 303. | People/Ringu Tulku, 303 "authored" + 294 "performer" for a true union of 303. | ||
They are separated on |Class= rather than by negating |Performer=, for two | They are separated on |Class= rather than by negating |Performer=, for two | ||
reasons. First, SMW's negation operators do not do set subtraction here | reasons. First, SMW's negation operators do not do set subtraction here. | ||
A negated Performer condition excludes pages that LACK the property entirely, which | |||
silently drops every text work (it zeroed out Śāntideva's 181 works in | silently drops every text work (it zeroed out Śāntideva's 181 works in | ||
testing), and | testing), and a negated Category condition was ignored outright. Second, Class is a | ||
reliable positive discriminator — every one of the 1,732 library items | reliable positive discriminator — every one of the 1,732 library items | ||
carrying a Performer value is Class=Multimedia, with no exceptions. | carrying a Performer value is Class=Multimedia, with no exceptions. | ||
So | So Multimedia is the performance bucket, and everything else is authorship. | ||
Positive conditions only, no negation. | Positive conditions only, no negation. | ||
| Line 172: | Line 123: | ||
}} | }} | ||
<!-- | <!-- | ||
Fallback | Fallback for when nothing matched any bucket. Preserves the original empty state. | ||
--> {{#ifexpr:{{#ask:[[Category:Library Items||Editorial Content]][[Category:{{#titleparts:{{SUBPAGENAME}}}}]] | --> {{#ifexpr:{{#ask:[[Category:Library Items||Editorial Content]][[Category:{{#titleparts:{{SUBPAGENAME}}}}]] | ||
OR[[Category:Library Items||Editorial Content]][[PeopleTopics::{{#titleparts:{{SUBPAGENAME}}}}]] | OR[[Category:Library Items||Editorial Content]][[PeopleTopics::{{#titleparts:{{SUBPAGENAME}}}}]] | ||
| Line 200: | Line 151: | ||
separated from single-valued ones. | separated from single-valued ones. | ||
The GetData module now takes |multi=, an allowlist of the properties that should | |||
receive SMW's '+sep=' directive. Everything else in |props= is stored as a | receive SMW's '+sep=' directive. Everything else in |props= is stored as a | ||
single value, so both groups can travel in one query. | single value, so both groups can travel in one query. | ||
