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

This is an archive of past discussions on Wikipedia:Manual of Style. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Archive 20

←

Archive 24

→

The discussion "Hndis needs its own Manual" continues from Archive 25.

<< go to Archive 25

Hndis needs its own Manual

Latest comment: 17 years ago37 comments4 people in discussion

continued from Archive 25

"WP as a reference is used by people searching by surname only" -- is it? This is the part I have the most surprise over, but no doubt that's because of the way I expect to use it. I have also recently changed Johnson to indicate that it was listing people with the last name of Johnson, not people who are known as Johnson, since it included Whoopi Goldberg; should the surnames stick to the "most notable" people of that surname (and/or people who might be cited in some paper as "F. Lastname"), and point to LOPBN for exhaustive listing then?
-- JHunterJ 15:35, 27 August 2006 (UTC)

_ _(after edit conflict) OK, this is something to work with. I still believe, the immediate solution is to modify the MOSDAB. The only other "exceptional" dab page is for ship index pages, where the instructions are part of a separate project. If there were a project that wanted to define and maintain human name index pages, then that would be another route to consider.

_ _ I think the problematic instructions are the following, under the section Examples of individual entries that should not be created: Box reformatted by Jerzy•t 23:13, 27 August 2006 (UTC), to clarify its relation to rest of page.

:On a page called Title, generally do not create an entry for:

Title County
Title City
Title Hospital
Title University

These may require their own disambiguation pages. For example, "Jefferson County" should list the counties in all the states, but the "Jefferson" disambiguation page ideally would not. A reader looking for Jefferson County would be expected to type both words and hit the Go button, not just type "Jefferson". However, if you find that another editor has felt the need to create such entries, please do not remove them.

You may want to create entries on the same page for:

TITLE and Title
Title town and Title township

An example is "Willow Valley", which lists a town of that name as well as "Willow Valley Township" in another state.

"Title Island", "Title River" or "River Title" may be worth listing in cases where the "Island"/"River" part is often omitted, so "Catalina" might include "Santa Catalina Island".

In most cases, do not list names of which Title is a part, unless the persons are very frequently referred to simply by their first or last name (e.g. Galileo, Shakespeare).

_ _ Quite apart from the human names issue, I find the first portion of this to be problematic, and generally disregarded. (At least I disregard it when editing dab pages and many otherwise good quality dab pages likewise appear to disregard these specific proscriptions.) I'm not so sure about Title Hospital, but it is quite common to list county, city and universities that share the a name on the dab page -- all of them may be referred to by the short name in various contexts and are something I would expect to see on a dab page.

_ _ The last sentence appears to be principal cause of the problem for human name disambiguation. I propose that we modify that sentence to read something like:

In the case of human names, the disambiguation page should include links to articles about persons whose surname (family name) is Title. If there are a large number of names, they can be placed on a separate page titled: Title (surname). In the case of given names, the disambiguation page should generally only include links to articles about persons who might likely be referenced by their given name alone. For example, Elizabeth II of the United Kingdom would be listed on Elizabeth. Monarchs and persons from antiquity and medieval periods are often known primarily by their given name. See the section People, for details on human names.

_ _ As for the first section, that also needs a substantial rewrite, IMO, but that is beside the point here. The issue of disambiguating based on given names (e.g., Clint) is a somewhat separate and more difficult issue. As an example of one problem, there are Benjamin and Benjamin (disambiguation) and Bartholomew and Bartholomew (disambiguation), all of which are in Category:Given names, although only the latter of the two pairs are disambiguation pages, although there is some name disambiguation on the articles with the simple titles. Then as a different approach, William is the disambiguation page, while William (name) is an encyclopedic article about the name. Then there is Dirk (disambiguation), which is categorized as a Given name, although it the name is only one small aspect of that disambiguation page.

_ _ Hmm, the more that I look into these, I'm starting to think that perhaps it might be a good idea to have some guidance about hwo to name these sorts of pages and what sorts of things to include in them. Although I do think the main MOSDAB page should be updated as well to clarify that lists of surnames (and in at least some cases, lists of given names) are not prohibited.
-- older ≠ wiser 16:14, 27 August 2006 (UTC)

Next steps

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).

Steps I'd like to take:

