User talk:Phlox

 Feel free to Drop me a note. Archived talk: 1 | 2 | 3 ending April 2009 | 4: just May 2009 | 5 | 6

Locality
Just looked at your changes to The Hague. All fine. However, you opted for human readable latitude and longitude of minutes and seconds, while Google Maps uses real numbers. Going back and forth between the two is not that difficult, so that we can automate the use of Google Maps.

When the localities are done, we should also be able to automate maps as these: Richard S.J. Tol (1969-)/ancestors which shows were all my known ancestors were born. The code of the map is simple but tedious, just the sort of thing you would want the computer to do in your stead.

Keep up the good work! rtol 05:59, 1 June 2009 (UTC)
 * The coords for The Hague were automatically extracted from WP infobox code. Personally I prefer decimal.  The infobox extraction templates are in preparation for very high volume transfer of placename data from the wikis.  Regarding digital vs dms- Actually the plan was to run bots to normalize them all into decimal form.  However, this may be unnecessary since the lat/ long proximity search (see Robin post from yesterday) has been added to SMW and will likely be available to us soon.


 * I did some demo work with the googlemaps extension immediately after I got it activated here, and I recall you could set pushpins with popup text right? Yeah- All that sort of stuff we should be able to automate.  Also coming down the pike for visualization aids is the semantic timelines extension.  No word from uberfuzzy yet on when that will go through inspection.  It's pretty neat- you can just dump in a bunch of dates with annotations and it sorts it all out and makes it pretty.


 * On the language front, the tech heads have no great solution to the logged out user problem, so my view is that we do multiple pages for multiple languages rather than a single page for multiple languages. The former approach is demo'd in Barack_Obama_(1961)/fr.  A logged out user will see the content in french.  The latter approach uses mediawiki messages eg I internationalized the person template with them so if you change your language, the table rows will at least display in the correct language eg .  The latter scheme is the worst because we require the users to set up an account to see things in their native language.  That's too high a barrier.  So the other experiment with the Hague that I am doing is using SMW properties to store the alternate language versions of the placenames, and we use those for matching foreign language versions of places in Gedcoms.  Side benefit is greater support for foreign language visitors.  - ~  Ph l o x   06:49, 1 June 2009 (UTC)


 * Even better than I had hoped. rtol 07:10, 1 June 2009 (UTC)

Karehana Bay and Camborne
I see that you saw my second "form" locality. Not sure if you saw the first one. I'm sure the system will be fine eventually. Tell me when you want it tested again.

I've lived in this house since it was completed in 1976. I know the city well. My children did get taken on a few trips further afield, including one trip to the "Mountain" (Ruapehu).

— Robin Patterson (Talk) 02:06, 4 June 2009 (UTC)

Ahnenbug?
Ingeltrude de Paris (?-?)‎‎ has Charlemagne with ahnnumber 10. On Descendants of Charlemagne (Generation 4), the query "all CM's descendant with ahnnumber 10" returns empty. I can't figure it out. rtol 17:09, 1 June 2009 (UTC)
 * The subject did not have a birth date property value, and this confused the sort. I commented the sort out to demo this.  Sounds like a bug to me.  Did you report the other one regarding apostrophe's in the article name? - ~  Ph l o x   22:34, 1 June 2009 (UTC)
 * Thurstan reported the apostrophe to you. I did not report anything to anyone. rtol 05:11, 2 June 2009 (UTC)
 * Bug confirmed. With the sort on birth date, CM has 17 kids. Without the sort, CM has 20 kids.
 * Birth date sorts correctly, by the way, unlike birth year which is a string. rtol 05:15, 2 June 2009 (UTC)
 * I put a ? as Ingeltrude's birth year. This did not change matters. rtol 08:19, 2 June 2009 (UTC)


 * Oh I thought you reported the apostrophe thing. Sorry.  Regarding birth year as a string... Heh heh.  Obviously the partial date values should be numeric, be default zero and the form template should set a year value derived from the full date value when available.  Sorting using the full date field isn't what you want regardless of the Ingeltrude bug.  Default year zero is ok since it is an illegal year.  That will keep sort happy- which from what you say seems to toss illegals as if they didn't exist.  Seems to me that unknowns should be very rare though. If a parent or child is known you always know an approximate date usng "before" or "after".  For instance an unknown child birth must have Birth Year >mother father birth plus at least 13-15 years. Similarly for unknown parent.   Lots of little things like partial dates have not been attended to, and part of the reason I keep saying the SMW stuff is not yet ready.  It is a housekeeping thing- I'd have done it already except that extracting year requires #time and that function has a bug that requires some elaborate code that I have not yet moved over.  Anyway, you understand that you are starting to live in a house that doesn't yet even have a roof on it.  On that score progress looks good- the fundamentals are beginning to stabilize.  I don't expect that much radical will happen after the multilingual thing is sorted out.  I am pretty much of the mind that all templates and forms will be hard coded in other languages rather than rely on Genealogy:Multilingual messages.  - ~  Ph l o x   16:32, 2 June 2009 (UTC)
 * SMW may not be ready, but it is too much fun to wait. rtol 17:36, 2 June 2009 (UTC)

