User talk:Zoeannl/2018

ARCHIVES: 2015, 2018 

Welcome
Welcome

Hello, Zoeannl, and welcome to Wikisource! Thank you for. I hope you like the place and decide to stay. Here are a few good links for newcomers:
 * Help pages
 * Style guide
 * Inclusion policy
 * For Wikipedians

You may be interested in participating in Add the code active projects, PotM or CotW to your page for current wikisource projects.
 * Proofread of the Month
 * Community collaboration
 * Requested texts

You can put a brief description of your interests on your user page and contributions to another Wikimedia project, such as Wikipedia and Commons.

I hope you enjoy contributing to Wikisource, the library that is free for everyone to use! In discussions, please "sign" your comments using four tildes ( ~ ); this will automatically produce your IP address (or username if you're logged in) and the date. If you need help, ask me on my talk page, or ask your question here (click  [ edit] ) and place  before your question.

Again, welcome! Beeswaxcandle (talk) 06:01, 5 September 2014 (UTC)

A Key to Uncle Tom's Cabin
Zoe, I must say you are doing an incredible job. Moondyne (talk) 14:57, 15 January 2016 (UTC)


 * Thanks. I've asked for help with the Sidenotes (problematic pages) in the Scriptorium Help but had no response… Do you have opinion of what to do? I'd just as well convert them to references since the sidenote template transcludes so ugly. Cheers, Zoeannl (talk) 08:52, 16 January 2016 (UTC)


 * Sorry that I didn't see your Scriptorium/Help request. I agree that the sidenotes template is ugly, or at least a way apart from what that text looks like. I have done something similar to what you need here, which would be quite easy to implement.  However, what to do in a 2 column text rendered as a single column? — I think you'd want to place all the sidenotes on one side only, nominally left.  What do you think?  Moondyne (talk) 12:44, 16 January 2016 (UTC)


 * Yes it would make sense to put them all to the left. I happened to read today that float left causes text to wrap and have tried it on p 68. What do you think? I've used float left before, so for me, it has the comfort of the familiar. Shame it doesn’t offset like right does. Zoeannl (talk) 14:14, 16 January 2016 (UTC)


 * I think float left is more than adequate. Looks good. Moondyne (talk) 14:38, 16 January 2016 (UTC)


 * Done proofreading! A bit of a marathon… Transcluding to do. And a list of referred books to look at doing (on Discussion page). For tomorrow (which is 45 minutes away) Cheers, Zoeannl (talk) 10:19, 31 January 2016 (UTC)


 * Congratulations and a big thankyou. Due to other stuff happening, I doubt I will be able to make significant contribution towards verifying, but I will try!  Moondyne (talk) 10:42, 1 February 2016 (UTC)

Bots
If you're running bots, please make it clear to everyone at Index talk:The Hog.djvu. If you're not, my apologies for bringing this up. Outlier59 (talk) 05:13, 25 January 2016 (UTC)
 * Lol. I don't have a clue how to run a bot. Good job on "Evidence as to Man's Place in Nature". Cheers, Zoeannl (talk) 05:18, 25 January 2016 (UTC)

Origin of Vertebrates
The works I have copied from DP to WS were all ones I was post-processing myself. I have a program of my own which allowed me to work with a single master copy and generate both HTML and plain text for Gutenberg, and I extended this to produce wiki code at the same time. The works had all been proof-read at least twice in DP before I worked on them, and some, including O. of V., 3 times. I don't see any need for further proof-reading in WS!--Keith Edkins (talk) 12:02, 24 February 2016 (UTC)


 * I've post-processed too. Mistakes can still be there. But the main thing is that PG texts are just texts, we can do so much more on WS and it is valuable and aesthetically pleasing to be able to see the original print copy.
 * I hadn't noticed you had inserted the images into the PG text. Very nice. So there goes my main objection; I have to admit I just have an aversion to unsupported texts. Cheers, Zoeannl (talk) 23:28, 25 February 2016 (UTC)

TOCstyle
Hello. I note you seem to have caught some kind of mild addiction. (Happy to be the manufacturer of same.) After dilly-dallying about this far too long I've finally added support to TOCstyle for row-level styling. For example the gap leading "NOTES" (last line in Page:Various Forces of Matter.djvu/11) may now in principle be replaced with  (Not that this particular example really justifies such a change—I am merely using it as a simple demonstration.) AuFCL (talk) 01:15, 26 February 2016 (UTC)


 * (I had been composing this on your talk page) Hi, as you've noticed I have finally got the courage to try and get my head around TOCstyle. After working through the template documentation, I looked at What links here and took notes. I had trouble working out the width parameter, had to drag my husband in to look, he told me to add an "em". The only thing I’ve come across, not specified by your documentation is how to do an indented section; so is nested TOCstyle like this OK? It looks neat, and I did work out it counted as one line eventually. But I couldn't get it to work here, of which there is another 18 pages of TOC to do… Is this because nesting will be problematic? I am more than willing to accept it didn't work because I did it wrong. (pause, fiddle with Anatomy, Oh I have mail…)
 * So can I use rowstyle for a range of lines?


 * P.S.The first page of Anatomy has centered dots page#. Can we have a |model=c.?— Zoeannl (talk) 01:29, 26 February 2016 (UTC)


 * Many apologies for tardy response. I had a minor panic when I realised there was an error in the LUA code where range comparisons were being made alphabetically instead of numerically. (My mental state is probably best assessed by the fact I could not even get the correction summary right!) In case that remark makes no sense; it has impact upon your very question above, in that  affected rows 4,5,6,7,8,9 as intended, yet   previously affected nothing at all. This (I hope) has now been addressed so that the formal answer to "can I use rowstyle for a range of lines?" is that you can use   or   to affect a range of lines.   still affects the whole TOCstyle enclosure and if you happen to use   (where K falls inside the range [N-M]) this last will take precedence over the range version. I trust this makes at least some sense? As it turned out my mentor "got too busy" just at the point where I originally constructed  and as a result the documentation tended to be unreviewed. If I have put some things too obscurely and you can figure out a better way of expressing them please (oh please!) amend Module:TOCstyle/doc as you see fit, as that is where the basic commentary lives. And of course if it makes no sense at all please ask: either I hope I will be able to explain, or in any case you may well have uncovered a bug which needs to be addressed anyway.  With regards Anatomy's centred dots, something akin to  ought to already cover your requirement, viz:  AuFCL (talk) 04:01, 26 February 2016 (UTC)
 * Just back from the afternoon school run myself. Cool. I've had a lot of fun playing with leaders! But it is the text that is centered with dots to the right with a right-aligned page number so like a model c with dots and then pp. Cheers, — Zoeannl (talk) 04:17, 26 February 2016 (UTC)
 * Oops. I think I misunderstood before. I take it you were referring to the second column, which can be "bent" to fit the existing framework, unless you consider this to be too dodgy: which yields:Now if you are wondering where the constants 84px, 90px and 44px are coming from, they are estimates of half of the display width of "The Primitive Segments", "Separation of the Embryo" and "The Yolk-sac" respectively. Half? Well the required offset is from the 50% centre-line&hellip; Is this the behaviour you sought? AuFCL (talk) 04:53, 26 February 2016 (UTC)
 * That'll do the trick. How do you estimate the px width? I sort of know how wide an em is. — Zoeannl (talk) 05:00, 26 February 2016 (UTC)
 * Oh good enough! That is in fact what I did for a first estimate, and then ended up over-egging the example. (In point of detail I use Firefox a lot and there is a so-called "Box Model" utility hangs off "Web Developer" [sounding overly grand already!] which shows the dimensions occupied by a given HTML element. In further point of detail only in px—which can be rather a pest in of itself&hellip;) AuFCL (talk) 05:11, 26 February 2016 (UTC)


 * A query: Is rowRpageribbon like enclosing a line in ? Zoeannl (talk) 06:31, 27 February 2016 (UTC)
 * Yes, pretty much. Do it this way if you prefer. Just be careful about adding stray blank lines if you do: a couple of the more obscure models (the cross-page ones like  and  ) proved to be a bit fragile in circumstances where a leading newline resulted in mediawiki inserting a &lt;p&gt; unexpectedly. AuFCL (talk) 07:12, 27 February 2016 (UTC)
 * Example—Page:Anatomy of the Human Body(Lewis-1918).djvu/15 Tarsus, row21 is a column continuing header that shouldn't transclude. Have I got it right?Zoeannl (talk) 05:44, 29 February 2016 (UTC)
 * Looks good to me. AuFCL (talk) 06:56, 29 February 2016 (UTC)

TOCstyle log

 * Anatomy 18 pages of TOC super fast. As above, centered description with dots and page numbers—solution not working for long descriptions.
 * Works Translated by William Whiston Easy. But the descriptions are not lining up, influenced by crooked Chapter numbers. Zoeannl (talk) 05:46, 29 February 2016 (UTC)
 * Leibniz Discourse on Metaphysics super easy. I use Table style as reference for Natural language code. Shorthand doesn't work. Zoeannl (talk) 06:06, 29 February 2016 (UTC)
 * History of the German people
 * Explorers and Travellers Contents, Illustrations Illustrations cont.
 * Benjamin Franklin italics, long s
 * Index:Principles of Political Economy Vol 1.djvu Multipages.


 * As a gross rule, may I suggest usage of model  (with adjunct  ) instead of   to handle long lines with hanging-indents? Although not particularly pretty (in wikitext terms) substituting  for spaces works better and is independent of whether proportional or fixed fonts are chosen. This is not perfect but works O.K. so long as the chosen   is slightly greater than the longest expected (here) Roman numeral expansion expected. AuFCL (talk) 07:26, 29 February 2016 (UTC)


 * I missed your comment regarding use of Table style on my earlier reading. To be strict that template was designed with table formatting in mind, and is accepting modifications to a DIVision context (in point of detail the most basic internal element is:  ; and the   variants are similarly modifying list elements within an ordered list  structure. The basic element being built upon in the latter case is  . So as you see ts is not a terribly good choice both from this perspective and from the fact that the template constructs a full   specification which is incompatible with both the   and quotation marks already present.
 * Taking all of this on board it is however technically feasible to get access to suitable shorthand expressions via 's "helper function" table style/parse, so that things like —will actually work—should you feel brave enough to so try. As you see here:


 * —just not very conveniently, due to only accepting a single parameter value each time. AuFCL (talk) 09:56, 29 February 2016 (UTC)
 * So TOCstyle isn't table formatting, good to know. Maybe someday I will get what it is. Your example is of a TOC in a table? My question was a musing of: instead of |style=font-variant:small-caps; could we have |style=sc?Zoeannl (talk) 22:11, 29 February 2016 (UTC)
 * Oh good grief! (This not aimed at you.) Variants of TOCs seem endless and any attempt to contain them in a "standard" always finds a compelling case which "leaks outside the specification." Which I guess in a nutshell is what this is all about. After a great deal of angst about this, George Orwell III came up with an architecture which—after mangling through misunderstandings and compromises—sort of fits:


 * I hope this diagram also makes it clear why options like,   and   must appear in the header section of   and   cases. All of these options are effectively "chopped off" pending reassembly at final transclusion where the jigsaw is fitted together again.


 * So all universal settings on the starting page go into the header of subsequent continuing or completing pages? |leaderspacing=2em didn’t work from the header.— Zoeannl (talk) 01:29, 1 March 2016 (UTC)
 * "Universal" is kind of tricky once the fact is grasped that said "universe" has not been defined. Your list is O.K. except for "depth" which applies at the row level (all actual tables are independent so each has to be informed individually.) You appear to have already isolated "leaderspacing" correctly as being in the same category. AuFCL (talk) 01:54, 1 March 2016 (UTC)


 * So getting back to your earlier point: Yes, there is in fact a table created for each and every row. However as each table is independent that means that matching column widths is quite a task. They cannot be amalgamated into a single table because that runs counter to the never-quite-crystallised mobile specification—which is also about the point where my understanding dissolves into total static so please do not ask me about that!
 * My involvement was only as the sucker who got enthused enough to code the damned prototype. Which is all this really is at this stage. I am certainly not pretending it couldn't be done better, or that I did not half wish somebody else would have a go.
 * I shall put your style=short-cut idea aside for the moment. The idea is good but some means of reliably (programmatically) expanding shortcuts without simultaneously damaging genuine CSS fragments needs more consideration. Please remind me as necessary. AuFCL (talk) 00:07, 1 March 2016 (UTC)
 * Did I miss a hanging indent? I did. Twice. I'm fine with using Hn.P. But there is no nCHn.P to match: the description is also hanging. I suppose it is terribly naive of me to hope for a generic aCbDc?P model? (Joking.)


 * Glad you were joking. Of course nCHn.P is impossible. Needs to be mCHn.pP at least so that the documentation can refer to m,n unambiguously, and in any case no user request should not be generalised in an unasked fashion, should it? AuFCL (talk) 00:07, 1 March 2016 (UTC)


 * span is really ugly. I hope I never see a need for it again. Is the width for the chapter column adjustable? Zoeannl (talk) 09:14, 29 February 2016 (UTC)


 * I (thought) I did warn you. Apologies if I didn't. At present the Chapter columns is pretty much assumed to fit within 5em. This decision has more to do with proving the concept than necessarily being a good choice. Not tonight; but I'll put some thought into adding some kind of chapter column width. Any thoughts as to a sensible keyword? Is  too much to type? AuFCL (talk) 09:56, 29 February 2016 (UTC)


 * Chapter-width is fine. If we get a default that works for most TOCs then the technically able can adjust as they wish. My main hope is to enable technically challenged people to ease into using wikis. So Wikisource can be the nursery for Wikipedia; with the content provided, it's a lot easier for people to gain confidence working on a wiki at WS. And we're all nice here, cf. WP, of course. So a template that does as much of the thinking for the proofreader is the aim. I am so far appalled at the diversity of TOCs I have encountered. I have vague thoughts on what should be on a good help page and would include a page/tab "Examples and Exemplars" with a list of links to well-done examples. It took me 12 months and a personal tutorial with Beeswaxcandle to find template pages and Whatlinkshere. And I was looking. Most people would have given up, I think this is behind the dearth of proofreaders here. So I want to build help as a pathway from proofreading (which Distributed Proofreaders does so well) to wikified. Perhaps there is a way to do tutorials with a set piece of unproofread text where the edited (annotated) version is saved as/on a User page and can be compared with the "Correctly" proofread page? Then people could practice on "easy" examples. The TOC is critical as it is challenging formatting and in most books (cf. images, tables, references) so it provides the best opportunity from "just" proofreading to real wiki work. But first I have to figure out how to use it myself. And practice, lots of practice.Zoeannl (talk) 22:11, 29 February 2016 (UTC)
 * P.S. I don't need warning about ugly coding stuff. It's what I expect. I really appreciate your template making TOC "possible" and accessible. Really. Zoeannl (talk) 22:11, 29 February 2016 (UTC)
 * Thank you. I'll try to keep the complaining under control. Here is a trial of the new options:


 * I hope this gives you some usable alternatives. AuFCL (talk) 00:07, 1 March 2016 (UTC)


 * Cool. What are the defaults? Zoeannl (talk) 06:55, 1 March 2016 (UTC)
 * Precisely as detailed in TOCstyle:
 * depth: On models which make use of this, provides a user-specifiable hanging-indent factor. Default is 5em.
 * chapter-width: On models which make use of this, provides a user-specifiable chapter width. Default is 5em.
 * page-width: On models which make use of this, provides a user-specifiable page width. Default is 2em.
 * O.K.? AuFCL (talk) 07:02, 1 March 2016 (UTC)
 * Got it. Zoeannl (talk) 07:06, 1 March 2016 (UTC)
 * Are chapter-width and page-width in or out of the header for continuing pages? — Zoeannl (talk) 07:52, 6 March 2016 (UTC)
 * Out, because they affect row formatting. Hmm. may have to start compiling these relationships&hellip; (If the documentation is ever unclear to you, put the parameter in the header and preview the result: if it does not seem to have had an effect then transfer into the main body and repeat. That should be definitive in most cases?) AuFCL (talk) 08:05, 6 March 2016 (UTC)
 * Is it possible to set depth and chapter-width for a row?: Here the last entry would fit better with different settings (using mCHn.pP: C a blank field, shorter m, longer n?) — Zoeannl (talk) 09:59, 6 March 2016 (UTC)
 * Not as the system currently stands. Might be easiest in the short-term to make two separate TOCstyles? AuFCL (talk) 10:44, 6 March 2016 (UTC)


 * This page is interesting (as in the curse) with the description overhanging the page number. Is it replicable? Zoeannl (talk) 02:42, 5 March 2016 (UTC)
 * Not as things stand at present. Thinking back I seem to recall this case getting pushed aside as "too simple to bother with initially"&hellip; and then was forgotten! It will require the creation of a new model type as (in table terms) the dot-leader must "live" in the same cell as does the page number (for example in D.P the description and leader share a cell but page stands alone in its own one.) Do you need this in a hurry? AuFCL (talk) 07:51, 5 March 2016 (UTC)
 * Pardon the delay—I was too tired last night to trust myself making changes. I have added a new model (CD.uP) (if you don't like the name now is the time to change it!) intended to be read as same as CD.P-with-page undercut. I have taken the liberty of reformatting Page:Historic Girls.djvu/245 as an example of use but deliberately left the page un-validated in case you don't approve of the result. AuFCL (talk) 02:21, 6 March 2016 (UTC)


 * I have also come across an hyphenated word across pages. From your patient explanation, I gather hws won't work with TOC style because the 2nd page will start a new table and we should manually join the word, as I do for references with words hyphenated across pages. Unless there is some trick to doing this, I haven't investigated really, I just haven't seen any alternative in action. With a reference I would put a instead of an hwe on the second page with an explanation "united on previous page" or something. What would be an appropriate way to leave a note with TOCstyle? A note in the header? Using  ?


 * No, I have over-generalised, I think. Does your explanation covers what happens across pages if the description, D is split across pages? Zoeannl (talk) 02:42, 5 March 2016 (UTC)
 * I think it was me that did the over-generalising. In most models the above discussion is true, however models like 2H3P/s create a "split" cell which can be recombined with its continuation model 2H3P/e, and hws/hwe should work fine across such structures. Though it does not contain hyphenation a split cell is at the bottom of Page:Hakluytus Posthumus or Purchas His Pilgrimes Volume 12.djvu/12 continuing onto the following page, and the results of reassembly may be seen here: Hakluytus_Posthumus_or_Purchas_His_Pilgrimes/Volume_12 AuFCL (talk) 07:51, 5 March 2016 (UTC)


 * There wasn’t any rush. Just, as you can see, Kathleen had validated all the other pages and this was the last one. Which she has already done. Other than the heading that wasn't larger (it’s an optical illusion from being bold.) I have no problems with your reformatting—it makes sense to have it as one TOC. I do have trouble reading the Comparison between our edits though: what is with the highlighting where as far as I can see there isn’t any change? Flower Painting for instance. Did you remove the extra spaces manually or with some script or bot? Beeswaxcondle said he has some scripts on his sidebar that he clicks and they do their stuff; they’re on my to do as they sound very nifty.


 * Do other models have the /s /e option? I had noticed the 2H3P versions before but had forgotten them. Obvious answer to the problem no it’s pointed out.— Zoeannl (talk) 06:15, 6 March 2016 (UTC)


 * Thanks for picking up the over-enthusiastic "ART HAND-BOOKS." heading. I did have mild doubts and should have realised the precedent set earlier. Wow, checking the change display certainly is confusing. I think the main point of difference was your technique was bolding the "Chapter" Roman numerals in one block but not the other; and I opted to bold none of them, just the descriptive text. Amend as you see fit—which was why I was less than amused by friend K.W. blanket validating. As it turned out I manually removed the spaces more or less through habit. I do however have a script helper which seems to be too complicated for normal consumption. However you might have a look at installing Pathoschild's TemplateScript which appears to be very popular with the locals and includes this very function. As for other /s,/e models there is CD.P/s paired with CD.P/e. I went through a phase of only adding models as cases came up which the prior set could not handle. This concept of split entries doesn't really occur all that frequently. As things stand each model is simply a unique label ordering a particular row structure to be built. Perhaps one day it might be handled in a more mechanical fashion but for now it isn't. (Something else to add to your short-cuts idea?) AuFCL (talk) 07:51, 6 March 2016 (UTC)


 * Index example: Is there a way to get TOCstyle to play nicely with di?— Zoeannl (talk) 10:03, 6 March 2016 (UTC)
 * Short answer: not a hope. Long answer Maaayyyyyybbbeeee? (see page: the solution (if you can call it that!) is to remember the drop-capital "lives outside" of the two lines; which I have quite horribly joined up and floated beside the capital. Unfortunately to get the page numbers to line up one has to estimate the width of the drop-capital and then subtract it from the 100% width allocated by the outermost compact=yes TOCstyle.... Worse yet the initial guess has to be made in terms of the fact di increases the font-size and adds... I am getting seasick just describing this stuff. Are you sure it is worth the effort? AuFCL (talk) 10:44, 6 March 2016 (UTC)
 * I don’t mind it underlined with dots. Someone might rather convert it to a straight capital but it is extremely trivial. Cheers Zoeannl (talk) 23:40, 6 March 2016 (UTC)
 * Pardon? Is it being underlined for you? My browser (firefox 44.0.2 currently) shows the drop-capitals unadorned. If that is not the case for you would it be possible to let me know your browser version and, ideally, a screen capture, please? AuFCL (talk) 01:55, 7 March 2016 (UTC)
 * As per the previous page which is how a mere proofreader would leave it. The alternative is to state that we don't di at all with TOCstyle and leave a plain capital. Quite reasonable I think. The di C on the example isn't working for me-due to above complications?Zoeannl (talk) 02:47, 7 March 2016 (UTC)
 * Thank you. I understand now. Although as the formatting does not remotely match the scan would this be considered adequate proofreading? This is entering the realm of: should the text proofing be fully divorced from the formatting?—argument. PGDP diverges from WS practice here, and perhaps has made the wiser choice? Regarding the "di C on the example isn't working," how about now? I thought of a "looser" way of floating the components which might work a little more universally. AuFCL (talk) 03:35, 7 March 2016 (UTC)
 * Big question. I think it is in WS's interest to be very gentle with "mere" proofreaders and not overwhelm them with complications but being able to be faithful to the original page is a one of the major pluses for WS. [For "Quite reasonable", above, please read "As much as I can handle right now". Your solution is much better.] I'm thinking that WS is a great place to learn wiki-ing and that it could provide a pathway from "mere" proofreading to competent wiki-er. DP has stages of proofreading: so for someone on a P1 licence, a plain Di in a TOCstyle would be considered adequate but a P2 would be expected to notice it wasn’t true to scan and to investigate the template page for a solution and go to Scriptorium Help if not found there. I would like to see a list of books kept for beginners to proofread—books without references, tables or images. But of course they would all have TOCs so an easy to master template would be great, but TOCs do seem to have a lot of complications… Consider me your canary! I’ll sing (or squawk) if the template gets too complicated! I think there is still a bit of trialling to do. I tried a scenario of using mCHn.pP as a default on my user page. Quite pleased with myself that I could make it do what I wanted but I don't know that it isn't too intimidating. I shall carry on proofreading, Cheers, Zoeannl (talk) 10:20, 9 March 2016 (UTC)


 * Another variation here with a hanging indented description with underhanging pg number. Is the underhanging page number something that could be added to mCHn.pP? Considering above… Zoeannl (talk) 10:24, 9 March 2016 (UTC)
 * Please pardon once more my tardiness. I have added both a Hn.upP and a mCHn.upP model (the first applied to /254 per your mention; all size controls are at their default values). Was that more what you were looking for? I have not even written any documentation yet. I am afraid that will have to wait for a new day. AuFCL (talk) 10:06, 11 March 2016 (UTC)

User Guide
Not sure where this will fit but something might be worthwhile including in your draft guide:

Whenever a page ends in a quoted, hyphenated word or phrase the approach often utilised of ending with, e.g.: followed on the next page, e.g.: results after transclusion into the final text in the rather awkward result: due to the initial quote mark being contributed from the first page, a space contributed by the transcluding &lt;pages&gt; tag, and finally the word contributed from the content of the appropriate parameter of the hyphenated word end template on the second page.

May I commend the following as more correct usage? On the first page, e.g.: followed on the next page, e.g.: resulting after transclusion into the final text:

In case you did not recognise the above it is based upon Page:Symonds - A Problem in Modern Ethics.djvu/56 and the subsequent page. I have been encountering this situation frequently recently and thought it perhaps worthy of bringing to your attention. Pardon if not of interest. AuFCL (talk) 17:17, 14 March 2016 (UTC)
 * That's really good to know. I was going to include the em-dash across pages as well. Are there any other similar scenarios? Zoeannl (talk) 00:42, 16 March 2016 (UTC)
 * Basically anything which ends up butted just in front of hws—certainly any kind of dash, quote (for sake of argument do you want to mention the &amp;lsquo;-and-variants? Sleeping dogs?) or mathematical operation. Oh, and braces, brackets and parentheses (‹,«-guillemets?) Things which are immediately adjacent to hwe are generally of lesser problem—maybe due to the fact that people are more conscious of the adjacency of the second parameter which is normally the full word to be rendered under transclusion; and also because the mechanism of expanding does not result in adding spaces. That is basically my thought in a nutshell. Apologies I could not think of a less long-winded means of explaining above—maybe you should put in a bid for a pay rise? AuFCL (talk) 07:34, 16 March 2016 (UTC)


 * My additional comment is that split word joined by the template, appears in the main namespace as if the whole word is part of page 2. — Ineuw talk 18:10, 18 March 2016 (UTC)


 * In further passing I stumbled across this paired gem. It must be some kind of sacrifice to the god of cruelty to templates perhaps? Page:Poems,_Volume_2,_Coates,_1916.djvu/281 and Page:Poems,_Volume_2,_Coates,_1916.djvu/282. Please, oh please, don't recommend anything like this usage in your `Guide. AuFCL (talk) 11:14, 19 March 2016 (UTC)
 * Even better would be to offer an alt solution... or would that involve a complete reformatting of the Index of Titles? Londonjackbooks (talk) 11:57, 19 March 2016 (UTC)
 * Please don't worry, I am not having a go at you or this solution. In fact I am somewhat agog with horrified admiration for the technical success whilst simultaneously disregarding the "spirit" of the templates used (and that is an argument which has been had and lost by me elsewhere. Not with you though. I'm not going over that old ground again.) It is an exemplar of "good enough for government work," which is the main reason I was drawing the attention of our very own self-appointed "works process manual" compiler. AuFCL (talk) 12:15, 19 March 2016 (UTC)
 * Unconcerned. Merely open to suggestions. Londonjackbooks (talk) 12:19, 19 March 2016 (UTC)
 * Besides which, I did offer an improvement: if you were going to use this solution at least make it work in both Page: and transclusion; i.e. the  recommendation. AuFCL (talk) 00:05, 20 March 2016 (UTC)
 * You may have misread my tone; I may be misreading yours. I was unaware of the  option back in 2011. You said you don't recommend the usage above; I assumed you meant hws use in general (in that particular instance), and really was genuinely seeking another option. RE: "SNB": has a familiar ring. Londonjackbooks (talk) 01:26, 20 March 2016 (UTC)
 * To be meticulously fair, one P.T. Aufrette introduced  about a month after your effort. And I apologise if "tone" was coming across. I was really delaying even seriously looking at the page formatting until Ineuw and Zoeannl had a chance to witness and/or make their own comments. There are really two levels of conversation going on here: between you and I regarding a better approach (and in all honesty there may not even be one!) and between Z., I., et al as to how to lay down "best practice" (gag!) for advising newcomer editors. So everyone has to carefully maintain that "innocence of mind" which, hoary old reprobates all we no doubt in reality are, is not quite "truth" either. To specifically address your concern: no I don't really recommend the usage of a running block center/s enclosing &lt;poem&gt; enclosing sc enclosing hws for the purposes of plastering over the results of butting together the two pages. There is so much fundamental "wrong" going on there, not least of which much the same effect reduces to careful use of &lt;noinclude&gt;/&lt;includeonly&gt;. And I repeat I blame you for none of this: this is one of those cases where a chain of justifiable small deviations from legitimacy has resulted in a kind of Frankenstein's monster of an overall result (For Ineuw: is "szalamitaktika" appropriate?).  Poor Zoeannl, having to host all this! Please hang in: I truly hope it may one day may actually become more productive and less circus-like? AuFCL (talk) 01:56, 20 March 2016 (UTC)
 * I am amused. As an aside I have been having a similar conversation (which I sort of kept up with, technically) with Djr13 about (end of book) indexes and plainlist and making templates fit for purpose for WS. He mentioned italics: Why don’t we have an italics template that ignores hard returns? And then there is poetry and next month is poetry PotM. And I take a deep breath and do some sane proofreading and try to figure out where to focus my efforts… — Zoeannl (talk) 02:32, 20 March 2016 (UTC)
 * If I have learned (and may be permitted to pass on) two lessons in the wikisource world: when Londonjackbooks lays down the law with respects to poetry, listen! because she is usually correct. And in similar vein Djr13 is rarely wrong when pontificating upon accessibility issues. I do my best but will always defer to these two on those areas. All of us have certain skills and deficiencies but the delightful side of that truth is each one can become experts in a sufficiently well-defined niche area. P.S. Was italic block what was desired? AuFCL (talk) 03:04, 20 March 2016 (UTC)
 * Had to think and check. So not usually, italic block only works for whole paragraphs, it forces a hard return at beginning and end.Zoeannl (talk) 03:25, 25 March 2016 (UTC)
 * Re Coates: As a mere proofreader I don't see the point of the block center. Would plainlist require the same sort of treatment (he) for the last listing? — Zoeannl (talk) 02:32, 20 March 2016 (UTC)
 * Ah well, in for a penny&hellip;: shall I explore the true horror that that represents, since I raised the concept of Frankensteinian creations earlier? This template wraps a (presumed unordered list, as it does little useful to any other construct bar indent control) and then applies CSS to the result of the form:
 * Umm. What? It strips the bullets back off that would otherwise be present as generated by the leading-*'s ? (Mind you to be fair  internally pulls exactly the same sleight-of-hand.) So all-in-all I accept Djr13's point about this place being a laughing-stock on so many levels but then again so is this rather a good joke as well. AuFCL (talk) 03:36, 20 March 2016 (UTC)
 * So there isn't a template that just takes a list and produces—a list? That seems awfully silly.Zoeannl (talk) 03:25, 25 March 2016 (UTC)
 * Maybe I have missed the point somewhat but don't the two outstanding issues you pose have the same answer? Why have a special template when, for italics, there already exists &lt;i&gt;; and for lists of all persuasions, &lt;ul&gt;, &lt;ol&gt;, or &lt;dl&gt; (or even at a pinch,   or   forms)? AuFCL (talk) 04:18, 25 March 2016 (UTC)

Religio Medici
Hi. After a quick glance at the page histories of Index:The Harvard Classics Vol. 3.djvu it seems that you have completed the section[s] The Harvard Classics Vol. 3/Religio Medici. I haven't added those missing pages as I didn't want to rob you of that pleasure. CYGNIS INSIGNIS 18:22, 1 April 2016 (UTC)
 * Hi back. What missing pages? Cheers Zoeannl (talk) 06:23, 2 April 2016 (UTC)
 * Pages from 265 on of the index above, parts 1 and 2, everything but the introduction. CYGNIS INSIGNIS 06:51, 2 April 2016 (UTC)
 * Ah the transclusion. I hadn’t noticed. Thanks, done. Zoeannl (talk) 09:47, 2 April 2016 (UTC)

Vol 56 done?
Shall I move on to vol 57? Mark 56 as proofread (though there are a missing symbol and image to be unproblemed)? I have been known to be in the mood for Ads so can return to them when it strikes. Cheers, — Zoeannl (talk) 11:33, 24 April 2016 (UTC)
 * Regarding your "missing symbol" sub-issue, is it too naughty to deliberately misinterpret the phrase "double plus sign in a circle" to mean  (which looks like $$\oplus\!\!\!\oplus$$—try not to go cross-eyed looking at it)? In other words "double; plus-sign-in-a-circle" vs "double-plus-sign; in a circle." Some other possibilities are: *  —looks like:    ; or  —looks like:  (frankly awful on my system: though in theory ought to be correct Unicode for double-plus-within-enclosing-circle.) AuFCL (talk) 02:57, 25 April 2016 (UTC)
 * One last try (yes it is mad):  looks like: $$\bigcirc\!\!\!\!\!\!\!\!\!+\!\!\!\!\!\!+$$ which is pretty near acceptable here. AuFCL (talk) 03:12, 25 April 2016 (UTC)
 * These all look awful on my chromebook with Chrome except for * which is good. Should we look at how it presents on different browsers, or scan an image or …? — Zoeannl (talk) 09:46, 25 April 2016 (UTC)
 * Ironically though that one looks fairly O.K. under Firefox here; under Chromium it is barely distinguishable from the single plus-in-a-circle. On impulse I checked Commons: images and am sure somebody out there is teasing with Symbol_full_support_vote.PNG. You might be more fortunate searching than was I. AuFCL (talk) 10:59, 25 April 2016 (UTC)

&lt;math&gt; on Page:Somerville Mechanism of the heavens.djvu/87
Hello. Just a quick note which I hope might save you some effort in future: In practice I have found there is no material benefit in adding  or \right to the innermost parentheses of an expression. For example in your original coding on the above page you had: —which at least to my eyes and browser is pretty much indistinguishable from: —now on the other hand outer braces, brackets and parentheses most definitely do look better with the, \right directives: —don't they? —Happy experimentation! AuFCL (talk) 06:00, 26 April 2016 (UTC)

Partial vs. Delta
I just had a double-take moment regarding this same page, Page:Somerville Mechanism of the heavens.djvu/87 and thought I'd better check before "correcting" something you did intentionally (perhaps your browser makes no distinction?) Various formulæ on this page use partial(∂-$$\partial$$-&amp;part;) whereas I believe delta(δ-$$\delta$$-&amp;delta;) is the correct symbol in this context. The icing on the cake is two adjacent formulæ (third- and second- last on page) use alternate symbols, even though the same symbol is shown in the scan. I shall hold off further validation pending your clarifying this. AuFCL (talk) 07:25, 26 April 2016 (UTC)


 * I started using the delta from the maths symbol menu and then realised, as you have, that it doesn't match the scan. I have been using the delta from the greek menu since and corrected some of the previous pages with find and replace—except when bleary-eyed and/or not paying attention, I have cut and pasted formula uncorrected. All up a bit of a mess, if you can run through with a bot or something that would be great. Otherwise I do intend to fix; I'm a bit formula-ed out right now. How to change the menus? The minus sign on the menu isn't -; maybe an en-dash? Cheers, Zoe — Zoeannl (talk) 11:08, 27 April 2016 (UTC)


 * Ah. I was looking on the wrong menu (Special Characters.) Presumably you meant the "Math & logic" menu on the "other" (technically CharInsert gadget—but just how somebody who does not already know that is to learn it as the d**mned thing never shows its name!?) Yes, you are right that menu is rubbish: loop-integration, nabla, partial-differential, upper-case Delta: where is the logic? And the one character you do actually want at this time is lower-case delta which is not even present (though as you observed is under the Greek selection—after climbing through all those accented characters. In short sympathise with the tired eyes argument—suffer from same myself, which is why I'm not offering to review tonight, but will try to do so tomorrow perhaps? Returning to the CharInsert menu in theory the "User" section is customisable (as in fact you have already done so: in User:Zoeannl/common.js the lines consisting of:
 * —if working correctly ought to be reflected as the "User" charinsert menu selections. If this is working my recommendation would be to modify the set here build up a set to suit yourself. AuFCL (talk) 11:46, 27 April 2016 (UTC)


 * That's Inuew's User menu he added for me to help with Pop. Science proofing. It does do for almost everything. I was just feeling intrepid and having a go at maths inspired by Mrs. Somerville. This sort of thing (crap menus) discourages beginners… — Zoeannl (talk) 11:55, 27 April 2016 (UTC)


 * I understand. With regards your last "discourages beginners…" I could not agree more. However I have no clear ideas on how to better arrange any of these "pick and choose" special character selections: I am aware of more than a couple of attempts to rationalise them which have basically stalled due to intransigence/disinterest so my instincts are to just "do not go there." Everyone I know who takes this sort of thing seriously appears to have a personal solution which bypasses the mediawiki gadgets/utilities anyway to a greater or lesser extent (I certainly do!) AuFCL (talk) 18:05, 27 April 2016 (UTC)

Terence
There is no need to specify works "translated into English". On the English Wikisource, we only list English works anyway. But you need to go back through the list you added, since some of the additions are not in English, but in Latin, and some of the works aren't works by Terence. --EncycloPetey (talk) 15:02, 3 May 2016 (UTC)

Mediaeval Mind
Hi Zoë, I've been out of action for a couple of weeks and have come back to see you're charging through Mediaeval Mind. I hadn't written the style guidance for this because Tannertsf and I were doing the work between us and were thus keeping consistent. I've put together a few notes on the Volume 2 talk so that we can be consistent with the way we did the first 17 chapters. Could you please switch to following those notes? Cheers, Beeswaxcandle (talk) 09:21, 15 May 2016 (UTC)
 * Sure. Can you give me a page to refer to for the blockquotes? Re titles and authors, just the English books? Cheers Zoeannl (talk) 10:47, 15 May 2016 (UTC)
 * See Page:The Mediaeval Mind Vol 1.djvu/446 for a simple example, and Page:The Mediaeval Mind Vol 1.djvu/447 ff for a more complex one. For titles, anything in English or that is likely to be here in translation in the next x years. For authors, anyone who would reasonably have an author page here. Beeswaxcandle (talk) 04:46, 16 May 2016 (UTC)

Page:U.S. Government Printing Office Style Manual 2008.djvu/238
Don't forget that /s /e type template are paired :) ShakespeareFan00 (talk) 08:41, 28 June 2016 (UTC)


 * This was on my "later" list: Page:U.S. Government Printing Office Style Manual 2008.djvu/23? This continues on /25, there is an image on p 24. So I presume it will be transcribed 23,25,24? Cheers, — Zoeannl (talk) 08:54, 28 June 2016 (UTC)


 * Yes. ShakespeareFan00 (talk) 09:01, 28 June 2016 (UTC)
 * So… in footnote on first (and subsequent) pages; and in header on second to last page, with  at end of paragraph on last page? — Zoeannl (talk) 09:39, 28 June 2016 (UTC)
 * 2nd try. in header on second to last page, with  in footnote on first (and subsequent) pages; and at end of paragraph on last page? — Zoeannl (talk) 10:24, 28 June 2016 (UTC)

If the paragraph is split..


 * nd/GPO/s at start of paragraph.
 * etc...
 * nd/GPO/e in footer
 * nd/GPO/e in footer


 * On next page: -
 * nd/GPO/c
 * ... etc.
 * ½ using sfrac. It is the preference that real characters are represented or by their unicode wherever possible. . If you are unable to utilise keyboard shortcuts like Alt-171 in Windows, there are choices in the toolbar options. Thanks. — billinghurst  sDrewth  07:46, 30 June 2016 (UTC)

Share your experience and feedback as a Wikimedian in this global survey
Hello! The Wikimedia Foundation is asking for your feedback in a survey. We want to know how well we are supporting your work on and off wiki, and how we can change or improve things in the future. The opinions you share will directly affect the current and future work of the Wikimedia Foundation. You have been randomly selected to take this survey as we would like to hear from your Wikimedia community. To say thank you for your time, we are giving away 20 Wikimedia T-shirts to randomly selected people who take the survey. The survey is available in various languages and will take between 20 and 40 minutes.
 * 1) default=

Take the survey now!

You can find more information about this project. This survey is hosted by a third-party service and governed by this privacy statement. Please visit our frequently asked questions page to find more information about this survey. If you need additional help, or if you wish to opt-out of future communications about this survey, send an email to surveys@wikimedia.org.

Thank you! --EGalvez (WMF) (talk)

larger is a span template so can be used for a span of text which is usually a word, a few words, or something smaller than a paragraph, so it works for having  (x-larger) words. Where as look what happens with (x-larger block) words.

Once your at a paragraph or several paragraphs a span won't work, so we would use larger block, and you have to use paragraph or division markers. We tend to just do division (or for use we call them "block" templates. Now if you want to centre words, you cannot do it with a span, it will be div.  Remember you cannot just centre a few words from within a sentence, it is all of something.  So I will always have the center on the outside of other formatting   nested this way   div -> span -> span.

So your problem with Italic text and Bold text is that they are wiki syntax for italics and bold spans, so their formatting stops at the end of a line. So you can use continue the formatting on the next span by the same method. BUT if you just want one set of coding, we can sneak back to using traditional html, eg. Italic text and Bold text and it it continues over a page then closing tag can be moved into footer, and the opening tag put into the header. It isn't templated as we can use html, though if you think that it needs to be, then maybe we need to do it.

How to have things work? We have tried to label sizing and related div templates with "block" to make them overt, and the other sizing (span) as without. If something is centered, then it has to be a div (rule, asterism, center, ...). Usually we would fix up most newbies work where it is the other way around, for those who are more melded to the community we explain, and see how the conversation progresses. Any feedback that you have about what is needed to better explain, make evident, have easier, is most welcome. {Just like this conversation] My initial thoughts are that we need to look to better explain DIV > P > SPAN and their nesting, and then where we have templates that are a DIV that we probably need to better highlight their difference more evidently.

Line formatting/breaks. These line breaks are what breaks formatting on all span templates, wikilinks, etc. So in cases that any of those things span a line break they need to be removed. I am certainly one has the practice (guilty?) of removing all line breaks for such, and to dehyphen ends of lines. You are correct that there are two aspects to removing vs. leaving.

With regard to your comment about being the only proofreader, I am not sure that I get the gist of the comment. Yes, our tools are less than perfect. There has started the transition to give users the ability to use VisualEditor rather than the raw wikitext/markup, there is just lots of legacy to get through, and the WSes traditionally get less in resources (chicken and egg there). — billinghurst  sDrewth  08:25, 18 April 2017 (UTC)
 * Good information. Often wondered why center and smaller needed to be in a certain order. A comment re line breaks; to leave them in or remove. I notice that some of us are coming from a DP community. Leaving line breaks in in that environment works very well. Not so much here. When I'm proofing/validating, I have to temporarily boost my Windows magnification from my default 150 to 200. This is so I can effectively see what is presented on the edit portion of the page. However, when I do that, the display I see is about 85% of the words on one line and the remaining words on the second line which makes it more difficult for my style of proofing. That's one thing I like about working here; fewer hard rules (only one being emdash space before/after). It would be a shame to start imposing a more DP-type environment here. Humbug26 (talk) 16:24, 18 April 2017 (UTC)

Note
Hello. Hope I didn't stop you in your tracks or cause a frustrating edit conflict by placing this note. I tried to leave note a couple pages ahead of you, but I am a slow typist, and you were too quick for me :) Feel free to remove my note and continue. I thought to tap you on the shoulder there rather than here, but now I have interrupted you twice. Apologies, Londonjackbooks (talk) 12:16, 10 July 2018 (UTC)

Well, I doubt there are many around here who will insist you remove end of line breaks... But I would still suggest adjusting the running headers when proofreading, and if characters are missing (such as Greek &c.), the page should be marked as problematic until resolved. This text was on my to-do list (I had only proofread one chapter), which is why it was on my watchlist, and why I am here at your talk page right now. Of course, we don't claim ownership here, so you are free to proofread. Thanks, Londonjackbooks (talk) 04:21, 11 July 2018 (UTC)

Hi no offense but I just proofread as I read. I got onto this book after it was referenced in The Origin of the Family, Private Property and the State which I just finished reading and enjoyed. You did interupt my proofing the other night but not in a bad way -I’m in NZ so it was past bedtime and I lost track of time trying to finish. I’ve had a year of disruption and am enjoying being back and reading books.

I have been doing this for a while and am over trying to persuade WSers to use Distributed Proofreading (Project Gutenberg) standards so we can get more proofreaders here. I am not an exceptional proofreader at DP but here I am because I’ve managed to pick up how to Wiki-sort of, and kept at it because I like working through a whole book I’m interested in which I can’t do at DP. I don’t remove hard returns as this assists proofreading by the validator. I don’t change the second header as I proofread as I’m lazy and it breaks the flow. I have gone back to copy and paste every second page in the past. I forgot with Origin though.

Cheers, Zoeannl (talk) 08:42, 11 July 2018 (UTC)


 * Thanks for the reply. In my opinion, it is worthwhile to seek to treat every work as though it will be nominated for Featured Text, for example. Also in my opinion, this includes the correctness of non-transcluded headers/footers. It is one thing to leave out a rule from the header, but where text information is concerned, it should be matching. In any case, formatting should be consistent throughout a text, to include header formatting, hard breaks, etc. That is my main concern. The chapter I proofread removes hard breaks and includes a rule in the header. If it is your wish to continue as you are, then either your formatting or mine should be adjusted for consistency's sake. Again, all my opinion. Thanks :) Londonjackbooks (talk) 09:21, 11 July 2018 (UTC)

CAPS
Hi. In the pages The Sphere and Duties of Government/Chapter 10 would you be okay with these being converted to lower case, or maybe some camel case. The upper case for prev/next/section is a little eye-catching. — billinghurst  sDrewth  07:18, 4 September 2018 (UTC)
 * And I will hazard a guess that Coulthard is the one at Page:Alumni Oxoniensis (1715-1886) volume 1.djvu/326. I will span out from there to see what he does later in life. — billinghurst  sDrewth  07:27, 4 September 2018 (UTC)


 * hi, can you tell me why the page numbers in the transclusions are blurred and in the text? Cheers, Zoe
 * I am not understanding to which text that you are referring. I am not seeing issues of blurring, in either text, so I am going to need a link and a little more info as I may be looking in the wrong spot. Thx — billinghurst  sDrewth  21:13, 4 September 2018 (UTC)
 * So at The_Sphere_and_Duties_of_Government/Chapter 10 I have the page number [121] blurry and in the middle of the text. Is it just me? Zoeannl (talk) 22:21, 4 September 2018 (UTC)
 * Looks okay to me. Do you have all your page links in the running text? If so, then in your left sidebar, you can toggle to   ->  .  Hmm, that grey background does have them less clear. — billinghurst  sDrewth  22:30, 4 September 2018 (UTC)
 * That’s it. Must have toggled it accidentally at some stage. Cheers, Zoeannl (talk) 22:45, 4 September 2018 (UTC)

Growth team updates #2
Welcome to the second newsletter for the new Growth team!

The Growth Team's objective is to work on software changes that help retain new contributors in mid-size Wikimedia projects.

Our plan for the next quarter is ready

After consulting with many communities on the best ways to increase retention, we will focus during the next 3 months on these projects:


 * Understanding first day: to see what new editors do right after creating their accounts. We will be careful with user privacy, and we hope to share initial results in December.
 * Personalized first day: this idea will also help us learn a lot about new editors by adding some optional questions to the new editor’s registration process. We hope to share initial results in December.
 * Focus on help desk: we plan to invite or redirect people to the local help desks where they can ask questions to help them make their first edits. We hope to have an initial experiment running in December.

You can read about the details of this plan on our team page.

How did we get to this plan?

We have set up our plan based on the 8 ideas we were considering. You can read about our analysis in our team updates, and detailed discussion on each idea.

We are looking for volunteers

Do you want to participate to our experiments? We are looking for new communities to work with us (especially a new mid-size wiki), and people to become ambassadors to help us to communicate with the different communities. Discover how you can involve yourself or your community.

Learn more about us

You can visit our team page to find out why our team was formed and how we are thinking about new editors, and our project page for detailed updates on the projects we'll work on.

'' Growth team's newsletter prepared by the Growth team and posted by bot, 13:31, 4 October 2018 (UTC) • Give feedback • Subscribe or unsubscribe. ''

Novalis
Thanks for adding the author link. I had not as of yet looked into the identity of Novalis and the associated quotation, but will do so now :) Londonjackbooks (talk) 08:29, 16 October 2018 (UTC)

Growth team updates #3
Welcome to the third newsletter for the new Growth team!

The Growth team's objective is to work on software changes that help retain new contributors in mid-size Wikimedia projects.

Two Growth team projects to be deployed in next two weeks

We will be deploying the "Understanding first day" and "Personalized first day" projects on Czech and Korean Wikipedias in the coming weeks. See the new project pages below for full details on the projects, and our project updates page for their progress.


 * Understanding first day: learn about the actions new editors take right after creating their accounts. We will be careful with user privacy, and we hope to share initial results in December.
 * Personalized first day: learn about new editors' objectives by adding some optional questions to the new editor’s registration process, and personalizing their onboarding. We hope to share initial results in December.

Third Growth team project begins


 * Focus on help desk: direct newcomers to the local help desks where they can ask questions to help them make their first edits. We hope to have an initial experiment running in December.

Best practices for helping newcomers

We are going to direct newcomers to help desks. But what's the best way to reply to a newcomer there? We have gathered some best practices for successful interactions, based on community experiences and some external documentation. The page has also been reviewed by some experienced community members who suggested some changes. That page is now open for translations. Comments and suggestions are still welcome!

We are still looking for volunteers

Do you want to participate to our experiments? We are looking for new communities to work with us (especially a new mid-size wiki), and people to become ambassadors to help us to communicate with the different communities. Discover how you can involve yourself or your community.

Also, please share this update with your community and interested people!

Learn more about us

You can visit our team page to find out why our team was formed and how we are thinking about new editors, and our project page for detailed updates on the projects we'll work on.

'' Growth team's newsletter prepared by the Growth team and posted by bot, 13:30, 7 November 2018 (UTC) • Give feedback • Subscribe or unsubscribe. ''

Growth team updates #4
Welcome to the fourth newsletter for the new Growth team!

The Growth team's objective is to work on software changes that help retain new contributors in mid-size Wikimedia projects.

We need your feedback!

We have two requests for community members:


 * 1) Now that data is coming in for the welcome survey, we are planning how to use that data to personalize the newcomer's first day.  See our current thoughts here, and join the conversation here.
 * 2) Try out the help panel's interactive prototype, and read about how we're planning to roll it out, and post any thoughts or reactions here.