Edit the WP:MOSDAB#Examples of individual entries that should not be created and replace "In most cases, do not list names of which Title is a part, unless the persons are very frequently referred to simply by their first or last name (e.g. Galileo, Shakespeare)." with "For places or names of which Title is a part, list them in a "See also" section unless the subject is very frequently referred to simply by the single name (e.g. Galileo, Shakespeare, New York)." or similar, so that other editors don't fall into the same usage vs. specification conflict. -- JHunterJ 21:51, 28 August 2006 (UTC)
Done. —Preceding unsigned comment added by JHunterJ (talk • contribs) 21:10, 29 August 2006

For clarity of history: The former text
In most cases, do not list names of which Title is a part, unless the persons are very frequently referred to simply by their first or last name (e.g. Galileo, Shakespeare)

was proposed to become
For places or names of which Title is a part, list them in a "See also" section unless the subject is very frequently referred to simply by the single name (e.g. Galileo, Shakespeare, New York).

--Jerzy•t 09:04, 30 August 2006 (UTC)

How about
(e.g. Galileo, Shakespeare, New York (and New York))

for the sake of avoiding doubt abt 2 points: this is not abt the short name being the title, nor (i think) abt one topic being the only one the short name frequently refers to.
--Jerzy•t 09:04, 30 August 2006 (UTC)