Kids
Property:Children used to be the union of children-s1, children-s2, .... This does no longer seems to be the case for children-g1, children-g2, .... rtol 12:30, 2 June 2009 (UTC)
 * Now solved and tested. Thanks! rtol 17:36, 2 June 2009 (UTC)

Admin assist
Can you please remove the auto-Wikilink-the-dates functionality on Template:Cite web. (It's a protected page, so I can't do it myself.) EN-Wikipedia no longer wikilinks dates, and doing so here is probably impractical and just adds a bunch of red links. Happy to discuss of the template's talk page if you think others would disagree, but I don't think most others would care. Thanks. —DeGraffJE talk 00:28, 3 June 2009 (UTC)
 * [[File:Check yes small.png]] done. - <font color="#0A9DC2">~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x  07:29, 3 June 2009 (UTC)
 * Thanks for your help! —DeGraffJE talk 23:47, 3 June 2009 (UTC)

Broken again
I now get the long form when clicking a red link, but the "edit without form" does not work, and neither does typing in the page title in Firefox. rtol 18:04, 4 June 2009 (UTC)
 * I turned it back off on the ones I was testing, so you shouldn't see that anymore. Let me know if that is not the case.  - <font color="#0A9DC2">~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x   18:37, 4 June 2009 (UTC)

GEDCOM
http://genealogy.wikia.com/wiki/Help_talk:Loading_Gedcoms#GEDCOM_upload_under_SMW — Robin Patterson (Talk) 05:03, 5 June 2009 (UTC)

Need crumb
I still don't understand how you write the "facts" box at the bottom of the page. I'd like to add some diagnostic checks comparing people's birth dates to their parents' and so on. Could you write a simple "age at death" template? Does not work with the birth and death years at the info page because these are strings. Thanks! rtol 18:07, 8 June 2009 (UTC)
 * Ok. See Age (smw).  George_Spencer_Geer_(1836)'s age at death was.


 * BTW- I don't write the facts box (though this could be done). The facts box is a standard feature of SMW (that can, and probably should be turned off once we are exposing all these values in the article(s)).  The shutoff wikitext is like NO TOC,  a __Magic Word__ that is in the SMW docs and on my notes page.


 * Date math is not especially simple, especially given that we allow for two different kinds of date fields (actually 3), but for this purpose there is the precise date versus approximate Year and month. The function should calculate the age correctly except for dates in a weird segment of time between 100BCE and 100AD that the #time function does not support.  I'll fix this later- it is more involved.  You basically add a large number then subtract it when you are done, but it turns already ugly code even more ugly.


 * George_Spencer_Geer_(1836)'s age at death was . I put in some sparse docs but it probably should be decorated with esoteric and explained a little less briefly.  Maybe we should vector to this one from the Age template if the article is an SMW article.  Anyway, please doc and / or improve as you see fit.  - <font color="#0A9DC2">~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x   21:14, 8 June 2009 (UTC)


 * Thanks man! I thought I asked for something simple. I'll have a go at mother's age at child birth. rtol 21:39, 8 June 2009 (UTC)
 * Actually it just looks complicated. Anyway, for your variation you can do this simply by replacing the top level function.  Instead of the ask sending one query to the aux routine, call the aux routine directly with parameters from 6 asks.  The first three are mothers b date, b date-y, b-date-m.  The second triple for the child is used as the end date in place of death.  No need to mess with the math routine. - <font color="#0A9DC2">~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x   22:34, 8 June 2009 (UTC)


 * age mother at birth correctly returns my mum's age when she gave birth to me. Will come in handy as a diagnostic, but the info-page version is expensive, right?
 * age (smw) is now deployed at biography. rtol 08:00, 9 June 2009 (UTC)
 * the cost of age (smw) is practically nothing. The rest of the info based stuff that biography is doing is a little expensive and should be converted to smw calls.  Doesn't facts from info recover all the properties you need for biography?      - <font color="#0A9DC2">~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x   08:13, 9 June 2009 (UTC)


 * It does. I'll have a close look at age (smw) to find out how to display smw info. rtol 08:24, 9 June 2009 (UTC)

inquiry from a drive by contributor
I have never found this website before. What is it and is it free genealogy or what?

