User talk:Phlox/Archive 2

PhloxBot on Literature Wikia
Could the Bot add the author category as you copy the WP author content to Literature Wikia? -- CocoaZen 23:50, 31 October 2007 (UTC)
 * Sorry. I didn't mean to make you or the Bot feel unwelcome.  It's ok to use the articles as seeds -- especially since you've given appropriate credit.  And you're right that a richer-content site may attract more contributors.  I just meant that it's not ok to consider just copying content as an end point.  Too many articles that are just copies will lead those new users to think that's all we have in mind -- copies of existing content.  Are you planning to make at least a few original edits?  -- CocoaZen 00:23, 1 November 2007 (UTC)
 * Was it Wikia staff that recommended the use of the Bot? I'm only one admin on the site.  If other users or staff want the imports, mine is just one opinion, and I'm ok with being overridden.  I think books might be a better focus than authors (again, personal opinion), and I worry that all the links take people away from the Literature Wikia.  Also, without any editing, these articles all reflect the Wikipedia style -- NPOV, lots of references, no reviews, recommendations and few comparisons to other authors, so if they are the vast majority of the content, they'll set the tone for prospective contributors, and the Wikia can loose its "flavor".
 * On the other hand, we certainly could use more content. :-)
 * The categories I was asking for are the Literature Wikia categories -- in this case the "Author" category to help tie it into the existing wiki. Please do finish importing the templates used in the articles so they won't have gaps.  Thanks!  -- CocoaZen 01:34, 1 November 2007 (UTC)

I agree with Cocoazen. Mirroring wikipedia isn't a good way to make a small wiki grow, if the wiki isn't different from wikipedia in ignificant ways newcomers would rather edit wikipedia instead.--Rataube 03:39, 2 November 2007 (UTC)
 * The most successful wikia, Psychology, found the opposite was true. They deepenned those articles but attracted traffic of proffessionals by having a rich set of source material to start from.  "Mirroring" reflects an extremely restricted view of the power of leveraging WP content.  Think "seeding" instead.  POV is not expressed in any of those WP articles, but POV is encouraged on your wikia.  So there is ample reason for a user to contribute to your site and not wikipedia's.  But if you want to stay at 240 articles, fine with me.  Further responses on your wikia.   ~  Ph l o x   06:53, 2 November 2007 (UTC)

your note
Hi, with respect to your note to me, I'm not sure what you're asking. Could you explain further what kind of advice you want? John Kenney 22:20, 1 November 2007 (UTC)

Are we talking royalty or nobility? The box isn't bad for royalty, but I'd prefer not to describe a Duke of Norfolk, say, or a Viscount Palmerston, as "reigning," and of course peers don't have coronations. Let me think about further potential issues. John Kenney 23:02, 1 November 2007 (UTC)

P.S. "Regent" is usually going to be irrelevant, even for some monarchs who actually came to the throne as minors (for instance, Richard II never had a single regent.) John Kenney 23:04, 1 November 2007 (UTC)

Years, etc
Years, etc, now massively done. I wondered why none showed up on my watchlist. Then I saw which recent years had been created and I worked out that you imported only the missing years. Fair enough.

Template:Month3 and its mates would be a very handy next addition, so that folks can instantly see what date Granny meant when she said "My birthday is on Sunday".

I'll absorb implications as I browse. Now off to the dentist.

