Wikipedia talk:Manual of Style/Disambiguation pages/Archive 26

message: :The following 8-point single-sig edit has been refactored into individual signed items, to facilitate point-by-point discussion.--Jerzy•t 09:04, 30 August 2006 (UTC)
replies: text: I support proposals 1,2,3 and 5.  My interest is in the disambiguation of place names.  Many of these words are also surnames, and some of these pages have recently had lots of people added and have become uncomfortably large.  I support creating separate "Title (surname)" pages, (although LoPbN would still be my long-term preferred solution). CarolGray 10:54, 29 August 2006 (UTC)
thread_title: Next steps

message: (Section temporarily residing on Wikipedia talk:Manual of Style; when discussion there subsides, Jerzy•t will label that copy "closed" and request that any further discussion ensue on a copy to reside on Talk:List of people by name or its subpages.) 
_ _ Making a user rely on LoPbN, to the exclusion of a page where lks to bios on people bearing the surname, is bad for several reasons. 
: (These are beyond the fact that, despite 
:* the additions of all the names on each of many topical lists of people, 
:* the first additions of alphabetic stretches from :Category:Living people, 
:* (i think) additions of combined alphabetic stretches from many Cats for deaths in given periods of time, and
:* daily random or small additions, 
:the number of bios still appears to be at least 5 and maybe 10 times the number of entries.  Which is to say that there's a decent chance a given bio is not lk'd from LoPbN -- and this is true even if the name is not obscure. The following further reasons will apply even if and when the list lags the bios by less than other name-related resources do.)
# For users with slow connections, loading the whole of the needed LoPbN page, instead of a page with just the names in question, may be burdensome.
# For surnames with too few notables to fill a screen, those entries may share a section with multiple other surnames. (At present, a prototype scheme for subdividing sections with multi-level bullet headings could arguably ameliorate the burden that results, but it is implemented only on a couple of dozen pages, and it must be redone virtually from scratch on pages  that expand rapidly.) For such a group of names, simply reading them once  as a list requires either scanning through all the names preceding them in the section (up to about 20 in number), or finding the beginning and end of the group by two binary searches, probably keeping track of each narrowing binary-search range's beginning and end with a finger or a post-it on the monitor (if not on the screen itself).  Weighing several names within the group against each other probably requires further use of such place markers, at least at the start and end of the group.
# As LoPbN's stock of names expands, there is hard-to-catch disruption of maximally precise lks into LoPbN, as entries relocate onto newly created or renamed pages and into newly created or renamed sections:
#* A page-and-section lk of the form LoPbN:Xy#Xyz may no longer lead to a screen where the name entries desired are visible, they being instead in a subordinate section that is "off the bottom" of the screen, so reaching them requires either scrolling or going to top-of-page and lk'g via the page ToC.
#* A page-and-section lk of the form LoPbN:Xy#Xya - Xym may turn into effectively a lk to the top of the desired page.
#* A lk to a page (whether a page or page-and-section lk) may turn into a lk to (the top of) a page that is the parent (or a more remote descendant) of the page containing the entries being sought.
#* A lk to a page whose title is of the form LoPbN:Xyp-Xyz will usually become redirected to the largest page that was produced when the former page was subdivided, which for up to half of such lks will be neither the desired page nor an ancestor of it. (When such subdivided pages have been further subdivided, such misdirections can be to "cousins" of various orders and "removed" by various numbers of "generations".)
_ _ Some lks from Dabs into LoPbN do exist; one from Stein to List of people by name: St#People named Stein may the first i became aware of. It  was created in October 2003, and i corrected it following the entries' relocation from St to Ste, as i have on occasion done in those three years for some other LoPbN page that got subdivided. No correction has been made, however, for the relocation to the entries' current page, Stea-Steo. (I haven't, IMO shouldn't, and won't make doing such changes an ongoing priority.)
_ _ It is currently dauntingly labor intensive  for an interested editor to detect which pages, among a group of surname-focused pages they are interested in, come to need such a change. 
* As to breaking lks' page parts, however, it may be feasible for me to modify one set of 17 templates so i can easily maintain a list of templates such that at one of them changes whenever a page is created (the events which account for the overwhelming proportion of such lk-breaks), and virtually never change otherwise.  Any interested editor could extract from it the titles of templates sensitive to the division of LoPbN pages lk'd by (surname-focused or other) pages of interest to them, enter them on a user sub-page, and (at least every 30 days) check Related changes of that sub-page; some of these would damage lks only to siblings of targets of their lks of interest, so some false alarms would have to be ignored. It is probably also practical for me (who carries out virtually all LoPbN page divisions) to state the precise pages affected in the summaries, which will appear on the Related changes screens and ease the winnowing out of false alarms.
* As to breaking the section parts of lks (which is much more frequent), some bot-driver might be willing to traverse the LoPbN tree periodically, extracting for each page only its heading markup and copying this as the new content of a corresponding "skeleton page", say Talk:List of people by name: Stea-Steo/Heading skeleton for the example already discussed. Periodic rewrites identical to their predecessors would not show up on histories (apparently being treated like unsaved edits), so only changes in the depth or title of at least one section would appear on the Related changes of a list of skeleton pages of interest to that list's creator; viewing the differences in such edits would disclose whether a heading used in a link of interest was among the changed headings.
_ _ These objections are irrelevant, however, to markup-sharing schemes that become feasible if one (or better yet two) fairly confined server extensions should become available. (Likewise in the case of more complicated facilities, such as Wiki-style data-bases, that i won't presume to describe.) I call these two extensions as "transextraction" and "symbol setting" (without any claim that these terms are good ones); i describe their application to this problem in the second following subsection at this level, Transextraction & LoPbN.
Proposals for writing information in one place and having multiple pages share this information, each in a context appropriate to the context of a page better suited than to the one page's purpose than to anothers could in theory be more efficient of editor's time and be more consistent. As i believe i demonstrate in the next section at this level, "Transclusion into LoPbN?", our present transclusion facility is inadequate to the task, but one (or better yet two) fairly confined server extensions should make it feasible to meet those goals; i describe them their application to this problem in the second following subsection at this level, Trans-extraction & LoPbN.--Jerzy•t 05:44, 30 August 2006 (UTC)
thread_title:  Lk from Dabs into LoPbN? 

message: (Section temporarily residing on Wikipedia talk:Manual of Style; when discussion there subsides, Jerzy•t will label that copy "closed" and request that any further discussion ensue on a copy to reside on Talk:List of people by name or its subpages.) 
There are two current major barriers to using transclusion to avoid duplication of labor in creating groups of name entries for LoPbN and Dabs.
# They don't use the same format for their entries:
#:_ _ Dab entries are and should remain unpiped, while LoPbN ones must be piped for these reasons:
#:# with most modern Western names, for the sake of putting the surname (and primary sort key) first, 
#:# to avoid distraction by any dab'n sfx, and 
#:# to provide multiple list entries on LoPbN according to any of their nicknames and compelling misspellings that are formated (in the Dab) with the lk at the end of the entry.
#:_ _ Descriptions following their lks on Dabs may be omitted where the dab'n sfx obviates them, or differ from the LoPbN ones, bcz the visible Dab'g sfx in the Dab lk makes part or all of the description redundant.
#:_ _ Removing the moderately popular "is a" at the head of descriptions in Dab name entries would be necessary first, but for the sake of consistency that must be extended to the non-name entries, consuming more time.
#:_ _ It is probably desirable that each entry on LoPbN continue to include both
#:* nationality and 
#:* the "low-resolution terminology" cause-of-notability description 
#:that the preponderence have, so that the consistent style discourages, in the entries frequently contributed by brand new editors, the tendency to include information of no navigational value; on the other hand, Dab entries are more likely to be contributed by better oriented editors, and the different style that WP:MOSDAB implies is preferable:
#:* including (of course) distinguishing info that a typical LoPbN entry would not, and 
#:* omitting nat'ty and/or cause of notability when identical for all the bio subjects who share identical names.
# The multi-entry blocks of entries that cover the same surname or the same surname/given-name combo on a Dab and on LoPbN should often not include entries for exactly the same people. The probably primary case reflects the order on LoPbN being strict alphabetical order (at least for people not well known by a non-surname), while on Dabs at least the first few should reflect prominence (and arguably the rest should be ordered by date of death rather than alphabetically, or grouped by area of endeavor). If alpha order is used, these differences are not fatal to the concept of defining templates that contain multiple entries, but that approach sacrifices some otherwise expected efficiencies: new entries suitable for a Dab but not for LoPbN would often require subdividing an existing template into two templates, so the unshared entry can be placed between the two templates on the list that includes it.
These objections would apply much less, however, if one (or better yet two) fairly confined server extensions should become available. (Likewise in the case of more complicated facilities, such as Wiki-style data-bases, that i won't presume to describe.) I call these two extensions as "transextraction" and "symbol setting" (without any claim that these terms are good ones); i describe their application to this problem in the next subsection at this level, Trans-extraction & LoPbN.--Jerzy•t 05:44, 30 August 2006 (UTC)
thread_title:  Transclusion into LoPbN? 

message: (Section temporarily residing on Wikipedia talk:Manual of Style; when discussion there subsides, Jerzy•t will label that copy "closed" and request that any further discussion ensue on a copy to reside on Talk:List of people by name or its subpages.) 
_ _ CM's comment (my response to which includes a lk to this subsection) is, IIRC, the third time i have heard a proposal for transclusion into LoPbN of stretches of Dab-style name entries (presumably from a handful to hundreds in length); i recall discussing or demonstrating some kind of awkward alternative to the unworkable obvious template approach (to little or no response and effect). This mention of the general concept is the first i've seen since the introduction of the  syntax. That tag, IMO, points the way to doing, in effect, what those proposing transclusion of entries onto LoPbN hope for, with the help of at least one fairly limited server feature (but preferably also one further feature, which is at least as limited).
_ _ This subsection is limited to a technical description of the two features and their application to this problem. For insight into the goals (implicit in the transclusion proposals) that require going beyond current features, see the preceding subsections "Lk from Dabs into LoPbN?" and "Transclusion into LoPbN?".
_ _ The feature i am calling "transextraction" (for lack of a better naming idea) is fairly well specified by one pertinent example.  One possible syntactic expression of the idea is 
:  
and the current contents of Ferdinand Magellan's Persondata tag would give that invocation the same effect as 
:  
For the sake of demonstration,  could contain (instead of its real content) something along the lines of
:  ( --  ) was a  from . He died at .
The effect is that of looking up the values assigned in the  tag within that bio, and using them as the parameters of . (The parameters anticipated by the current  could not actually support templates capable of building entries that meet our standards for these lists; doing that would require either inventing another tag, say , or adding parameters to the existing one, or restructuring the existing one by breaking up into smaller "chunks" some parameters (which function as "fields" bcz of its data-base role) that it currently has.)
_ _ ( exposed the implicit potential in MediaWiki for one small but fundamental DBMS feature, the creation of tuples; the Persondata tag has the intention of being used as part of the interface for non-MediaWiki DBMSs to extract data from those tuples in bios, if by no other means, by reading the markup in the corresponding pages. (MediaWiki relies on a data-base component that stores and retrieves the current and former versions of pages, and the info seen on page-history pages and Logs; the Persondata-based mini-database, like virtually everything else on WP, depends on it, but should not be confused with it.)  Implementing such "transextraction" as i propose here would amount to complementing that with another small but crucial DBMS feature, one for extraction of data from those tuples for reformating via the template system. One argument against permanent provision of "transextraction", and perhaps against using it even temporarily, would be that it is a limited and ad hoc feature that should properly be provided as part of a broader DBMS capability. I am not arguing on either side of those questions, if only bcz i consider this description to be worthwhile whether as 
* a proposal to implement transextraction in essentially this form (for the long or short term), 
* a means of stating one example of why MediaWiki editors should have DBMS tools as well as the template ones they have already gotten, or
* a misguided idea that is concrete enough to be a target for those intent on showing that giving DBMS tools to editors is not a good direction for MediaWiki enhancement.)
_ _ A second feature, perhaps easier to provide than transextraction, would multiply the effectiveness of transextraction in making editing effort that uses it more efficient. I call it (again for lack of a better name) "symbol setting". It would enable editors to create symbols functioning like the existing  and  ones, without any effect outside the respective pages they are created on (other than through their effect on how those pages are rendered, transcluded, substituted, or transextracted elsewhere). The symbol setting probably should take two forms, perhaps 
: __SET VAR SYM=xxx__
and
: __SET CONST SYM=yyy__
The Const version might have to appear before any text, and would set the meaning of a symbol (SYM in these examples) and render ineffective any Var settings, on the same page, of the same symbol. VAR settings, on the other hand could be repeatedly changed, staying effective until the next one that sets the same symbol, or the end of the page. In the LoPbN/transextraction context, the use i contemplate is making the same template render differently depending on LoPbN pages setting the same symbol differently from the way Dab pages would do. The templates in question would each contain a series of transclusions utilizing  tags of bios. When preceded by 
: __SET CONST Pgtype=L__
(on an LoPbN page), the transclusion 
:  
would be equivalent to  
:  
while preceding it by
: __SET CONST Pgtype=D__
(on a Dab) would make it equivalent to  
: 
This would accomplish nothing that could not be achieved by copying a symbol-less stretch of "transextractionized" Dab or LoPbN markup, doing a global change on the multiple copies of the template name, and pasting it into a page of the other kind -- except saving that editor effort, and probably reducing occasional clerical errors.--Jerzy•t 05:44, 30 August 2006 (UTC)
replies: text: I've responded over there CarolGray 20:21, 11 September 2006 (UTC)
thread_title:  Trans-extraction & LoPbN