Category talk:Multilingualism
I would appreciate your spending 20 seconds in the next few days to give your followers a clue about my note at Category talk:Multilingualism. — Robin Patterson (Talk) 02:59, 12 June 2009 (UTC)

ahnentafel bug
I believe I understand the bug that produces "Expression error: Unrecognised punctuation character "&".

Have you seen any cases where it happens with an article that does not require an html entity for it's page name? The problem is that in the ahnentafel and descendants templates, I used a semicolon to delimit fields. This is evil because unbeknownst to me, smw will substitute html entities in these strings, and of course they are terminated with semicolons.

Unfortunately, the fix will require regeneration of all these trees. -~ Phlox 16:57, 12 June 2009 (UTC)


 * That's progress. I've only ever seen this show up where there was supposed to be NAME (YOB-YOD). rtol 17:53, 12 June 2009 (UTC)

Set desc v set dsc
My primitive understanding is that a template like "set desc/aux1" or "set dsc/aux1" only works one page at a time. "set desc" retrieves children one by one and passes them into "set desc/aux1". "set dsc" retrieves groups of children and passes them into "set dsc/aux1" as a group; only the first child is processed. I could not solve this, or get SMW to give me one child at a time, so I resorted to the parser calls. rtol 05:19, 13 June 2009 (UTC)


 * I see that you replaced "set desc" with "set dsc" in "info categories". It's faster but not faultless. Mysterious errors, like skipping a generation, or just ignoring information even after a triple flush. rtol 06:11, 14 June 2009 (UTC)
 * A 100 parser count for a function that doesn't produce accurate results is a little pricey. Let's straighten out set dsc rather than resort to gets on info pages.  I know what that thing is doing, and it is horrifying how much work the wikia servers are doing to generate these lists that way.  Now, as I pointed out in note to you, "Set desc" does not handle the two children of the test case for set desc let alone more esoteric test cases.  If you put in monitoring messages into set dsc, you will find that set dsc does the same sequence of calls that set desc does.


 * The difference is that set dsc operates off of smw info transfered from info pages. I expect this is the source of the errors.  If you can point to a specific test case I would like to isolate what is going on here. - <font color="#0A9DC2">~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x   06:32, 14 June 2009 (UTC)


 * My bad. Sorry. I apparently did not flush systematically. All seems fine with "set dsc". rtol 06:24, 14 June 2009 (UTC)

Generation numbers
Robin insist on is rather keen on the idea of displaying the generation number of descendants of Charlemagne.

There are three ways of doing this.
 * 1) Take the ahnnumber of Charlemagne from the person's page and convert this to a generation number.
 * 2) Take the generation number of the person from Charlemagne's page.
 * 3) Introduce Property:Order of Charlemagne and set it equal to min(Father's order, Mother's order)+1.

Option 3 is the simplest (I thought), but I can't even do Father's order+1. I retrieve the generation correctly, but when I passed it to a template to be increased, it returns Expression error: Unrecognised punctuation character "[".

I've been wrestling with Set Order of Charlemagne and trying it out on Amaudru (?-?). rtol 10:39, 13 June 2009 (UTC)


 * Got rid of the error message. Now it just does not pass on the info. rtol 12:34, 14 June 2009 (UTC)


 * One other way is to do it manually. rtol says that's not an option. It will work (and would be a small part of what's needed to create any person's page unless we get seriously mechanized). It's the fallback solution if no others work. I hope one of them does. But a semi-automatic option could be to use something like Set Order of Charlemagne or the older, potentially costly, Descent Charlemagne test in 10-generation lots instead of 42 generations. So we do generations 6 to 15 using that, and if it's with the latter it's only about 20 parser calls per page instead of 80-odd. Then when gen 6 is "complete", we adjust the template to get a little further down the tree. — Robin Patterson (Talk) 11:53, 15 June 2009 (UTC)


 * If we sort out how to do it automatically, we can do it for all generations. I now compute the generation number correctly, but still cannot assign it to Amaudru (?-?). rtol 05:57, 17 June 2009 (UTC)


 * Still don't know what I did wrong, but a radically different approach worked. If we now get Charlemagne's page right, then generation numbers will propagate. rtol 18:10, 18 June 2009 (UTC)

I was fiddling with it this morning but decided I would be doing some more radical things with multilingual so I removed the stuff necessary for the trial of the interlingua (multilingual) templates from that page. The article is way too slow for this purpose. It should now back to the form of all the other articles you are processing. Let me know if there is something still wrong with Charlemagne article. - <font color="#0A9DC2">~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x  19:08, 18 June 2009 (UTC)


 * CM's page is fine again.
 * Generation number as explicity property also makes it easier to show descendants per generation; 2^N - 1 < Ahnnumber < 2^(N+1) - 1 would rapidly get out of hand.
 * Next challenge: Coefficient of Inbreeding. rtol 20:01, 18 June 2009 (UTC)
 * Okey dokey. This is looking pretty cool.  - <font color="#0A9DC2">~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x   20:05, 18 June 2009 (UTC)