Looks fine, perhaps even with a note that eliminates the potential doubts explicitly. -- JHunterJ 11:37, 30 August 2006 (UTC)
If the Title is already a disambiguation page, move the list of people to a "Title (surname)" page, so on Patton, for example, George S. Patton (often referred to as just "Patton") and the places and things would remain on the base page along with a Patton (surname) link, which would list people with the last name who aren't commonly known by just it.
-- JHunterJ 21:51, 28 August 2006 (UTC)
_ _ The principle current problem of Patton (Let's ignore here the clear non-conformities of many entries....) is its failure to use a "See also" section where point 1's wise change calls for it. George S should indeed get the first entry, but in the lead section rather than under "People". The "People" (non-section) heading belongs under the "See also" (section) heading (and i doubt there should be any section hdg except the "See also").

_ _ (IMO, it would be good chg to permit two entries for the same article, at least one above and one below "See also", so users seeking G.S but mistakenly jumping directly to "People" under "See also" can lk to his bio w/o going back and looking at the top. But that is a side issue.)
_ _ Separate pages IMO are reasonable only for the Dabs where
1. both the "true Dab" and surname portions are so large that they should be split into separate pages to improve access to the surnames (via a lk near the top of the Dab page), or
2. the surname portion is so big (over about 20 sections, with the largest sections over about 20 entries each) that placing the ToC at the top of the See-also section doesn't give reasonably easy access to all the surnames,
  ... or (IMO) if the surname entry give encyclopedic information about the surname (history, meaning, dispersal, etc.). -- JHunterJ 11:37, 30 August 2006 (UTC)
but IMO the See-also section of a Dab is usually a good place for the surnames, and usually there will be no pure pages deserving specialized Cat tags.
--Jerzy•t 09:04, 30 August 2006 (UTC)
Create a new template for the Surname disambiguations, that would be more applicable (surnames don't "pages that might otherwise share the same title") so that they would be in Category: Surnames instead of Category: Lists of ambiguous human names, to distinguish the disambiguation of "Smith" from the disambiguation of "John Smith".
-- JHunterJ 21:51, 28 August 2006 (UTC) Done. -- JHunterJ 18:04, 7 September 2006 (UTC)
Well, there should be very few such pages, as i argue under the preceding point. (So this is a very minor issue, which probably belongs after pt. 2 due to their common subject matter, but unfortunately distracts from the more important ones below.) But the examples show the legitimacy of some sort of distinction, which the titles alone don't (for me) capture.
--Jerzy•t 09:04, 30 August 2006 (UTC)
Continue to remove lists of full names from the first name entries (e.g., Jennifer).
-- JHunterJ 21:51, 28 August 2006 (UTC)
Should the lists by first name be moved to new articles, e.g. List of people named Jennifer? Or simply left in the given name article, as their own See also section? (See Talk:Jennifer) -- JHunterJ 21:51, 28 August 2006 (UTC)
For my money, there is nothing encyclopedic about a list of people sharing a given name: too specialized for a general purpose reference work. IMO, the functions they can serve should be left to baby name books (ask at your local bookstore if nonplussed) and (along with lists of people by surname that are intended to do more than help a search find a specific person or two of whom they are already are) to Web sites for people whose vanity is stroked by knowing they have something trivial in common with a group of notable or marginally notable people.
--Jerzy•t 22:24, 28 August 2006 (UTC)
Add seealso templates to surname pages to cross-reference the LOPBN project.
-- JHunterJ 21:51, 28 August 2006 (UTC)
Apparently that would be {{see also}}.
--Jerzy•t 09:04, 30 August 2006 (UTC)

Don't do it, i think, as other measures should be more effective in the long run, and the effort that would be put into that stopgap can be used elsewhere on Dabs and/or LoPbN for longer-lasting benefit. Note the maint problems for such lks, discussed in next sub-section.
--Jerzy•t 09:04, 30 August 2006 (UTC)
Add seealso templates to LOPBN pages to cross-reference the surname pages?
-- JHunterJ 21:51, 28 August 2006 (UTC)
Apparently that would be {{see also}}.
--Jerzy•t 09:04, 30 August 2006 (UTC)

No; issues pretty much the same as in the previous point.
--Jerzy•t 09:04, 30 August 2006 (UTC)

The maintenance problem goes away (or greatly diminishes), but the effort remains, yes. -- JHunterJ 11:37, 30 August 2006 (UTC)
Should less notable entries from the surname pages, to leave the exhaustive list to LOPBN?
-- JHunterJ 21:51, 28 August 2006 (UTC)
No, don't remove less notable entries (tho they should eventually be added to LoPbN if missing there), since they are optimized for different purposes; see the next subsection for details, and also the two after that for more on improving faster the independent effectiveness of both LoPbN and Dabs .
--Jerzy•t 09:04, 30 August 2006 (UTC)
In the cases where there is fuller encyclopedic information on a surname (its history, derivation, etc.) which would appear above the entries, should the disambiguating list of people with that surname be placed on the same page or be on yet another page? Both have their drawbacks for users trying to find people by last name.
-- JHunterJ 21:51, 28 August 2006 (UTC)
No: IMO even in borderline cases, a sufficient reason is to avoid undercutting the clear principle that Dab pages are solely for navigation, and that trying to piggyback in anything else (info provision) interferes with nav.
--Jerzy•t 09:04, 30 August 2006 (UTC)

The "No" appears to have a "Yes" reason after it. If the info provision keeps the surname page from being a dab, a new, solely navigational dab should be created. (Unless you mean encyclopedic information about a surname should not be included anywhere if the surname page is used as a dab.) -- JHunterJ 11:37, 30 August 2006 (UTC)
Information on the derivation, history, and distribution of a surname is encyclopedic, and needs to go somewhere. I think it belongs at Title (surname). Does Title (surname) have to be a disambiguation page? Disambiguation is about distinguishing between articles with the same title. The list of people with a given surname is clearly not a list of articles with the same title. Title (surname) pages could be regarded as outside the scope of Wikipedia:Disambiguation, in which case the derivation, etc, and the list could go on the same page. CarolGray 11:16, 7 September 2006 (UTC)
I'm in complete agreement, CarolGray. I think the {{surname}} template should not redirect to {{hndis}}. -- JHunterJ 12:22, 7 September 2006 (UTC)

If any of these prove contentious, the others should still be doable. Comments? -- JHunterJ 19:45, 28 August 2006 (UTC)

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)

Lk from Dabs into LoPbN?

(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)

Transclusion into LoPbN?

(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:
1. with most modern Western names, for the sake of putting the surname (and primary sort key) first,
2. to avoid distraction by any dab'n sfx, and
3. 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)

Trans-extraction & LoPbN

(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 {{Persondata}} 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

{{T|NAME=Magellan, Ferdinand|ALTERNATIVE NAMES=Magalhães, Fernão de (Portuguese); Magallanes, Fernando de (Spanish)|SHORT DESCRIPTION=Sea explorer|DATE OF BIRTH=Spring 1480|PLACE OF BIRTH=Sabrosa, Portugal|DATE OF DEATH=April 27, 1521|PLACE OF DEATH=Mactan Island, Cebu, Philippines}}

For the sake of demonstration, {{T}} could contain (instead of its real content) something along the lines of

{{{NAME}}} ({{{DATE OF BIRTH}}} -- {{{DATE OF DEATH}}}) was a {{{SHORT DESCRIPTION}}} from {{{PLACE OF BIRTH}}}. He died at {{{PLACE OF DEATH}}}.

The effect is that of looking up the values assigned in the {{Persondata}} tag within that bio, and using them as the parameters of {{tl:T}}. (The parameters anticipated by the current {{Persondata}} 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 {{tl:Personentrydata}}, 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.)
_ _ ({{Persondata}} 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 {{PAGENAME}} and {{CURRENTDAY}} 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 {{Persondata}} 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)

I've responded over there CarolGray 20:21, 11 September 2006 (UTC)