Warning Please do not post any new comments on this page.
This is a discussion archive first created in , although the comments contained were likely posted before and after this date.
See current discussion or the archives index.

Announcements

Proposals

Recommendation for proofreading by unregistered users

A recommendation to improve the editing experience for editors who are not registered or logged in.

  1. Reduce the editing window to 12 rows from the currently estimated ~25 - 30.
  2. Enlarge the fixed font size because it's way too small. This alone may turn people away from contributing. — Ineuw talk 07:26, 14 February 2015 (UTC)
Whilst the intent of this proposal is sound; realistically the entire ProofReadPage extension ethos is so deeply bound to users being logged in that frankly Wikisource is never going to be able to be made to look attractive to anonymous contributors, and any attempt to do so without fundamental advance/redesign of that extension is a basic waste of time.
The best that can be hoped for is to continue the efforts ongoing to make it look attractive to consumers, and perhaps hope they might register and return as contributors later on? unsigned comment by anonymous (talk) .
I have difficulty with the belief that the proposed visual changes cannot be implemented, Wikisource culture or not, personal experience says otherwise. If enough people support such a proposal, it will be implemented. If the powers that be, try editing without logging in (Try it, you won't like it.), that in itself would be a good motivator to implement the changes.— Ineuw talk 17:17, 14 February 2015 (UTC)
Even when logged in, the window size and font size vary hugely depending upon the browser I'm using. Firefox gets it right, and IE isn't too bad, but Safari gives me a tiny edit space and tinier font. Unless a proposal can be made that will be consistent across all browsers, I don't see it gaining support. --EncycloPetey (talk) 18:04, 14 February 2015 (UTC)
I fail to understand why you are taking such a negative view. As for your setup, am surprised at your screen differences as well as you comment to "gaining" the support of the community. What does the logged in community has to do with the proposed changes? Unless, it's your habit is to edit anonymously, your comment is non sequitur. I uploaded six screenshots to the Commons. Four are from Windows (FF, Chrome, IE11 and Opera) and two from a Macbook (FF and Safari) all screenshots were made without logging in. IE11 was the only browser displaying 19 lines of text all the others were 25 rows.

I also spent an inordinate amount of time figuring out the font style and font issue. Firefox has its own fonts built in and are inaccessible. I suspect the same with Opera and Chrome.— Ineuw talk 00:03, 15 February 2015 (UTC)

In your screenshots you appear to have toggled the page scan to appear above the edit box and tools. I get the impression that the box is as long as it is because it is meant to stretch a distance downward comparable to a page scan shown beside it. In fact at least for me, on two browsers, in this mode it's never long enough (whether logged in or not). When you toggle the scan to appear above the editing interface, it makes the vertical size of the editing window largely either irrelevant or completely subjective depending on how you personally edit, because you won't be seeing much more out of your scan than a line or two, so what all are you hoping to compare it with in the edit box? djr13 (talk) 04:02, 15 February 2015 (UTC)
I'm sorry that you have such a hard time understanding other viewpoints. I'll only address one of the points you didn't understand: "What does the logged in community has to do with the proposed changes?" It is the logged in community that would need to be rallied to get behind the proposal to make it happen. Anonymous WS editors are unlikely to turn out in droves to do that. --EncycloPetey (talk) 04:16, 15 February 2015 (UTC)
@EncycloPetey: What I was trying to say - Why would any logged in editors oppose a proposal which would improve and unregistered user's experience without harming their own setup?

Having said that, and trying to understand the code elements of Wikisource software, the unregistered user's setup is identical to the default editing settings in Preferences. In this, the default font setting is the browser's default font and size. In Firefox, these are set in Options\Contents\Advanced Monospace font. I haven't checked other browsers.

@Djr13: The Preferences default edit area is 80 columns (or less when using side by side proofreading method, and always 25 rows regardless which view is selected - over & under, or side by side proofreading. Ineuw (talk) 21:13, 15 February 2015 (UTC)

The problem is not opposition to the proposal, but failure to support. Failure to support (apathy) is not the same thing as opposing something. I am apathetic because I've experienced issues that do not seem to be addressed. I've stated my own personal experiences with the edit window. If your experience is different, then it may be a result of using only the latest version of Windows, which I am unable to use. I can't recall which old version of Windows I'm currently forced to use, but upgrading to the latest version of Windows is not possible for me, and may not be for many other editors. You have also failed to consider the impact / effect of mobile devices and their defaults, and have not addressed the issue of side-by-side editing windows (as opposed to windows above each other), which is the way I always see the editor when I am not logged in. --EncycloPetey (talk) 22:28, 15 February 2015 (UTC)
@EncycloPetey: You have a point, but this is how proposals made . . . and eventually accepted and then implemented. As for Windows, I use Windows 7 which is an upgraded Windows XP, very stable and supported. I believe that mobile devices are of secondary importance for proofreading.

The font size is the same as the default font size in the browser, if the font preferences are set Browser default. As for over/under, or side by side editing, the text side of the window in side by side editing is the same 25 rows of the Wikisource default, just the columns adjust automatically to accommodate the scan on the right. But one can modify these settings, I outlined previously.

My proofreading setup is over and under, and the text editing window height is set to 11 rows which is approximate because I see 12 rows. That's all that fits into the screen without constantly scrolling up and down. I also experimented with side by side editing and found that if the text area is set to ~60 rows, it matches the page length of a scanned PSM page.

One last thing, The advantage of editing in over/under mode is that a row of scanned text matches the row of the original without a line break. Ineuw (talk) 03:28, 16 February 2015 (UTC)

┌─────────────────────────────┘
@Ineuw: So are you saying that these can be configured separately so that the default size of the box is appropriate to the editing mode in use? If so, I have no opposition to the change. I would offer my support for it, but I essentially only ever use "over" mode if I need to eliminate the column taken up by the scan so I can shrink the browser window and use a different scan (rarely). djr13 (talk) 19:17, 16 February 2015 (UTC)

@Djr13: Yes, you can change the settings back and forth to whatever you want because you are a registered user. Just to clarify. If you were to reset your editing preferences to the Wikisource default, (for which there is an option on the right of the Save button), then, Wikisource sets the editing options to: Side by side editing, Font = Browser default and the editing box size is set to 80 columns wide and 25 rows high. This is the only mode an unregistered user has. They have no access to any preferences. You, as a registered user can change these parameters to anything you want in your Preferences\Edit panel.

My original proposal is moot because the default settings for editing are built into the Wikimedia software and there is not separate preferences setting for unregistered users. Ineuw (talk) 19:39, 16 February 2015 (UTC)

BOT approval requests

Help

Repairs (and moves)

Other discussions

Survey

Speaking for myself - one of the worst things about discovering the wiki-world was its inability to fully match some of the most basic of basics out there -- simple HTML. Probably one of, if not the worst thing I came to realize early on was wiki-markup's inability to incorporate <COL> & <COLGROUP> tags into the backbone of whatever it is they are running like sane people do everywhere else. You entered formatting parameters just once and the entire column of table cells would be formatted with those inputs. Easy peasy lemon squeezy -- you were done with setting up a frame &/or the table foundations and could go right to 'tweaking it' before moving on to something more enjoyable.

Which brings me to the reason I had to stopped myself before I got too giddy again (only to be let down when I find out it was only me who was seeing 'this, that or the other' this time too). Anyway, I think the recent advancements in CSS3 have made overcoming some of this longtime headache a possibility and I need your feedback to insure that -- at the worst -- I've only wasted the last couple of hours invested in this.

All I ask is for folks to open THIS page, look over the "Basic" section's test-table and report back (with the OS & browser version you are using) ONLY if you did NOT see with your own eyes something very close to the eight descriptions put to word that follow.


Ignoring the top-row of the table containing bold-face text and counting from left -to- right, is it NOT true that...

  1. Column 1 has all right-aligned text and all their table-cells have a yellow-ish background
  2. Column 2 has all right-aligned text and all that text is rendered in small caps
  3. Column 3 has all centered text and all that text has slightly larger letter-spacing than you'd normally come across
  4. Column 4 has all right aligned text, a smaller font-size than the rest and are all vertically aligned to "text-top"
  5. Column 5 has all right aligned text
  6. Column 6 has all left aligned text
  7. Column 7 has all centered text; and finally
  8. Column 8 has all right aligned text and all their table-cells have a green-ish background.

If one or more of the above descriptions is not what you've observed on the linked page with the test table -- I'd like to know it about along with your OS and browser version. The rest of you are welcome to add your OS and browser versions along with a short blurb affirming as much but I rather you poke my eyes out on my talk page than in this survey's section. Thanks in advance. -- George Orwell III (talk) 19:51, 4 January 2015 (UTC)

Survey findings

Findings

Will close on Sat., February 28th.

  • Windows 7 -- I checked the page with my "toys" (installed browsers in Windows 7) and all I can say that everything is as it should be.
  •  Y Firefox 34.0.5
  •  Y IE 11.0.15
  •  Y Opera 26.0
  •  Y Comodo Dragon Version 36.1.1.21 (Google Chrome)
Ineuw talk 21:10, 4 January 2015 (UTC)
  • × Firefox Nightly 37.0a1 (2015-01-04). Column 4 is left-aligned not right-aligned for me.
Hesperian 00:50, 5 January 2015 (UTC)
@Hesperian: - tsk my fault. No matter how careful I thought I was during my last attempt at further "refinements" I still managed to screw up Column 4. Please check it again at your leisure. I suspect you'll have 8 out of 8 this time. -- George Orwell III (talk) 01:05, 5 January 2015 (UTC)
 Y WFM. Hesperian 01:09, 5 January 2015 (UTC)
  • billinghurst check
  •  Y Firefox 34.0.5 (W8.1)
  •  Y Chrome 40.0.2214.38 beta-m (64-bit) (W8.1)
  •  Y IE 11.0.9600 (W8.1) (64-bit)
  •  Y IE9 (some version, W7)
I will see if I can find PC running IE8 and run a check. To note that as WMF has turned off active (javascript) support for IE6 and IE7 I don't think that it is a major issue for us to follow suit. It is maybe the ability for us to identify browsers that we know are broken, and let people to know why. — billinghurst sDrewth 01:31, 5 January 2015 (UTC)
I'm nearly passed out from giggling to myself with so much delight -- no scripting involved Its all done by using new pseudo elements from CSS 3 (imagine my disbelief when I saw it "work" for the first time > > > had to run a survey).

Granted an old browser is just that and there's little we can do about it -- but it won't be the fact that "active" javascript is no longer supported around here that's causing it to fail. :) -- George Orwell III (talk) 01:45, 5 January 2015 (UTC)

I was more trying to indicate that the alignment of columns of a table will be among the least of their concerns if they are on IE6/7.
  •  N ASUS default android browser at en.m.wikisource.org mobile site expectedly, though desktop site displays table properly, though chops off right border of table.
billinghurst sDrewth 13:05, 5 January 2015 (UTC)
Ohhh lord-y, lord-y - don't get me started on Mobile Mode. Anyway, I added overflow: scroll; for the highly unlikely chance its presence is needed to invoke scrolling as I recall it being a legitimate bug at some point and, I forget if those things run on firmware or some form of crippled bios. but you'd be doing yourself a favor by flashing to the latest version if not there already.

I did set the width at ~1000px rather than the usually more dynamic 100% to insure as many alignments as possible would not be "questioned" as center when its really left or right. You can try changing that to see if there is any difference as long as you don't forget to change it back. -- George Orwell III (talk) 19:39, 5 January 2015 (UTC)

Tested it because I could and that it provided a baseline, not b/c it is the tool of choice. If I browse off the tablet it is usually a FF derivative. We still need an Apple iThing test. — billinghurst sDrewth 00:59, 6 January 2015 (UTC)
Umphf. You reminded me of my uncharacteristically un-locatable iPod. Pretty sure it runs the same OS & browser as the iPhone does so hopefully I'll remember to verify this w/that when I come across it again (That Is what you meant by "iThing(y)" right? anything with internet connectivity made by Apple and sold as i-Whatever or is there really an app or suite of mobile tests marketed with that name?) -- George Orwell III (talk) 04:24, 6 January 2015 (UTC)
  • IE8 (W7)  N, shows every column left aligned, same text size and no background.
  •  Y Firefox 34.0.5 (Mac OS 10.9.5)
  •  Y Safari 7.1.2 (Mac OS 10.9.5)
  •  Y Safari 5.0.6 (Mac OS 10.5.8)
  •  Y Firefox 16.0.2 (Mac OS 10.5.8)
Beeswaxcandle (talk) 06:11, 5 January 2015 (UTC)
TY! IE8 (and lower) "failing" is not all that unexpected, although IE8 still has more users than 9 or 10 apparently. No worries (its Microsoft remember? :) -- George Orwell III (talk) 06:51, 5 January 2015 (UTC)
  •  Y Sony's version of Android (2011) in B&W
--Beeswaxcandle (talk) 08:08, 5 January 2015 (UTC)
  • On Ubuntu 14.04
  •  Y Firefox 34.0
  •  Y Chrome 39.0.2171.95
--Mpaa (talk) 12:31, 5 January 2015 (UTC)
  • iOS 8.1.2 on a 5th gen. iPod ( have no idea what ver. of Safari its running )
  •  N Safari - Mobile Mode (en.m.wikisource.org) fails - but not much works there to begin with (ongoing issue)
  •  Y Safari - Desktop en.wikisource site is a-OK on all points however.
  • Windows 8.1 (64 Bit)
  •  Y IE 11.0.9600.17498
-- George Orwell III (talk) 00:26, 24 February 2015 (UTC)

Page status checker is not working

I use the toolserver checker to count the number of pages to be validated. This is not functioning currently. Is there another way to calculate the number of pages to be validated? — Ineuw talk 18:32, 28 January 2015 (UTC)

Would Category:Proofread do what you need? Beeswaxcandle (talk) 04:41, 29 January 2015 (UTC)
Thanks, but not really, Finding the pages in the category would take a whole evening. Also, there seems to be a sorting or placement error in the 'P' section. Should not this Index:Transactions of the Provincial Medical and Surgical Association, volume 2.djvu be in the "T" section? — Ineuw talk 01:57, 30 January 2015 (UTC)
@Ineuw: Toolserver is long dead. The checker tool is now on ToolLabs, and the links from Index pages have been updated. — billinghurst sDrewth 12:09, 1 February 2015 (UTC)
Pardon, but its down on tools.wmflabs at the moment. Its been pot-luck for the past few weeks now. -- George Orwell III (talk) 18:52, 1 February 2015 (UTC)

Cannot put hatnotes etc above header

All of a sudden the header is being forced to appear at the very top of the page, before everything else, even if I have inserted material before it such as a hatnote template (e.g. {{other versions}}) or a message box template (e.g. {{incomplete}}). It looks abominable (e.g. The Lesson of the Master, The Marriages, The Pupil, Brooksmith, The Solution, Sir Edmund Orme (New York & London: Macmillan & Co., 1892)/The Lesson of the Master). Hesperian 00:36, 29 January 2015 (UTC)

I think someone's been tinkering with the layout code. Recently, briefly, the layouts began to appear on all namespaces, including for example Template. It seems to properly only apply to mainspace now, but with a new set of problems. The hatnote issue is one, another is the same header problem on diff pages, another is that layouts are now applying to disambiguation pages and even to the main page of the wiki. It's not a showstopper for transcribers, at least... I've been assuming whoever is working on it just needs some time to iron it out. djr13 (talk) 02:46, 29 January 2015 (UTC)
Yeah, that is exactly it - Dynamic Layouts touches everything first & is then retarded back to just affecting the mainspace works and is then further limited to just transcluded works that appear in the main namespace. In trying to recover the 3em; gutter along the right that is suppose to offset the 3em; margin used for embedded page links on the left (which you would never normally see or know is happening until you start taking things apart), I got as far a moving all the license banners out of Dynamic Layouts on the bottom and headers in general out of Dynamic Layouts on the top. I see there is more to be done along the top (or front matter if you like) re: diff pages & hatnotes so I'll turn that off until I get all those worked out.

The thing about affecting all pages is a deeper problem and have not looked into the possibilities there. -- George Orwell III (talk) 03:09, 29 January 2015 (UTC)

yeah, i see it is kicking out pages with {{TextQuality|50%}} or {{EB1911}} at the top. should i just delete that? pretty lame when it can’t recognize the template is there. you are now slowing my work as i have to click thru your nonsense warning. <sigh> Slowking4Farmbrough's revenge 22:36, 29 January 2015 (UTC)
If it wasn't clear before let me make it so now: All of this "tinkering" is a single, ongoing endeavor to wrangle in Dynamic Layouts while becoming more Mobile Mode friendly at the same time. Its the reality in the growth of Mobile Mode en.WS traffic that spurs the need to wrangle in Dynamic Layouts back to a "more simple" incarnation - the crux of the issue is the fact that Mobile Mode cannot process -- nor would benefit from if it could -- the three or four preset layouts familiar to Users: who live & play primarily in Desktop view. Once that threshold is established - the "forking of things" should result in Desktop View having everything Dynamic Layout related it had all along restored while Mobile Mode successfully runs a watered-down variant of it as well.

The very least MM should "get" at the end of all this "tinkering" is the ability to toggle inline embedded page links pointing back to their appropriate Page: namespace counterparts on or off - otherwise getting from the main namespace to the Page: or Index: namespaces under Mobile Mode is neither apparent nor seamless nor intuitive anymore. So Please - start taking a look at your desktop view finished products in Mobile Mode before you sign-off on them and start making notes of what "transfers" and what does not.

Back on point @Slowking4: - what exactly is the problem with {{TextQuality}} templates (other than some believed, overall, that we should have stopped applying them altogether at one/some point)? -- George Orwell III (talk) 00:23, 30 January 2015 (UTC)

as i try to save a page that someone else years ago put a text quality template on, i encounter the helpful banner. as i try to save a page with a custom template such as EB1911, i encounter the helpful banner. should i now change the custom template to one that your code recognizes? i’m trying hard not to encounter the banner, but there is not much help or documentation, merely an exhortation to use page headers, thank you. i really do appreciate the doubtless unpleasant task of code upgrade, but you know we’re a community here, and notifications are nice, before the banners go forth, and false problem reports are unhelpful, where do i go to turn it off. Slowking4Farmbrough's revenge 02:32, 30 January 2015 (UTC)
WHAT BANNER are you talking about seeing upon every(?) save attempt? What does it "say"?

I'm not trying to be difficult - I just do not "see" what you're describing taking place here when I save either type of scenario is all. -- George Orwell III (talk) 02:44, 30 January 2015 (UTC)

@Slowking4: never mind, I figured out what you were complaining about. The abuse-filters were set to detect one thing while the new incarnations of the header template are no longer table based and therefore no longer detected by the filter (adds the tag 'no header' on watchlist /recent changes pages). Should no longer pop-up now. Sorry - that filter isn't one that I've dealt with much (never had to until now). -- George Orwell III (talk) 03:06, 30 January 2015 (UTC)
thank-you, yes it was less a banner, than a top spanning notice of missing page template, with a link to here. and requiring a click thru to save twice, for each page. thanks again for fixing the old code. Slowking4Farmbrough's revenge 03:17, 30 January 2015 (UTC)

Text quality template and categories

I noticed the mention of the "Text quality" template in the previous post which reminded me of something I came across recently. In extracting from the database the categories assigned to PSM, I found that the text quality template ended up in the Categories column. When I checked the page, it was inserted at the top left corner prior to the title template {{ opening brackets. Should the template be placed there? — Ineuw talk 02:10, 30 January 2015 (UTC)

The template generated an empty span wrapped in a div that acted like a placeholder for the associated script in found common.js (Quality Indicators etc.). Only categorization (25, 50, 75, 100 %) takes place outside of that script - which is why you saw what you saw. I switched the "placeholder" approach to use indicator tags instead (the scheme that now handles the top-right featured star icons & similar) so you can place the template anywhere you like and it will still go to the same spot. But in order to maintain some sense of standardization/conformity, please keep placing it before the header template as that seems to have been the practice prior to any of the recent changes. -- George Orwell III (talk) 19:14, 1 February 2015 (UTC)
Hi, GO3. Thanks for correcting it. Personally, I don't use the quality template because PSM articles are all transclusions and the quality is indicated by the color bar. — Ineuw talk 15:06, 5 February 2015 (UTC)

Art

Would I be allowed to place *my own artwork* on commons or here on wikisource? Art in color - oils on canvas, pen and ink sketches. ... It would be realism not abstract. I understand I would be donating it. —Maury (talk) 02:40, 31 January 2015 (UTC)

@William Maury Morris II: It would go on Commons and have to fit their criteria: in short, a free license and it has educational value. —Justin (koavf)TCM 15:34, 31 January 2015 (UTC)
Yes, thank you. I believe everything has educational value, or at least my work does. —Maury (talk) 22:11, 31 January 2015 (UTC)
some people are putting their work on flickr, since there you do not have the phenomenon of people coming along 5 years hence and deleting it as not educational. Slowking4Farmbrough's revenge 13:14, 3 February 2015 (UTC)

16:31, 2 February 2015 (UTC)

A little question about the Featured Text

The description of February's featured text states that one of the authors also wrote The Tale of Genji, "possibly the world's first novel". I am aware that this statement mimics the concerned Wikipedia article. Nevertheless, I have a little question: if this 11th century work is "possibly the world's first novel", then what about the seventh century Sanskrit novel, w:Kadambari? It would have been better to mimic another Wikipedia statement, that it was the world's first psychological novel, or even, the first novel by a female author, or some such. Hrishikes (talk) 16:11, 3 February 2015 (UTC)

I wrote it and a lot of the information does come from Wikipedia. Speaking of, their w:Novel article also suggests The Tale of Genji is the first novel, despite mentioning Kadambari. I have no personal knowledge of this, so I'm relying on their information and I don't know what criteria may or may not exclude Kadambari. Presumably the definitions of novel being used may vary. The word "possibly" already includes some ambiguity but I have changed the wording to "often attributed" instead. I would prefer to avoid qualifiers like "psychological" or "by a female author" as they diminish the significance of the act (a first of that kind could have happened within the modern era, rather than potentially being the first ever). - AdamBMorgan (talk) 12:14, 5 February 2015 (UTC)

annoying "Legend"

Is there some way the Legend can be removed or at least be closed when I log aboard Wikisource? It as as bad as the "we need money now" banners of Wikipedia, well, not that bad but it is annoying. Long ago on Internet we called them "begging screens" and "beg banners" which first came to me to purchase software. After that came freeware but all are just as annoying. It is similar to Gobble's ads on thousands of Internet pages and all of which are "legendary" in the history of Internet, before Internet on BBS's and of shareware (often timed) —Maury (talk) 16:33, 8 February 2015 (UTC)

Would you be able post or link to a picture of what you're referring to? I don't see any banners except for the steward elections (very small) banner. I'm curious. The Haz talk 18:25, 8 February 2015 (UTC)
Sure, Hazmat2. But please do not condemn me just for *asking* about this.


Legend:

N
    This edit created a new page (also see list of new pages)
m
    This is a minor edit
b
    This edit was performed by a bot
!
    This edit has not yet been patrolled
D
    Wikidata edit
(±123)
    The page size changed by this number of bytes

—Maury (talk) 23:23, 8 February 2015 (UTC)

Does't this only show on the Watchlist page? And is the "collapse" link not persistent? —Beleg Tâl (talk) 01:08, 9 February 2015 (UTC)
Yes, to my knowledge it shows only on the watchlist, which I watch a lot, and yes it persistently shows which is persistently annoying *to me*.I collapse it everytime I see it which is why I personally state that *it is annoying to me*. I would prefer the *option* of opening it rather than collapsing it. I speak for nobody but myself. Further, I asked if it can be removed or at least be closed when I log aboard. There may be a setting I am not aware of. What is your interest in this, Beleg Tâl, regarding *my personal dislike of it*? We have done without it for several years. *I* don't view it as an enhancement. —Maury (talk) 01:59, 9 February 2015 (UTC)
You can make the watchlist legend be collapsed by default by adding the following to your user script page:
if ($(".mw-changeslist-legend .mw-collapsible-content").is(":visible")) {
	$(".mw-changeslist-legend .mw-collapsible-toggle a").click();
}
Sam Wilson ( TalkContribs ) … 02:22, 9 February 2015 (UTC)
@William Maury Morris II: Samwilson is correct. Alternately, you can read your watchlist updates via a syndicated feed and never see Special:Watchlist at all. —Justin (koavf)TCM 02:24, 9 February 2015 (UTC)
Thank you Sam Wilson and I thank you too Justin. I figured there must be a way and I figured someone here would be smart enough to know that way to change the watchlist legend to be colapsed. Afterall, I have seen Index pages with this option. Thanks again fellows, —Maury (talk) 02:46, 9 February 2015 (UTC)
Ah, I see what you're referring to now. I'm glad you got it all worked out. And why would you think I'm "condemning" you for anything?
  • I don't but in not knowing I didn't want *anyone to start* any possible argument. Others read here too you know. Some people actually like to argue fubar.

I just asked for a picture so I could be of some help. I simply wasn't sure what you were referring to. The Haz talk 04:57, 9 February 2015 (UTC)

@Sam Wilson thanks for the script, it's very convenient. --Rochefoucauld (talk) 13:07, 9 February 2015 (UTC)
I'm glad it works. I reckon the custom scripts and stylesheets are one of the best features of Mediawiki; it's possible to almost completely change the UI for proofreading! :) — Sam Wilson ( TalkContribs ) … 00:01, 10 February 2015 (UTC)

16:26, 9 February 2015 (UTC)


Following-up to above items

We should be checking and noting

  • the circumstances of the above notified modification to Labeled Section Transclusion where it will work for section headings
    {{#lsth: PageName | SectionName }}
  • deleting out-of-date/retired abuse filter tags

If someone gets there, it would be great if they could report here. I won't get a chance any time soon for an in-depth play. — billinghurst sDrewth 01:47, 10 February 2015 (UTC)

Regarding new transclusion method: I attempted transcluding from the Page namespace to the main namespace. First I attempted using both section labeling methods and found neither to work. I also attempted putting both the section begin and section end tags on the same page and that did not work either. In both cases, there was no text on the page in the main namespace that I was transcluding to. In the HTML I found only paragraph tags with a line break. However, I also don't see a real use for this specific function as described on phabricator, at least for WS. Perhaps I'm being naive, but it seems that we're trying to get away from transcluding one page at a time and that's somewhat what this new function does. (It supposedly transcribes an entire section, but only from one page, which most pages on Wikimedia and Wikipedia are.) However, I urge others to play around with this as well and post your findings! The Haz talk 03:17, 10 February 2015 (UTC)
Confirmed. My guess this is because the magic-word (or it's coding equivalent) __NOEDITSECTION__ is applied to every page in the Page: namespace by default. As a result the "usual internals" for section headings are not generated in the Page: namespace so its not a stretch to think this has something to do with lst-h not working.

EDIT: It does work with or without subpages being the "root page" as exampled here in a Help: sandbox; won't work if using H# straight html tags (2nd example) however. -- George Orwell III (talk) 12:01, 10 February 2015 (UTC)

Fantastic! However, using headline tags (via equals signs) without using CSS to modify the definition changes the layout of the books, even in your example. Also, I don't think we can transclude more than one page at a time. The Haz talk 01:03, 11 February 2015 (UTC)
LST-H is not meant to transcluded "pages" in the traditional Page: namespace sense but the transclusion of "ranges" (just like when using begin & end section tags to mark a "range") but by using heading sections instead. In other words you wouldn't really use LST-H for "proofreading transclusions" purposes but for isolated inter- or intra-transclusions instances (for now that is. When the additional HTML5 "section-like" tags are supported by wiki-media, we can re-visit what method in what situation makes more sense then). -- George Orwell III (talk) 21:57, 11 February 2015 (UTC)

Categorisation: works by author?

Has there been discussion in the past about creating categories that group works by individual authors? There's the Authors category, but this is just for pages in the Author namespace. I mean a subcategory of the Works category, probably Category:Works by author. This has come up for me because I've been playing around with a little thing that lists the categories of validated works, and I want to view validated works by a any particular author; it seems a tricky thing to do.

I realise it'd be a duplication of the lists on authors' pages, but only in a similar way that e.g. the subcategories of Category:Authors-I is a duplicate of the information in Wikisource:Authors-I.

I'm not really suggesting that this is a good idea, literally just asking whether it's been discussed and what the outcome was (because I dare say it has! and I don't want to dredge up old arguments... hmm, although, perhaps I am... sorry in advance!).

Thanks, — Sam Wilson ( TalkContribs ) … 09:20, 10 February 2015 (UTC)

There are a few instances of such categories that I've seen, but mostly by folks out of the loop for English Wikisource norms. My memory recalls a discussion on this issue decided we were against such categories, partly because of the duplication and partly because of the headaches of dealing with co-authored works, translated works, and such. I personally think such categories would serve no useful function, and simply add to the cruft. Most of our authors have few or no works, and we have a poor category structure and maintenance as it is. --EncycloPetey (talk) 03:00, 11 February 2015 (UTC)
Yes, it's true that the category hierarchy is not particularly clean and organised at the moment! :) You're right about duplication between the authors' pages and the categories, but isn't this the same sort of duplication that exists between the pages that list authors and the categories that contain them (e.g. those I linked to above)? Which is a maintenance burden, but we encourage it anyway (well; that's a question, really: do we encourage it? Is it just a hangover from a previous time? I add new authors to both places when I add them). I wonder if creating a "Works by Author Name" category would be as simple as modifying the {{header}} template? Although, as you say, multiple authors would have to be handled — these would just mean that the work appears in multiple "Works by x" categories though.

I guess, fundamentally, I see an accurate category tree as being of greater value than accurate lists on Authors' pages, because of the ability to query all sorts of different things (like "all 18th century non-fiction works" or "all validated novels", or as is my case in point "all validated works by George Gissing"). — Sam Wilson ( TalkContribs ) … 04:42, 11 February 2015 (UTC)

As stated above category structure and maintenance is poor, and so I can only see the potential mess it may create. We can see this already in general categories. For instance Category:Psychology has a list of psm articles in it that creates an alphabetization disaster. Now of course this can easily be resolved by using redirects and adding categories their. The problem with that is it makes navigation/exploring difficult among users. (note, may make it harder to add such function to {{header}}) Also articles that begin with common words such as 'the,' 'a,' etc. may cause the same problem. In conclusion adding author categories will just create more categories being poorly alphabetized. --Rochefoucauld (talk) 13:46, 11 February 2015 (UTC)

An alternative way to mark page breaks

I discovered that French Wikisource uses another way to mark page breaks, placing <nowiki /> tag at the top of a page and a blank line after it, as in example we can see here. I propose it here to be added to Help:Formatting conventions as an alternative to {{nop}}. As for me, it has several advantages:

  • It does not include any templates;
  • It does not insert html formatting tags in the text;
  • You can add as many blank lines as you want at the top of the page;
  • You don’t need to look at the next page before placing this tag;

The only disadvantage I know is that the source text will be a couple of bytes longer. Nonexyst (talk) 22:43, 13 February 2015 (UTC)

  • The true disadvantage is nothing on God's green Earth except for wiki-based content &/or wiki-markup recognizes such a tag, whereas an empty DIV wrapper is expected to be recognized just about "everything" (including wiki-markup) and its expected behavior (here under wiki-markup) in general is -- when basic & empty; do not process nor render.

    The true fix for when the content at the "end" of a page in the Page: namespace also happens to be the ending of a block-element proper (a paragraph in other words) would be to apply opening and closing paragraph <P> tags to such content as needed (e.g. possibly needed at the first block of content in the Page: that follows in certain instances as well).

    If your browser/settings somehow supersedes wiki-markup's non-processing & non-rendering of an empty DIV element wrapper, try adding a new css3 selector dealing with "empty" elements to your User: common.css to try to usurp the behavior "back to the expected"; something along the lines of...

.mw-body div:empty {
	display: none;
}
Another disadvantage is inconsistency. The more ways of doing something that are used, the harder it is to maintain the site. If we're all doing something the same way, then making a change is simple.

In answer to the list of advantages:

  • templates promote consistency and an agreed change to a template propagates the change instantly to all pages that use the template;
  • given that wiki-markup is converted to html before displaying a web-page, don't worry about this;
  • blank lines at the top of pages are not required—we are not replicating the exact layout of every page of a book, we are making the text available;
  • I don't look at the next page before placing {{nop}} now. The last line of a paragraph is usually a short line and so we know that to put the nop before turning the page. On the odd occasion that a paragraph ends at the right hand margin, there is the handy gadget to insert a nop on the previous page. Beeswaxcandle (talk) 00:33, 14 February 2015 (UTC)

Re the proposal, that was discussed in the early days (pre 2009), and you should be able to find the discussion in the archives to this page. The current means was determined as the preferred means to resolve.

I have a custom regex sidebar script that places {{nop}} as the last thing in the body on a new line, which makes it easy for that too. — billinghurst sDrewth 13:37, 14 February 2015 (UTC)

Help translating German front page

Hello, can someone please help me to translate this front page Index:Gitarristische Vereinigung XIII. Jahrg. Nr 3.pdf. I need a title in English for it so I can create a main namespace. Jpez (talk) 16:12, 15 February 2015 (UTC)

  Done I've translated everything but the contents themselves. Most of those are titles and they're not all in German. --EncycloPetey (talk) 16:52, 15 February 2015 (UTC)
Thanks EncycloPetey. I'll be leaving the titles of the songs as they are because I think they are used with their original names universally anyway. What do you think I should call the main namespace page? Guitarists' Union registered association headquartered in Munich, Number III. June 1912?
There's no need for such a long title. "Guitarists' Union (1912)" or even "Gitarristische Vereinigung (1912)" should be sufficient. --EncycloPetey (talk) 22:31, 15 February 2015 (UTC)

17:57, 16 February 2015 (UTC)

{{fqm}} after a gap

Right now, it is not possible to render {{fqm}} after a {{gap}}. Is it possible to write code into the template to enable one to render quotation marks, etc. in lines of poetry which follow gaps of varying lengths? Thanks, Londonjackbooks (talk) 15:09, 18 February 2015 (UTC)

Methought the sky looked scornful down<br />
{{gap}}On all was base in man,<br />
And airy tongues did taunt the town,<br />
{{gap}}{{fqm|'}}Achieve our peace who can!'

Methought the sky looked scornful down
On all was base in man,
And airy tongues did taunt the town,
'Achieve our peace who can!'

Is this perhaps the effect you wish to achieve?
Methought the sky looked scornful down<br />
{{gap}}On all was base in man,<br />
And airy tongues did taunt the town,<br />
<span style="float:left; text-align:right; margin-left:-1em; width:3em;">'</span>Achieve our peace who can!'

Methought the sky looked scornful down
On all was base in man,
And airy tongues did taunt the town,
'Achieve our peace who can!'

That's pretty clever! So the fix works by defining the width more than the offset, so not only is there a floating <span>, but since it is only partially offset it creates an indentation gap with the floating the quotation mark inside of the indentation gap. {{fqm}} can't do that currently because its "depth" parameter passes equally to width and the "margin-left" offset. The template could probably integrate this in one of two ways...either make it possible to define each parameter separately, or use a little math so that a parameter can intelligently recalculate the width and/or offset to generate the needed indentation gap.

And airy tongues did taunt the town,
'Achieve our peace who can!'

Fun...Not entirely sure how to code this, not great at wikicode expressions. djr13 (talk) 11:47, 19 February 2015 (UTC)
Here is a thought. Too ugly? (N.B. Had to sacrifice (undocumented) depth=3em syntax top get this to work. Cost too high? Revert the template edit if you think so.)
Thought #2: CSS3 to the rescue. Hope this works in more browsers than IE and Firefox. As ever, revert to last working version if problems crop up.
Methought the sky looked scornful down<br />
{{gap}}On all was base in man,<br />
And airy tongues did taunt the town,<br />
{{fqm|gap=2em|'}}Achieve our peace who can!'

Methought the sky looked scornful down
On all was base in man,
And airy tongues did taunt the town,
'Achieve our peace who can!'


What is wrong with either of the following methods? Why does the quotation mark need to be "floated"?

{{block center|<poem>Methought the sky looked scornful down
{{gap}}On all was base in man,
And airy tongues did taunt the town,
{{gap}}'Achieve our peace who can!'


Methought the sky looked scornful down
::On all was base in man,
And airy tongues did taunt the town,
::'Achieve our peace who can!'</poem>}}

Methought the sky looked scornful down
On all was base in man,
And airy tongues did taunt the town,
'Achieve our peace who can!'


Methought the sky looked scornful down
On all was base in man,
And airy tongues did taunt the town,
'Achieve our peace who can!'

Hrishikes (talk) 14:44, 19 February 2015 (UTC)

Quite a few source texts have floating quotation marks. —Beleg Tâl (talk) 14:50, 19 February 2015 (UTC)
Right, and we want to be as faithful as possible to the original.... Most texts I've come across don't float marks on indented lines, but Emerson's work that I am working on does. Thanks all. Londonjackbooks (talk) 15:06, 19 February 2015 (UTC)
Once printed, does not it get fixed? How can it be floating or swimming? How do you determine whether it is floating or not? I don't have any idea, that's why I'm asking. Hrishikes (talk) 15:01, 19 February 2015 (UTC)
You can see it visually. See the example used above on this page in the original image. Not sure if that answers your questions... Londonjackbooks (talk) 15:09, 19 February 2015 (UTC)
Thanks, it's clear now. Hrishikes (talk) 15:22, 19 February 2015 (UTC)

I created this to assist with the accented IPA in a recent work, but figured it may be useful elsewhere.

I also created it because hunting down the relevant combining marker wasn't necessarily as quick as typing the codepoint, and for some more obvious accenting, there are some more specfic cdm... named templates (All were subst) so if needed they can be renamed to conform with the dictratic templates (even though their use is slightly different.ShakespeareFan00 (talk) 20:38, 18 February 2015 (UTC)

cdm=Combining diacritical marker. ShakespeareFan00 (talk) 20:38, 18 February 2015 (UTC)

So, how is this set different in effect from the already existing set in Category:Diacritic templates? Beeswaxcandle (talk) 06:05, 19 February 2015 (UTC)
Because they can be used with ANY base character (which is the one of the parameters), the existing templates were specfic accented characters that (barring some breve-macrons combinations I added) were as far as I knew single points in the Unicode planes. The intent with cdm is to make it easier to add the accents for the ocassions when the accented form is NOT a single standard character, or one of the existing templates. ShakespeareFan00 (talk) 11:06, 19 February 2015 (UTC)
I think it would be unreasonable to create a new template for every pair of letter and accent that exists, so I think this is a great idea. —User:Beleg Ta͏̂l 2015-02-19 14:51 UTC

Editing/Adding/uploading - Improvement of the Mind

Hello,

The Improvement of the Mind is a text by Issac Watts written in the 1800s. I wanted to type it so that people have a computer copy instead of a scan of the pages of the book.

On Wikisource, I saw that somebody shares a similar interest in writing up the Improvement of the Mind.

The editing/addition of the book is in order of chapter (currently the editing/addition is of Preface Part II on Wikisource). I have the addition for Chapter 9. I want to upload this but cannot. Please help. -- Shawn Kailath (talk) 21:38, 21 February 2015 (UTC)

16:28, 23 February 2015 (UTC)

Help with formatting

Hi Can someone help me with the formatting of the brace here Page:The Olive Its Culture in Theory and Practice.djvu/7? I've tried myself using a table with the help of the templates help page but it doesn't look too good because there is a big space between the two lines. Jpez (talk) 05:32, 24 February 2015 (UTC)

  Done


Wikimania 2015 scholarships

Dear Wikimedians,

Wikimedia Polska Association will fund up to two international scholarships to this year's Wikimania conference, to take place in Mexico City, on July 15-19, 2015, covering air fare, conference fee, accomodation and insurance. See here for information on how to apply for the scholarship, what the requirements are and how to contact us. Feel free to distribute this message to any relevant Wiki pages and mailing lists. On behalf of the WIkimedia Polska Scholarship Commitee, Wpedzich (talk) 19:07, 24 February 2015 (UTC)

Duplicates ?

Index:A PAGE OF AMERICAN HISTORY.pdf and Index:A page of American history (1905).djvu ?

Yes. Should also be taken care of at Commons.--Mpaa (talk) 22:37, 24 February 2015 (UTC)