Dark Red instead of dark brown.
thank you! but the wikia lifestyle and the button stays brown Fred Bergman 06:24, 14 June 2009 (UTC)


 * Pardon? doesn't anything turn red?  What browser are you using? - <font color="#0A9DC2">~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x   06:34, 14 June 2009 (UTC)

Yes it is okay, but I would change also the leftside above Wikia Lifestyle colour and the right upside More button to the same colourFred Bergman 07:14, 14 June 2009 (UTC)
 * There are other logo files. More information on how to customize may be found at help wikia - <font color="#0A9DC2">~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x   03:24, 15 June 2009 (UTC)

More kids (redux)
May I add more kids to Set facts from info/family? Even one of your test cases, John Piper (1773-1851) has "lost" 4 children. Thurstan 08:09, 14 June 2009 (UTC)
 * I'm surprised that more shortcomings have not been noticed. I wrote this in a few hours and never went back to update it.


 * My thinking was that this scaffolding code would have an "exhaustive" flag that would access every attribute that could possibly have been set on an infopage and map it to some smw property. AutoWikiaBrowser would then stop by the article, save a temporary version with the exhaustive flag, then reload the article and replace the Info categories with the subst code at Set facts from info.  AWB isn't really necessary- this could be done manually fairly rapidly, but AWB allows you to do a few hundred at a sitting as opposed to fa few dozen.  That is an outline of the conversion process, and many (in particular simple use info templates like freds) can be done right away since I believe I am moving all the fields those simple ones are using.  Anyway, this conversion process allows human eyeballs on the conversion process and any contributor can do it.  Have you tried AWB yet?


 * Not having a stable design for properties at the time, this was premature. Now with a stable property schema, it is now possible, and somewhat forced at least in the case of children due to the fact that set descendants needs an exhaustive list.


 * So the short answer is go ahead and create an exhaustive version of the family subtemplate, but please do it conditionally on an exhaustive flag passed to the subtemplate. That way if the NewPP cost gets too high we can shut it back to the nonexhaustive list.  Putting ultra heavy cost code in every article slows the entire site down.  Let's be more sensitive to that.  I am the most guilty of anyone because I wrote the info templates in the first place, so I am not blaming anyone except myself for the situation of slow articles.


 * Also, feel free to expand beyond the family subtemplate and move more of the info fields over to smw cats if you would like to lend a hand. I'll review whatever you do.  It is fairly straightforward, and I think you can figure out the schema from the existing properties used in Form:Person.  Some info categories are ambiguous, eg :Baptism field was used to record both time and place.  Some of the dates in these fields use date templates so they could be extracted reliably using mw:Extension:StringFunctions, or by setting a marker in the date template, shoving the entire value into baptism locality, then using AWB to post process the locality value, and split the time off either into a date-y date-m partial date field or to store them in the full baptism date field if it is complete.  I haven't given it any in depth thought, but I prefer the more AWB reliant path since you can use regex and more complex conditionals useful to automatic processing.   Of course I am talking about the worst cases here, and most fields are not this challenging.  The less ambiguous fields like Wikipedia-es etc are straightforward.  Do what you feel like doing if you have the time.  Not fun to code this sort of thing, but there you are.  Life in the fast lane.  - <font color="#0A9DC2">~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x   17:08, 14 June 2009 (UTC)

Please see Forum:SMW Thurstan 03:37, 16 June 2009 (UTC)

Married oneself
William Waite (1832-?) is married to himself according to facts but not according to info ... rtol 09:29, 14 June 2009 (UTC)


 * That's because of errors in Susanna Harrington (1835-?)/info: both "Article" and "Full name" are wrong. Thurstan 09:54, 14 June 2009 (UTC)


 * Good man! Now fixed. rtol 11:20, 14 June 2009 (UTC)