Two Growth team projects have been deployed (detailed updates here)


 * Personalized first day (welcome survey) was deployed on November 20 on both Czech and Korean Wikipedias.
 * The survey is now being shown to half of new users (A/B test). Responses are being recorded in the database. We'll report on initial results during December.
 * We are planning to test a second version of the survey, called "Variation C", which we think will maximize the number of users who complete the survey and stay on the wiki.
 * The original objective of this project was to give newcomers the materials they need to achieve their goals, and so now we are currently planning how we will use the information collected in the welcome survey to personalize the newcomer's experience. We hope community members will read our current thinking and join the conversation here.  Some of the plans we are considering include:
 * Making it easy for newcomers to see editing activity around the topic areas in which they indicated that they're interested.
 * Connecting interested newcomers to experienced editors.
 * Surfacing the help content most relevant to the reason for which the newcomers created their accounts.


 * Understanding first day (EditorJourney) was deployed on November 15 on both Czech and Korean Wikipedias. It has been done after a longer security review and final testing than expected. Data is now being recorded for all new users on those wikis, and we've been auditing the data and preparing to make initial reports during December. Stay tuned for the next newsletter!

Help panel is under construction


 * Focus on help desk (help panel) is planned to be deployed during the week of January 7 on both Czech and Korean Wikipedias.
 * This interactive prototype is the best way to see the design and wording in the feature.
 * We ran live user tests on the prototype, with results posted here.
 * In addition to giving the ability to ask a question, the help panel will also contain a set of links to existing help content. Our ambassadors on Czech and Korean Wikipedias are determining the right initial set of most helpful links in this task.
 * We encourage community members to try out the prototype and read about the rules for who will get the feature, and add any thoughts to this discussion.

We are still looking for volunteers

Do you want to participate to our experiments? We are looking for new communities to work with us (especially a new mid-size wiki), and people to become ambassadors to help us to communicate with the different communities. Discover how you can involve yourself or your community.

Also, please share this update with your community and interested people!

Learn more about us

You can visit our team page to find out why our team was formed and how we are thinking about new editors, and our project updates page for detailed updates on the projects we work on.

'' Growth team's newsletter prepared by the Growth team and posted by bot, 09:31, 7 December 2018 (UTC) • Give feedback • Subscribe or unsubscribe. ''