Talk:List of people by name/Root page
From Wikipedia, the free encyclopedia
Contents |
[edit] The LoPbN Page
[edit] Table Structure
Perhaps it's the genius of Wiki involved, rather than that of whoever coded the table in List of people by name, but it's in any case a very clean and flexible tool. Various people have used rows of it in three different approaches:
- The "native" approach is used in Rows A,C,D,G,K-N,R,V, and Z: one page per letter-pair. These can be subdivided into the
- fully-populated rows (A and Z), which have no broken links bcz (at least in the case of Z) of some pages that have the appropriate structure but (at least so far) no names, and the
- partially-populated (C,D,G,K-N,R, and V).
- The single-page approach is used in Rows J,Q,U,X, and Y: one page per row.
- What might be called the "mixed" approach is used in the rest (Rows B,E,F,H,I,O,P,S,T,W): one page per letter-pair, except where combining a group of adjacent letter-pairs in the same row produces a page of a convenient size. (Note that these "group of pairs" pages can be subdivided by splitting of one or more single-pair pages as the page grows; this means modifying the page's table entry to split it correspondingly; in theory, a mixed-approach row could by this process get converted back to a fully-populated native-approach row.) As with native-approach rows, some are
- fully-populated (E,I,O,P,S,T, and W), and others are
- partially-populated (B,F,H).
Row H is unique (as far as i know) in two ways:
- List of people by name: Ha, instead of containing all the names beginning "Ha...", acts as an index to 13 other pages, each containing the names in a range of letter-triplets.
- Row H being a mixed-approach page, there was no List of people by name: Ha but instead a List of people by name: Ha-Hd (with only "Ha..." names on it so far), which i renamed to List of people by name: Ha (and modified, besides the refactoring), converting Row H from a fully populated to a partially populated row.
[edit] Code Saved for Row J of Table
I have removed the following Wiki code from the table on List of people by name, in order to conform Row J to the conventions used in other rows that use the single-page approach. If the single-page approach eventually proves inadequate for Row J, restoring this code would convert Row J back to the native-approach, as far as the table is concerned. It is probably also the easiest first step to converting Row J to the mixed approach.
J -- Ja Jb Jc Jd Je Jf Jg Jh Ji Jj Jk Jl Jm Jn Jo Jp Jq Jr Js Jt Ju Jv Jw Jx Jy Jz
(The above code can be copied without editing this page from the following:)
'''[[List of people by name: J|J]]''' -- [[List of people by name: Ja|Ja]] [[List of people by name: Jb|Jb]] [[List of people by name: Jc|Jc]] [[List of people by name: Jd|Jd]] [[List of people by name: Je|Je]] [[List of people by name: Jf|Jf]] [[List of people by name: Jg|Jg]] [[List of people by name: Jh|Jh]] [[List of people by name: Ji|Ji]] [[List of people by name: Jj|Jj]] [[List of people by name: Jk|Jk]] [[List of people by name: Jl|Jl]] [[List of people by name: Jm|Jm]] [[List of people by name: Jn|Jn]] [[List of people by name: Jo|Jo]] [[List of people by name: Jp|Jp]] [[List of people by name: Jq|Jq]] [[List of people by name: Jr|Jr]] [[List of people by name: Js|Js]] [[List of people by name: Jt|Jt]] [[List of people by name: Ju|Ju]] [[List of people by name: Jv|Jv]] [[List of people by name: Jw|Jw]] [[List of people by name: Jx|Jx]] [[List of people by name: Jy|Jy]] [[List of people by name: Jz|Jz]]
[edit] General Template for One-Page-Approach Table Row
Even tho it's not likely to see further use, the following code template is what i used in changing row J, and isn't much effort to include here:
? -- ?a-?b-?c-?d-?e-?f-?g-?h-?i-?j-?k-?l-?m-?n-?o-?p-?q-?r-?s-?t-?u-?v-?w-?x-?y-?z
'''[[List of people by name: ?|?]]''' -- [[List of people by name: ?|?a-?b-?c-?d-?e-?f-?g-?h-?i-?j-?k-?l-?m-?n-?o-?p-?q-?r-?s-?t-?u-?v-?w-?x-?y-?z]]
--Jerzy 04:27, 2003 Dec 13 (UTC)
[edit] About missing letters
From: Paul <User:Rfc1394>
I am of the opinion this master page should have no missing entries. We should not 'see red.'
I also think we should resume standard usage of letters, and where there are no names for a particular letter combination, route back to the last previous letter that does, then link them under that letter.
If you have BA and no BB, BB should point to BA, not to a page BA-BB-BC.
When there is enough to split the page, then the page can be substituted. The empty pages can be redirects to the previous letter. This would eliminate having non-standard named pages like the BA-BB-BC example above. A page should be named (in the index) by the first letter that appears on it, not by what other letters it contains.
Or if you are going to name it for the contents, use a redirect for the original letter. That might be better. Then each letter is either a specific page or a redirect to the multi-letter page.
(On a separate note, Can someone let me know what the code is for automatic username and timestamp?)
- Done. Jerzy
Paul - mail be at User talk:Rfc1394 - 1:52 PM EDT 12/17/2003 --
[edit] Layout of 26x26 table
Personally, I prefer this version: List_of_people_by_name&oldid=1070120. If some of the letters are grouped, I'd let redirects take care of it. -- User:Docu
- This change back would (like the recent new version) produce a stylistic inconsistency with many (if not all) of the two-letter pages, such as List of people by name: Gm-Gn, which includes a "horizontal-transfer" index line reading
Ga-Gd - Ge - Gf-Gh - Gi - Gj - Gk - Gl - Gm-Gn - Go - Gp - Gq - Gr - Gs - Gt - Gu - Gv - Gw - Gx - Gy - Gz
- (I'm not taking a position that the stylistic break is intolerably confusing, nor one that making the two-letter pages match this style would be an intolerable editing burden. I'm urging keeping in mind what Buckaroo Banzai said to New Jersey during brain surgery: "Don't tug on that! You never know what it's connected to.") --Jerzy
- Nor am i looking for more than users' expressing their tastes on this to each other.
- Re Stein, i agree in liking the clever and effective
- partly bcz this kind of usage should work well together with the organizing i have spottily begun, at, e.g., List of people by name: Bennett. But i think that, unless i am missing something, any way we choose to organize the table on List of people by name will constrain e.g. editors of Stein only by leaving for them the effort of creating redirects or using pipes appropriate to their situations. (I'm glad to know this is connected to that, but i didn't see any of us tug on it.)--Jerzy 16:17, 2003 Dec 19 (UTC)
[edit] Discussion of Implementation in the Article?
I have removed to here (despite its long presence) the following text from LoPbN:
- Some of pages by first letter are not yet broken down in several pages, e.g. all surnames starting with "X" may be found under the letter "X", and not on "Xa", "Xb", etc.
Not only is it unencyclopedic, but also i can't see what value it has to people who are looking for, or adding names. Is there a problem that i can't imagine that it is solving, and if so, why is this the best solution to it? --Jerzy(t) 04:30, 2004 Feb 29 (UTC)
- No problem, it was added when the layout was different [1] and it might not be as helpful today (and no longer need in the encyclopedia "unencyclopedic" ;) ). BTW on some screen sizes, the <br clear=all> creates a lot of white space. Maybe we'd want to fill it with the description of the way the indexes are to work. -- User:Docu
[edit] Possible Reunification of Inter-Page Design
[edit] Pilot Project: Rework of B Row of the table
I previously described the B row of the table as a partially populated row that mixed the native approach and the one of sharing a page among multiple letter-pairs. It may be fully populated now, but i have yet to check that, or look at the links in it. In any case, i have delayed the overdue breakup of LoPbN: Ba (i.e., the relocation of the names on it, all beginning with "Ba", onto several pages, in each case determined by the first three letters of those names). I did so, to weigh and try out what others have argued for, and to think further ahead to include the need for scalability of this list. I'll describe here the standards i'm going to apply to the row (and mention relevant standards that i won't be retrofitting).
I will use here the term "native title in the B row" to mean any of the 26 strings of the form
- List of people by name: B?
where the question mark represents any lower-case letter.
This series of edits will involve looking at
- the B row of the master table on LoPbN
- every article or redirect page with a native title in the B row,
- each page that one of the redirects points to, and
- the three pages i am aware of that have similar names, but with the last letter an upper-case one.
I'll
- remove the column-spanning hyphens in the B row
- replace each link that spans columns in the B row, with links to the native titles
- ensure each letter-pair in the B row links directly to the corresponding native title
- (I am, after initial uncertainties, a convert on the preceding 3 points to views of User:Docu and Paul)
- recover any names from the three pages whose titles use upper-case letter-pairs, for inclusion on other pages
- ensure any LoPbN page that contains names starting with B either
- contains only names beginning with the same letter pair, and carries the corresponding native title, or
- covers the inclusive range between two letter-pairs, and has a title using those two letter-pairs, separated by a hyphen (but never has a title mentioning the letter-pairs between those two).
My reasons for this method of naming pair-spanning pages (fairly established, and also suggested in part as an alternative by Paul at this page) are
- maintainability: this is the shortest way of putting into the page's title the most helpful info for keeping track of what names are there, and
- least surprise: seeking Thabo Mbeki and landing on a page headed "...Ma" may be disconcerting, but "...Ma-Md should not be.
(Without going into detail now, with regard to the partitioning of the 26 row-B pairs into a smaller number of pages, i mention that
- my partitioning approach would give different results, for every column-spanning page, from the approach proposed by Paul in the section already mentioned, but
- rather than retrofitting it, i will be applying it only where no page yet exists for a letter-pair's future names to go onto.)
I'd be glad to explain further, for those who haven't already arrived at any or all of these approaches, but i'm going to proceed, without awaiting discussion, into this small piece of restructuring: having a concrete result should help all concerned (i being not the least helped among them) to evaluate the methods more clearly.
--Jerzy(t) 06:17, 2004 Mar 13 (UTC)
[edit] Ba/Be Outcome & J Row
I've reworked the B-row of the master table, and of the pages linked thru it, and i've broken up the Ba and Be pages, without eliciting comment. The mechanisms i used there are IMO probably the original intent of an unknown designer of the master table, with the possible exception that it's not obvious that they worked out its implications upon the growth of the tree of pages beyond the root and two more levels.
I'm proceeding to break up the J page into 10 pages, in a similar fashion. The difference between my approach and that of Paul, to pages for the letter-pairs that presently have no names, or at most have a few handfuls, was not entirely obvious from that i did on the B-row pages. (Again, i'll explain it if asked.) Those who are interested can preview a much more apparent version of my approach by following links from List of people by name: Ja (which cannot yet be reached from List of people by name: J), and by noting the population patterns of LoPbN: J. (Please Don't helpfully create the Jo page: that would interfere with creating it by a move of the J page (which i intend, for the sake of keeping its history with the numerous Jo-name entries)).
I expect to proceed beyond the behind-the-scenes part of the J breakup in the next 10 hours; so far i've kept the probability of edit conflicts and other transitional confusions low by working outside prime time. I've worked up a temporary boilerplate inspired by {{msg:inuse}}, to wit:
The following box is just a TEST of the routine long-edit notification system. If it were a real alert, you would be given the courtesy of it disappearing within about an hour, but this one may hang around forever for all i know.
| Please Note Well: This article is currently undergoing a major edit which may last something like an hour. If you're reading the list, you may have some confusing things happen, here and lower in this "tree", and occasionally it may fix the problem if you retrace your steps (clicking "Back" in your browser until you've "climbed back above" this message, and then try again). Concurrent edits should not be a problem, if you know how to handle edit conflicts.
I wouldn't want you to forget what you're thinking of editing, and i think i can be patient in cleaning up any mess that results. |
Jerzy(t) 18:51, 2004 Mar 16 (UTC)
I welcome comments.
(Following the breakup, it will become timely to edit the master table, reconverting the J row to what i have been calling the "native" approach, as i did with the B row.) --Jerzy(t) 20:28, 2004 Mar 16 (UTC)
[edit] What Next
The natural direction of the work i've been describing is to "reunify the inter-page design" of the LoPbN tree. By this, i mean reversing (at least temporarily) the trend (which i romanticized about several months ago) of editors making ad hoc decisions about how to expand the master table. IMO that trend
- has served us adequately, and
- may continue to in the long run, but
- is worth at least reconsolidating around a unified approach in, say, the next month, even if it continues to go off in uncoordinated directions again from there.
My philosophy of working on these inter-page structure issues is that
- breaking up big pages is necessary
- doing so means implicitly making decisions, for those pages, on structure, and
- it's
- better for an editor to stick to one approach, and
- better still for one approach to predominate at least in new work.
That predominance can occur informally where one person takes on the whole task, which i think i'm prepared to do; even in that case, tho, a consensus about it is valuable.
I make a point of mentioning the term "inter-page structure" because there are also issues of intra-page structure parallel the inter-page ones. I think those are by nature even more subject to diverse approaches, and i have found that fact valuable to my thinking about the intra-page issues. (Even tho those "thousand flowers blooming" is another name, for each of us, for other people trashing our work that implements our gorgeous ideas.) IMO the intra-page issues are also tougher, with our current resources, than the inter-page; also IMO it's not timely to get into how our current double-binds there may be resolvable. More on this eventually, tho IMO it can be ignored for now. --Jerzy(t) 20:28, 2004 Mar 16 (UTC)