Quick Query
I have finally started the process of converting my script to produce /info pages to use SMW instead, and I notice a discrepancy: Set birth set a property "birth subdivision1", while Set death, Set baptism and Set remains set properties "xxx state" at the corresponding point. I assume from the general discussion that "state" has been superceded by "subdivision1", so these templates need to be fixed. Thurstan 05:21, 15 June 2009 (UTC)


 * Set wedding1 uses "state" too. Thurstan 05:34, 15 June 2009 (UTC)
 * Yeah. Recent change, also there was a change of "had people" to the more general/inclusive "involved people".  Actually true for all non birth event templates- weddingX, migrationX, residenceX.  By the way, there is no need to be in any hurry to switch over right away. There is a slight advantage to SMW if you are able to extract higher detail information, like place divided by governmental unit, attendees and so on.  Otherwise, I don't see why using info pages as an intermediary poses any problems.


 * Just curious- this script of yours- what is the source data you are converting from? - <font color="#0A9DC2">~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x  08:51, 15 June 2009 (UTC)


 * I export GEDCOMs from PAF and import them into LifeLines (http://lifelines.sourceforge.net/), where I can run scripts. Thurstan 09:28, 15 June 2009 (UTC)
 * That's reasonable. These paf files seem to have more info than what is displayed on familysearch- eg links to ancestry.com, and the BDS refs. Presumably you will move over the sources references as you are now to the info pages.  I just don't think anyone is going to bother to post process the locations or person names.  That's why I want to import via AWB and normalize on the spot into to familypedia/wikipedia placenames, where the user can verify that the place is really the place the algorithm guesses, and the person article linked to is really the folks they have in mind.  Of course that is months off if ever, so your approach looks pretty good for the interim.

Okay, you have changed the "Set" templates. Now you have to change Showfacts person, because it is obvious using "state", not "subdivision1" (I would fix it except that I am still haivng trouble reading the SMW code). Thurstan 09:42, 15 June 2009 (UTC)
 * When did you write this? I did that. Actually, it was in a poorly named get-ex template, not showfacts person.- <font color="#0A9DC2">~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x   04:02, 16 June 2009 (UTC)


 * Okay, I see it working now (for example Thomas Edward Avery (1858-1921)). I think I was being fooled by the number of saves it took to show. Thurstan 04:12, 16 June 2009 (UTC)

Coparents
We're having trouble counting at Descendants of Charlemagne (couples), and the query depth prevents a solution with current properties. Would I break anything if I make a Property:Coparent-g1 (etc) a subproperty of Property:Coparent? rtol 07:35, 17 June 2009 (UTC)


 * Solved. Property:Partner already existed. rtol 15:12, 17 June 2009 (UTC)

Inbreeding
It would be better to replace Category:Married cousin with a Property:Married with value cousin. The test, however, is on co-parentage, not marriage. How would you call this property?

For the values, I would use sibling's child rather than nephew/niece and parent's sibling rather than aunt/uncle. rtol 07:42, 17 June 2009 (UTC)
 * I dunno. My request is you stay away from ordinal forms 2nd cousin, 3rd, etc.  It makes code exceptionally messy.  Maybe 2cousin, 3cousin?  But I don't envy you your task. It's tricky to be intuitive to novices, technically accurate, and easy to use for coding.  - <font color="#0A9DC2">~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x   08:10, 17 June 2009 (UTC)

Showfact v Get
Descendants::→;;3 works but Descendants::→;;3 does not rtol 15:40, 17 June 2009 (UTC)
 * "Showfact(s)" templates are for display and may have hidden formatting. They are not for general database retrieval tasks.   If you want a get, use the standard SMW database command (the ironically named) #show.  eg:   Certainly you or I could put that in a getfact template, but it would be a pretty trivial wrapper.  OTOH, maybe for novices we should have something like that.  Anyway, the problem you ran into is that showfact produces a more complex string that cannot be used for certain operations- in your case setting it as the value of a property.  There are embedded control strings that smw puts in there.  Just for fun, Do a #pos for "SMW" on a showfact string with an intro or outro that apparently does not have these values, and lo and behold- it will tell you SMW is indeed in there.  - <font color="#0A9DC2">~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x   17:25, 17 June 2009 (UTC)
 * Ta. The inbreeding test will be faster. rtol 18:45, 17 June 2009 (UTC)
 * Did you try Descendants::→;;3 ? It returns a database error! rtol 20:58, 17 June 2009 (UTC)
 * Autoprop for Married:Relative works, by the way, but I'll wait with the second cousin once removed until this thing is solved, because there are quite a few gets in Inbreeding test rtol 20:58, 17 June 2009 (UTC)
 * You are passing a pagename with square brackets, not a string. You should have used |link=none for what you are doing there.  I think I will make getfact's default link=none, (unlike SMW's default link=all) because most often folks using this sort of template will most often want to manipulate strings, right?  If that is not a safe assumption, let me know. - <font color="#0A9DC2">~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x   21:44, 17 June 2009 (UTC)