(PS - I'm enjoying Firefox 2)

--Robin Patterson 00:04, 2 November 2007 (UTC)

Not been studying your "Contributions" or looking at more than a tiny percentage of the results, so I may have missed the answer to this question. Have you progressed with my above idea "Template:Month3 and its mates would be a very handy next addition, so that folks can instantly see what date Granny meant when she said "My birthday is on Sunday"."? Robin Patterson 08:15, 16 November 2007 (UTC)


 * You aren't using enough words. Where do you want Month 3 placed?  Do you want a calendar in each year article using Month3?   ~  Ph l o x   08:58, 16 November 2007 (UTC)


 * Same way as WP uses them. I forget whether I've looked at the linkages, which have improved out of sight since I laboriously copied a couple of dozen templates of that sort for the Maori Wikipedia. Is that enough words or should I do more legwork then more spelling-out? --Robin Patterson 02:55, 18 November 2007 (UTC)
 * I missed this response. Ok, I will add this to the list.  If I need more clarification, I will talk page inquire.  ~  Ph l o x   19:35, 6 December 2007 (UTC)

Multiple spouses and children of other spouses on info templates

 * Could you take a look at Peter Pickard (1791-1872)/info? I enter the data for all four of Peter's wives, but they won't appear at Peter Pickard (1791-1872). Also, as Peter had children with multiple spouses, how does this work? Or is it not set up yet? - AMK152 (Talk • Contributions 17:29, 2 November 2007 (UTC)
 * You uncoverred a bug, and it will be fixed today sometime. Detail if you are interested: To avoid the expansion limit, I only display spouse 2 if spouse1 exists and so on for spouse 3 through 5.  The bug is that it was checking for the MarriageN field instead of the spouseN field.  I am optimizing the info code and expect to revise Showinfo Person today.  At that time I will fix that bug but may introduce others.  Bear with me.  This rewrite is necessary so that we can handle deep family trees like what you are doing.  If you want to understand the technical issues, I am documenting them in the technical article on info pages.  Take a look especially at pre-expand limits and the wikipedia article on the issue.  It can be dealt with, but if you thought the template code is already esoteric, it is about to get even more esoteric.  Can't be avoided.


 * In the next few days, I expect also to have the children of other families working. I like your suffix scheme and will use it.
 * ~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x  19:23, 2 November 2007 (UTC)

Picture Bot
Thanks for coming over to psychology wiki and letting us know about this, such help is really appreciated. Can the bot identify the pages that need images? - thats been on my wish list for sometime - or do we have to add them to the list manually? It would help us a great deal if this could be automated as we have a large number of wanted images, almost exclusively from WP. Dr Joe Kiff 08:21, 3 November 2007 (UTC)
 * As we have so many images it would be really useful if you could scan all the pages on the wikia, assuming all this is automated. Its too much to do if you have to input approvals etc. but if it could run overnight on its own then it would be a brilliant solution and save us a huge amount of time.Please go ahead if you can do it. I estimate we need about 3000 images in the 30000 pages Dr Joe Kiff 08:42, 3 November 2007 (UTC)
 * The wonders of programming!! We will be really pleased if you can pull this off. My fingers are crossed and I will try to keep an eye on it from this end Dr Joe Kiff 08:57, 3 November 2007 (UTC)
 * Are you happy it is going OK? Like you say it is hard to monitor it from our end as we cant get onto it to do "what links here". I am trusting that its doing the job correctly. I have looked at the list of uploaded files and while there is the odd one or two titles I find unexpected they are probably linked to articles. Certainly the speed of the site is not noticeably impaired for users.We are really grateful for your help here as it is clearly saving us a lot of time.Dr Joe Kiff 07:14, 5 November 2007 (UTC)
 * The work on adding in missing templates would be useful. I will print out a list of them so I can check them through for relevence once you have brought them over.Thanks again for your help Dr Joe Kiff 07:56, 5 November 2007 (UTC)

I have put a note on Catherine's page. What was the nature of the vandalism? Dr Joe Kiff 17:53, 11 November 2007 (UTC)

Showinfo template links to parents

 * The parent links aren't showing up on the info pages. Are we just linking them with and  or is this some error? - AMK152 (Talk • Contributions 21:43, 5 November 2007 (UTC)

Ahnentafel with birth/death information

 * I created a template (Template:AhnentafelSimpleTable) that, if entered the name, it will automatically enter their birth/death information. (If they have info pages) However, I am trying to get it to resemble the showinfo children template. Also, I can't figure out how to fix the spacing at my test page. Thanks for any help. - AMK152 (Talk • Contributions 21:13, 8 November 2007 (UTC)
 * What you were doing was perfectly legal but I think you ran into a problem the table generator has with attempting to calulate the proper height of cells. If I had to speculate, I would think the wikimedia code is making a bad guess due to the complexity of your noinclude/include statements and probably the order in which the are evaluated.  The workaround was to eliminate the extraneous stuff that had this spookey effect on table height calculation. This takes care of the problem I think you were refering to.  If there is something unanswered, let me know. <font color="#0A9DC2">~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x   03:31, 9 November 2007 (UTC)

Ohio births vs. Born in Ohio
I personally like Ohio births, but only because it seems to be more consistent with other states. However, I think the most important thing is that there are not 2 categories designed for the same purpose. By the way, my hope is that eventually, this will turn into a birth index, cross-linked with year and county, so that there will be, for example, some day categories like 1856 Harrison County, Ohio births. Kborland 23:55, 16 November 2007 (UTC)


 * I'd support the "1856 Harrison County, Ohio births" sort of refinement. Possibly can be done now in "report" form by pulling in every page that is in both the county or state births category and the year births category. I've read somewhere in this wiki (over a year ago) about intersecting categories like that. Phlox comment? Robin Patterson 03:05, 18 November 2007 (UTC)

County header box dates
"prior to 1400 • 1400-1449  • 1420-1499  • 1500-1549  • 1520-1599  • 1600-1649  • 1620-1699"

Those 20s should be 50s. To make the thing a bit shorter, maybe the next century should also be just 50-yr groups instead of 20? Robin Patterson 02:59, 18 November 2007 (UTC)

Tabs
Ahh, we have to put "main" in or something so we can navigate back to the main page from the subpages. --Richard Arthur Norton I 23:35, 21 November 2007 (UTC)
 * Now its fine, I just use the short version for the main page and the long for the subs.

Benjamin Putnam (1664-1715)/info
I can't seem to figure out why the info page is all messed up. Perhaps you can help? - AMK152 (Talk • Contributions 00:49, 24 November 2007 (UTC)

County forum index
I started a county forum index at Forum:Counties Index, to be an index list so people can easily find where to put their county by county inquiries. I did Alabama; but could the bot finish up? - AMK152 (Talk • Contributions 19:37, 25 November 2007 (UTC)

All's well
I've managed one day recently (NZDT) doing no edits on the G-Wiki but you can't keep a good man down for long (although this month Bill managed many more days off than I did). Almost dizzy watching the marvels of modern genealogy rolling in. And keeping an eye on WikiStats - this month sets another record: six people doing more than 100 edits; OK, it's only a robot, but it counts!! Keep up the good work! I noticed you saying recently that we have only about 10,000 "person" articles; I thought to myself that you could double that in one stroke if you cracked the GEDCOM problem and applied mine. Robin Patterson 09:49, 26 November 2007 (UTC)

wpxfer or whatever you call it
Please do what you can to ensure that few if any articles that have been through wpxfer have something like this near the top: <tr class="mergedbottomrow"><td colspan="2" align="center">

OS grid reference Template:Oscoor London borough Hounslow  Ceremonial county Greater London  Region London <tr class="mergedrow adr"> Constituent country <td class="country-name">England  Sovereign state  United Kingdom  <tr class="mergedtoprow"> Post town BRENTFORD Postcode district  TW8  Dialling code  020  <tr class="mergedtoprow"> Police  Metropolitan

Fire London  Ambulance London   <tr class="mergedtoprow"> UK Parliament  Brentford & Isleworth  London Assembly South West European Parliament London

--Robin Patterson 22:49, 26 November 2007 (UTC)
 * Can you give the name of an article where the problem you are seeing occurred? <font color="#0A9DC2">~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x   23:24, 26 November 2007 (UTC)


 * That one was Brentford, London, a page I created 6 months ago and spent some time tidying. Robin Patterson 21:03, 27 November 2007 (UTC)
 * Oh. Actually that junk is not in the article but from the infobox uk template that was recently uploaded.  The problem with the template is that it is not using wikitext, but html.  The quick hack is to simply remove the infobox reference.  The serious fix is to rewrite the infobox uk template to use wikitext table syntax.  I have marked it with Template:htmltidy and will get to these after the Gedcom situation is dealt with, or perhaps some folks that aren't shy about templates will show up and be willing to deal with them.  I will null out the transcluded content of templates marked with htmltidy so affected articles won't look ugly.  <font color="#0A9DC2">~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x   21:18, 27 November 2007 (UTC)

ged. files
Hi Phlox. ged. files are now enabled here. Please let me know if you have any problems. Regards -- sannse (talk) 13:55, 27 November 2007 (UTC)

Contributions in Russian
Forum talk:Social Security Numbers could be for you; tell us what it's about, please! Robin Patterson 00:58, 29 November 2007 (UTC)
 * Not a serious message. He just remarked that the new years holidays are coming up and wanted suggestions for close family.  Looked like native Russian, but the Shanghai IP suggests he could be goofing around.  Whatever.   <font color="#0A9DC2">~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x   02:17, 29 November 2007 (UTC)


 * FYI, that page was made by a cross-wiki spammer who spammed 37 other wikis. GHe (Talk) 17:34, 30 November 2007 (UTC)
 * 38* other wikis. I've deleted all the spam pages made by the spammer. GHe (Talk) 17:38, 30 November 2007 (UTC)


 * If you do a search for the term " ", you can see that it has been posted everywhere. Also, article titles containing " " ("Gifts for the New Year") (the summary used in the above spam) have been blocked recently due to spam, and I've just blocked summaries starting with that phrase to prevent further postings of similar spam. GHe (Talk) 19:33, 30 November 2007 (UTC)


 * It's most likely a spambot. GHe (Talk) 19:44, 30 November 2007 (UTC)

Wikipedia death age template
Any chance you could migrate over the death age calculation from Wikipedia? It is used in the date of death template. I see it, it needs a fix. It has a comma out of place. Ok, now that they are fixed, I need a tweak on one I created: Template:Birth date and ago, I want to switch the test to the other side of the number, so it reads "175 years ago" instead of "years ago 175".


 * the comma is now missing in the template. --Richard Arthur Norton I 22:30, 4 December 2007 (UTC)

Template:Years ago caption
Here is a new template with a booboo. I have this one to just calculate the years elapsed between two dates and not display the date. I use it when i don't know the month and day of a birth. --Richard Arthur Norton I 03:51, 5 December 2007 (UTC)

I don't want it to shw the date at all. The date has been padded with January 1 as filler. So it should just display (150 years ago). Cheers. --Richard Arthur Norton I 04:23, 5 December 2007 (UTC)
 * Thanks again! I am using Firefox, is that a problem here?

Google rank of pages - adding anything to plain name?
"Page name" is one of the things we should settle before wholesale importation from GEDCOMs, I agree. I read your comment about it not mattering much whether a page name contains " (disambiguation)". Doesn't the addition of anything to the plain name reduce the "percentage" part of what determines ranking? Wasn't that part of your reason for the firm decision to depart from our standard of including death dates (which decision has not been adopted by other major contributors)? Robin Patterson 00:50, 6 December 2007 (UTC)
 * Google was only part of it. The part having to do with Google is the bit about including middle name between the first and last name.  That is really dumb from a ranking perspective, because the weight of a term is determined by how closely it is adjacent to the other search terms.  Secondly, it is important for phrase search because "Elvis Presley" will get zero hits on our site because article Elvis Aaron Presley (1935-1977) makes no mention of an "Elvis Presley".  Even if it did, our rankings would be submerged because our site felt the term was not germaine enough to the subject to include in the Title.  Really, really self defeating...
 * Anyway- you have a point that the more terms you shove in a title, the more you water it down. I was stating that adding "disambiguation" to the end is not fatal like adding "Aaron" to the middle is.  So there is a google factor there, sure.


 * The main problem I had with putting data like dates in there is that it encourages churn in the database. Everytime someone comes in and has a different date in their genealogy files, or think that the date is not certain (should be c1856, not 1856)- they want to move the article.  But our articles are aggregates- All will have at least the article page as well as an info page.  Many will have separate ancestors, pictures and tree pages as KBorland is doing.  Will the contributor move all pages properly?  Maybe sometimes, but probably it will get screwed up frequently.  So it presents a collosal maintenance pain for what- so that we can follow a conventions designed for paper filing methods? Discovering the death date is just a click away.  And the cost of saving people the time to click?  Massive maintenance burden.  But let's get realistic about that.  Given millions of articles, it means this work simply will not get done- which means what?  That's right- Our site starts to turn to junk, with numerous broken articles.


 * Certainly, that problem doesn't happen at the 10,000 article number, but hey- Are we planning for a 1st tier genealogy or not? Sure we could fail for any number of reasons- but why plan for failure?  Plan like we are really going to pull this off.  We are not going to have one million, or just two million articles.  The gedcoms on file already exceed those numbers.  And what happens when this goes global and snowballs?  Both of us may be old guys, but within our lifetimes we are easily going to see hundreds of millions of articles on this site Robin.  That is an enormous enormous maintenance burden for those that come after us and we have to be hard nosed about what we do to preempt massive maintenance burdens that don't deliver significant pay offs for users.


 * I do not make the proposal lightly but we have to look at the rationale for the conventions and challenge whether they are relevant to our problem domain. Should we use all caps in the Surname?  Well a decade ago, suggesting anything different was rebellious/naive idea.


 * I don't see why we should be a slave to convention, especially if it delivers insignificant benefits and will have such serious costs in the future.
 * <font color="#0A9DC2">~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x  02:20, 6 December 2007 (UTC)


 * OK, death years are nice (and very little detriment googlewise) if nobody's going to change them but we can't guarantee that, so chuck them (and allow 50 times as many disambig pages because that's a minor irritation). Same with birth years then? They are even more susceptible to change, and a name with just one date is unconventionally odd and therefore likely to puzzle newcomers and even turn them away. Shall we then agree that an individual's page be the plain name (same as on his or her disambig Google-target page) plus a fixed distinguisher such as a thingy-number (which you mentioned a while back but I haven't time to look up) - I could be happy with that. Robin Patterson 13:23, 6 December 2007 (UTC)
 * Wow. Birth years too?  I knew you were closet radical.  Well, I suppose it is not totally radical.  After all, LDS does this in their ancestry files.  In ancestry files, they use NAME (AFN).


 * The thingee- the generic term for what an AFN or a genealogics Person ID is "UID" (unique identifier). Some genealogy sites use the term UID and export them as part of their gedcom data.  Naive users are going to create ugly links though- eg David Henderson (729382).  I suppose I could make an info template that looks up the data on the fly.  EG:

looks up birth and death and displays that as if the person had gone to the bother of typing the wikitext David Henderson (c1734-1810) So what are the Cons?
 * Will disambig pages really only be a minor irritation? I have seen a surprising number of multiples even for uncommon names.
 * There will be thousands of them but very easy to handle. Robin Patterson 03:57, 9 December 2007 (UTC)


 * Audience reaction? Will folks have a Frankenstein reaction when they see David Henderson (729382) as the title of the article on their beloved ancestor?  Will it really be William I of England (390351)?
 * Learning curve/ barrier to contributing? Ok- We make it simple to generate UIDs-let them make them up- Any 6 digit number.  Otherwise, if we have something more complicated like a computer generated UID as I originally proposed, then we have to wait until I figure out how to make a widget do a form that will input the data and create the UID on an info page for them.
 * The way DLP works, I am not sure that I will be able to generate a friendly name. I think it may have to have the UID because it wants to use the real title of the article.  Of course, we can put a column in there for birth and death years, so not that big a deal if that turns out to be unavoidable.
 * Will long numbers in a title downgrade a google hit? Possible rationale- the page is more likely to be a technical or database like dump page. They might do this- it is said they examine 60 or more factors.  No way to know for sure.  I suppose we could make it 3- there might be collisions, but they will know when they create a page.  If we make it 4, people might assume it is a date.  When a 3 range starts to get exhausted, we could tell people to use 6 digit numbers.
 * Sing along with me: "Secret Agent man... We're giving you a number, and taking away your name".  Numeric identifiers make ancestors more impersonal.  Date of birth is less impersonal, but that is not without problems- eg John Smith (1956)  Worth it?  I don't know.  But it's the impersonal factor- how big a Con it is, that's a subjective judgement call.
 * Any more cons?  <font color="#0A9DC2">~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x   17:22, 6 December 2007 (UTC)
 * Since the naming disambiguities are only going to occur, by definition, in the same surname, why not have people who own or regularly contribute to each surname decide on a case-by-case basis how to name their individuals? For example, the Dzyban family (a small family of an ethnic minority in the hills of Poland) will probably have different needs in page naming than the Smith families of the U.S.  Perhaps instead of numbers in the titles to disambiguate, there are other options as well, i.e. John Jones (1800-?) of Pittsburgh, son of Bill & Mary.  Perhaps the creativity and flexibility allowed in the Wiki format is is best feature, after all.  I think uniformity in page naming is far less important than uniformity in categorization, since the categories we're creating are going to become the real tools that set this site apart from others as far as search capabilities.  For example, being able to generate automatic lists such as New York City births in 1608, etc. Kborland 01:38, 7 December 2007 (UTC)
 * Certainly, these will be guidelines not policy and folks may elect to depart from them. Robin is aware that I shall be importing a very large number of articles into Familypedia in the foreseeable future.  For now, that is the scope of articles that will be affected.  But due to the number of articles involved, it will become the de facto standard.  So although it could be altered later via bot, it would be better to have the discussion now rather than after the import.


 * Anyway- to your comments- you are right that predictability and uniformity in cats is important. But your particular example is mistaken.  A hard coded category scheme as you seem to suggest won't scale.  Fortunately, we don't need to hardcode categories like "New York City births in 1608".  The database functionality you envision will use real database queries using DLP.  The database features depend on stability in names of objects, and that is a vulnerability we currently have.  This along will google searching is the driving motivation of the naming convention discussion.  Do you see how Template:Info categories can extract information from an info page and generate a category?  Well- when there are enough "born in New York city" folks on the wiki, that template will generate a marker along with a bunch of other markers for fields you can query like mother's maiden name, death city etc etc.  Buckets of them to query on.  If you attempted to hardcode them as categories, you run into a combinatorial explosion.  But you don't have to because DLP can generate a list with a query like: "get me articles with death city NYC, surname Smith, death decade 1890".  I've done demo examples for Catherine Price, Bush and Obama.   It can do this because all the information is in an easily locatable form so that it can be extracted easily.  But what happens if the person renames the article and forgets to move the info page?  Notice how many times you have to rename due to changing information about the subject?  Why are people doing that?  Because they are putting data that is subject to change in the name.  This makes the wiki by definition an unstable database.  Stability in naming means that info pages don't get separated from their articles.


 * Whether or not you agree this sort of solution is necessary, you are free to opt out. The info templates don't assume that there is some special number in the name that it needs in order to function.  It will make no such assumptions, so folks can do "Bob Jones (c1863-??) of Pittsburgh, son of Bill & Mary", and change it to "Bob Jones (c1863-1922) of Pittsburgh, son of Bill & Mary" when they learn the death date, and rename it to "Bob Jones (c1863-1922) of Pittsburgh, son of Bill & Catherine", when they learn Bob was actually the son from an earlier marriage etc etc.  No problem.  Just so long as you move the Info page along with it, you will get all the benefits of dynamic query and info pages.  Bit of a hassle though- and most folks aren't going to do it.


 * And really- you don't have to bother with the info page either if you don't want. No one is going to force anyone to do anything they don't want.  All I'm saying is that the info page features aren't going to work without them.  You may not care about them with only 10,000 person articles.  I predict you will care with millions.
 * <font color="#0A9DC2">~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x  02:43, 7 December 2007 (UTC)
 * I have been doing reality checks in my head, you know- creating mental mockups of what the site would look like with these funny numbers at the end, and it seems to me they may be too disorienting, because there is no context of time. It forces the display name be friendly- so the real name with the funny number never shows up in the article.  That is yet another bit of learning curve to add to our contributors-  Like we have to tell them- forget what you know about article name linking.  Instead always use , otherwise you won't get the friendly name displayed.  But even for experienced users, it would be disorienting because look at what it is like in cases when you are trying to sort which person of a similar name is the correct father.  You are discussing these two Joe Unknowns, and the article display says Joe Unknown (1734-1776) but says only   versus   on the edit page.  It's a PITA.


 * So I am not sure my proposal won't create more problems than it solves.  Maybe we just have to keep enough Bot operators trained to make periodic passes after people inevitably leave messes after renaming articles.   <font color="#0A9DC2">~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x   23:54, 8 December 2007 (UTC)


 * Instead of a meaningless-looking number, how about a relatively change-proof decade? George Bush (1930s) would be a fairly easy thing to teach people, obviously meaning something to them and avoiding "c" and "bef" and "aft" (mostly) and small year corrections almost entirely. Easy for bot to put them in their "Born in the ....s" category. Until we get another George Bush born in that decade we have two distinct pages linked from our Googletarget George Bush with no doubt in most searchers' minds about which one they want (and no need to disguise the true pagename with a ); when we do get another, we  (ie any ordinary user) can create more distinctive pages with less need for rules to specify the precise form. Robin Patterson 03:57, 9 December 2007 (UTC)
 * Yeah. Small point though- the bot won't treat anything in the article name as data for reasons I was intimating to Kevin.  It keeps it clean.  But your proposal deals with most of the problems.  It is a good 80% solution for name moves, since 20% will be on the decade cusp (1849 vs. 1850 birth), with the remainder (some of my "befores" could be as much as 20 years before my guess- Some are based on socio-biological minimums for likely motherhood age.  Anyway, they still are going to call us weird, but I think we are getting closer Robin.    Thanks- it was a good proposal.   I will do some more mental modeling and see if it holds up.


 * By the way, I was a dunderhead for not thinking about this, but I am going to have to crank down the knob on my activities here for the holiday season. I've got 4 kids 2-6 years old and I shouldn't be undertaking anything major like info page switchover until after the 1st.  So I think I will be mostly puttering around here and will hold off on any major bot runs.  So happy holidays and pass the eggnog, heavy on the nutmeg.
 * <font color="#0A9DC2">~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x  04:20, 9 December 2007 (UTC)
 * Robin- Two things on your "1930s" proposal:
 * If there are two George Bushs in the 1930s, we have a disambiguation page. What article names does the disambiguation page point to?  Are you proposing some variation of the funny number then? eg George Bush (395) (1930s)?
 * Bill made a good point in the context of a gedcom discussion about many people's genealogy research being based on tertiary sources- simply copying a relationship because some Gedcom file said their was a parent child link. So for bulk GEDCOM import, having a vague period in a title like (1860s) is completely appropriate indication to people of how they ought to regard articles that contain no primary source evidence.


 * If that convention gained traction, then perhaps it would be built on. For example, renames to something specific might be done if the confidence in the information was elevated.  For example, if it turned out that the imported material is verified by a contributor as having sufficiently reliable source material that supports the the specifics contained in the article.    <font color="#0A9DC2">~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x   19:30, 10 December 2007 (UTC)