Robin, you MUST put a line break before documentation or it screws up the ads.
I see. Where should I have read about that? — Robin Patterson (Talk) 09:36, 21 June 2009 (UTC)
 * Nowhere that I know. I have noticed there are two common ways of screwing up ads:
 * unclosed div
 * no line break prior to some templates that have fancy formatting in them. eg: Documentation
 * 1 is not always difficult to fix- it's just a matter of counting divs and matching them. #1 is very likely the cause if the Genealogy logo is missing from the upper left corner.  Probably a good subject for Help:Why are the adverts wandering around the page?.  - <font color="#0A9DC2">~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x   15:52, 21 June 2009 (UTC)

Thank you. Copied "2" to Forum:Ads covering bottom of page content. I'll go and document the doc doc. — Robin Patterson (Talk) 05:33, 22 June 2009 (UTC)

Familypedia times
Where can I see back numbers? And who gets it? — Robin Patterson (Talk) 13:09, 23 June 2009 (UTC)
 * It's the #1 issue. There are no back issues, if that is what you mean.


 * Who gets it? It is like the Wikipedia signpost people can sign up for it and it is delivered to their user page.  We can send emails to everyone who requests it when new issues go out.  It would be possible to print them, and mail them to selected individuals or genealogy groups.  Might be fun as a once every 3 months kind of thing, or more often as interest arises.


 * I suggested you as editor because you know your way around the genealogy crowd. - <font color="#0A9DC2">~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x   15:10, 23 June 2009 (UTC)


 * Now that I see the forum item, I appreciate that you are talking about a new thing, not (for example) just a renamed Bundaberg (or Riccarton or whatever you call it) Report. I may add some thoughts to the forum. — Robin Patterson (Talk) 09:26, 24 June 2009 (UTC)

Property ifmarried-gN and Template Set families
I am confused about Property:ifmarried-g1 and Set families. As I read your comments, the forms use values "Yes/No" and the property takes values "true/false", so I would assume that the template has to translate. However, the template seems to be checking for the string "true", so I have been coding |ifmarried-g1=true.

So should the template be changed (" |ifmarried-g1=Yes " doesn't seem to work at present)? If so, I have another AWB run coming.

More generally, the property seems to be being treated as 2-valued, "true" or anything else. I think it should be 3-valued: "true", "false" and "dunno" (I am happy for this last to be coded by not setting the property at all), since I have examples of all three cases. Can the form cope with this? Thurstan 05:08, 25 June 2009 (UTC)
 * You are fine. I hoped I had hidden that little detail, and forgotten I had done so when I made a comment line in a file the other day. Anyway, SMW properties with type boolean have values true false.  Template parameters that are created by Semantic forms for properties with boolean parameters (default input a checkbox) return from the form setting the template parameter to Yes or No.  I noted this in my comments but sensing this would confuse people adjusted to the template to use a pulldown that returns true or false.  The only people who will notice this are those who create alternate forms for generating these properties.  When Declare or SMW :: syntax sets a boolean property to a value of Yes, the returned value after queries will be true, not Yes.  This can all be verified by manual test.  It is an unfortunate aberration of Semantic forms which I hope shall not survive into future versions.  For now, we will just have to live with these little quirky attributes.
 * As for the tristate proposal, usage dictates semantics and the current use of the value is to decide whether to use Husband/ Wife or to use the generic "partner/socio" term. This means "No", and unspecified have the identical effect.  The precise thing would have been for me to name functionality- "boolean: canIdisplayHusbandWife", but -just my opinion- what is good C.S. practice is actually bad practice in the field- working in the real world of rapidly evolving software.  If you have some other use for ifmarried, you could make it explicitly tri-state by making the type string, and specifying the allows value::'s.  - <font color="#0A9DC2">~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x   07:56, 25 June 2009 (UTC)

Yewenyi pages
I see you've started. Good. But if they are going to average more than one a minute, please get the bot to do them. — Robin Patterson (Talk) 02:55, 27 June 2009 (UTC)
 * At this point I am doing about 12 a day. What do you think- should I just let it go fully automatic on these?  It does remove utter nonsense like born on planet earth, and it does enhance the article (cumberland county -> cumberland county, new south wales but the conversion is not fully 100% yet.  Not sure that it could ever be given the nature of text processing.  - <font color="#0A9DC2">~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x   03:09, 27 June 2009 (UTC)

OK, a dozen a day is no problem. A hundred even. But two were less than 60 seconds apart, so I thought you were really warming up to something. Three thousand pages substantially improved by bot could be better use of time than a few dozen perfected by hand. The three thousand might need only a little handwork after bot work.

Are you talking to Thurstan about how to tackle Yewenyi articles? He's doing some. And he's the Oz placenames expert.

However, even technologically retarded people such as me can do handwork. We need you and a couple of mates to get the SMW and GEDCOM conversion working in Beta or better.

— Robin Patterson (Talk) 03:52, 27 June 2009 (UTC)
 * Couple mates? Where?  I thought I was the only bozo on this bus.  But if you can round up some more blokes, heck- that's fine with me.  As for goals- trust me. I am not disoriented. There is method to the madness.
 * Hey. My mom is technologically retarded and she does pretty well, thank you very much.  Actually, 12 may be small, but also 3000 is pretty puny.  It's a testbed.  I am learning about regex processing.  Upgrading Yewenyi is a byproduct. By the way, AWB is magic stuff- it makes everyone a superhero.  It is a little disorienting at first to get started, but that wears off.  Once you get used to it, it is really about as complicated as doing search and replace in a word processor once everything is settled in.  Also it has fully automatic cleanup things like typoscan that you don't have to know anything about.  You just run it on every article, or say just the recent edits and you just sit there and ok the particular changes, disallowing the particular words that it should not have changed.  It doesn't take much mental work, but heck, powered by a couple Canterbury Drafts, a person could easily cruise through a couple hundred pages cleaning them up.  Theoretically, I can create some quality control plug ins that do stuff like nuke all cap names, identify inconsistencies like reflexivity checks like what Dorran or Durran whatever his name was from WR was remarking on.  For instance person 1 has a partner person2 but person2 does not indicate person1 as partner.   The future is bright.  Global domination is imminent.  Just kidding.  Ok, maybe not.  I'm a yank.  I can't help talking like that.- <font color="#0A9DC2">~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x   04:18, 27 June 2009 (UTC)

CategorySelect
Rich Text feature does not leave you the option of turning off CategorySelect. I've just tried Preferences to check.

I have wondered whether the info page system would be able to work with the category in its own noinclude tags right at the end, where Category Select puts it and might be happy to leave it alone. Would you like me to test a couple with that?

— Robin Patterson (Talk) 05:22, 27 June 2009 (UTC)
 * So the objective is to leave rich text on, but have it not muck with info pages, right? Can you point me to an example page with an example of the damage that you'd like the templates to prevent?  I am somewhat familiar with info page arcanery, so maybe there is something that can be done to get it to work properly with the new editor.  - <font color="#0A9DC2">~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x   05:32, 27 June 2009 (UTC)

The damage (as described in my recent help desk item about broken things) is horrible and quite unacceptable; you don't need to look at it. You may find some by checking the last few days of what links to Showinfo siblings (which is a brilliant invention - wow; instant siblings (including himself, of course, as usual) for a bloke the minute I'd saved his mother's page) or you may find one that we hadn't tracked down if you can do a database search for an info page containing: !--> {{noinclude

Satisfactory pages are created using the modification suggested above. See http://genealogy.wikia.com/index.php?title=Ann_Dowie_(1820-1897)/info&action=edit and her son. But not yet tested whether CategorySelect leaves that untouched. At 2:24 am I don't know whether I want to.

— Robin Patterson (Talk) 14:25, 27 June 2009 (UTC)
 * You guys have been messing with this since March? I'm not faulting you at all, but on reviewing your complaints at Wikia help, I am surprised Kirkburn at least did not suggest something like {{T|category-Info pages}}.  That will deal with this difficulty just fine.  Note there was no technical sophistication required to solve this problem- it is as simple as templates come.  Something all of us could benefit from is more thorough application of the maxim to do things in a way your opponent (in this case the new editor code) would not anticipate.  -{{User:Phlox/Sig}} 19:28, 27 June 2009 (UTC)


 * You exaggerate again. {{T|category-Info pages}} is NOT "as simple as templates come". And we have not been messing with it since March. It didn't some back until this month when CategorySelect was inserted into the new text editor. — Robin Patterson (Talk) 03:47, 28 June 2009 (UTC)
 * I exagger... Well, geez- sorry for helping. And what is this "again" about?
 * I beg your pardon, but the template consists of one single category declaration. This is all it is, minus the documentation.  Here- I created a version minus the docs.  Read it Robin.  It is dirt simple: click here- still think this is not a simple template?.  {{User:Phlox/Sig}} 04:57, 28 June 2009 (UTC)
 * I did not say anything to justify your claim (another exaggeration) that I ever thought it was "not a simple template", but I did deny that "it is as simple as templates come". It is clearly near the simple end of the simplicity spectrum but it is at least one step up from the bottom. The simplest templates display plain text, not wikimarkup that does something else. — Robin Patterson (Talk) 06:08, 30 June 2009 (UTC)

You will have seen that my early-morning attempts were not successful. Believing Central Wikia turned out to be a bad idea again. Having NOWYSIWYG at the top of the template page did not stop the page from being subjected to Rich Text and therefore being affected by CategorySelect. Thank you for finding a solution. — Robin Patterson (Talk) 03:47, 28 June 2009 (UTC)
 * You are welcome. Really though, no technical sophistication was required.  The thing was fiddling with a category, so take the category away from it and it will stop its mischief.  I simply put the category in a template.  Your inquiry to wikia help was in march and that should have been the end of it then.  You clearly informed them precisely that the problem was an additional newline and they should have told you this sort of workaround.  Sorry, but wikia technical should have been able to come up with that 3 months ago.  I stand by my statement.  {{User:Phlox/Sig}} 04:55, 28 June 2009 (UTC)
 * OK, we have been messing with it on two occasions starting in March (with the inclusion of a brief query from you a few weeks in) and we thought by mid-April that those of us who were doing something about it had solved the problem as much as possible. We did not know it would rear its head again in June. I agree that Wikia staff are less than perfect. Thing that puzzles me is how they can create an extension that moves a category out of somewhere and dumps it at the end but cannot just dump it straight after the last character (which would be OK for us) but must create a newline first. Anyway, Thurstan seems to be doing the decent thing with the AWB on it. So you can do more of your specialist work. And soon we will be able to tell users that Rich Text is harmless again. — Robin Patterson (Talk) 06:08, 30 June 2009 (UTC)

I don't understand why it is important to quibble over how complicated the template is etc. Actually developers can't be faulted for inserting the newline. It is a case of- you are damned if you do and damned if you don't. It's possible to change wikitext appearance if a newline is NOT inserted prior to a noinclude. Normally the downside of including the newline is at worst and extra line at the very end of an article. Since this bug only affects transcluded pages, and since wysiwyg does not act on template namespace pages, we are down to the very rare case of transcluded Main namespace pages. So there decision affect in theory will break pages only in the rarest of circumstances. We had the misfortune of having large numbers of pages with such a circumstance. It will be very tough to get this thing to work on WP with a huge number of legacy pages that will break. That is why it is super important for wikia to get this out fast so that pages won't be created (since they won't work) if they do these things. Anyway, back to shoveling coal... -{{User:Phlox/Sig}} 17:28, 30 June 2009 (UTC)

SMW, Slow, Motion, Wrong?!
I want to bring under your attention the next problems at Genealogy:Statistics:

Thanks in advance, --Fred Bergman 19:46, 29 June 2009 (UTC)
 * Generation of Descendants information is Rtol's project. If there is something wrong with SMW features I have been working on, I can be of assistance, but that does not appear to be the case here.  The way you would do an error report query on the Sex field uses the "Not" operator.  There is an implicit AND between them. For instance:
 * Yields:
 * error(s) in encoding gender.
 * Note that at the time of this writing, there is only 1 error- one I deliberately created in article Catherine De Berkeley (Abt 1360-?) for the purpose of this illustration.
 * Note that at the time of this writing, there is only 1 error- one I deliberately created in article Catherine De Berkeley (Abt 1360-?) for the purpose of this illustration.


 * As far as the title of this note goes, SMW is far faster than info pages, and the data controls make it much more difficult to enter incorrect data. In info pages, we have locations in date fields and all sorts of messes to straighten out. So SMW is inherantly faster and more accurate. - 20:44, 29 June 2009 (UTC)


 * Thanks again, I see that I have to study SMW to be actual ! --Fred Bergman 07:13, 30 June 2009 (UTC)

template wpbio-nl
I tried to make a wpbio template for the dutch wikipedia but it was not a success. What did I wrong, can you improve it for me ? template wpbio-nl ''Wikipedia heeft mogelijk meer biographische informatie over deze persoon. Zoek op Wikipedia's artikel (als dat er zou zijn).'' How to do this for the germans ?

thanks in advance ! --Fred Bergman 07:10, 30 June 2009 (UTC)
 * Je was heel dicht bij de oplossing. Echter, dit zal worden vervangen door een SMW versie binnenkort. Regards,  08:28, 30 June 2009 (UTC)

ik wist niet dat je nederlands beheerste of gebruik je een vertaalmachine, maar dat lijkt mij uitgesloten, die zijn normaliter veel gebrekkiger ! helaas werkt de template nog niet zoals ik wil. hij zoekt eerst via de engelse wp, maar die kent de nederlandse artikelnaam niet, zie de nieuwe test Willem de Veroveraar (1027-1087)/nl --Fred Bergman 10:25, 30 June 2009 (UTC)
 * There you go. Comments on your test page.  - 16:04, 30 June 2009 (UTC)

templates wpbio-nl, de, fr
Wpbio-nl|Willem de Veroveraar

This is what I wanted !!! I saw now that you allready made a french version !

But if it will be automatic and easy ubder SMW, why should I do now anything ?



Biography


--Fred Bergman 19:40, 30 June 2009 (UTC)