Wikisource:Scriptorium/Archives/2014-06
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
Recycling a deprecated font template name
I would like to reintroduce the template name "large" for the 110% font size, which is missing from the template family's scale. — Ineuw talk 17:24, 25 May 2014 (UTC)
- Please pardon a but half-remembered recollection. Wasn't the terms "small" and "large" reserved historically for some reason to designate absolute font sizes; whereas the /(x+-)+(smaller|larger)/ set were free for use as relative sizes? This is by no means an objection; rather a request for reassurance that there is not a hidden catch in using the name. AuFCL (talk) 21:19, 25 May 2014 (UTC)
- This is partly a semantic issue with "larger" being a comparative, and partly an issue with the html tag for large being an absolute size (text size 4, or 14 point). As a corollary of the need to prevent confusion with html (and css) the absolute templates were deprecated.
From my own perspective I'm not sure of the need for 110% text. I sometimes have trouble distinguishing "larger" from ordinary and interpolating another size in between would not help my reading flow. Beeswaxcandle (talk) 05:56, 26 May 2014 (UTC)
- +1 to what BWC said. Plus with browsers not being perfect rendering it is not of exceptional value, add in people's fonts, and with changes that WMF introduces ... and it becomes an unnecessary complexity. — billinghurst sDrewth 15:14, 26 May 2014 (UTC)
- No problem. Suggestion dropped. — Ineuw talk 19:53, 26 May 2014 (UTC)
- +1 to what BWC said. Plus with browsers not being perfect rendering it is not of exceptional value, add in people's fonts, and with changes that WMF introduces ... and it becomes an unnecessary complexity. — billinghurst sDrewth 15:14, 26 May 2014 (UTC)
- This is partly a semantic issue with "larger" being a comparative, and partly an issue with the html tag for large being an absolute size (text size 4, or 14 point). As a corollary of the need to prevent confusion with html (and css) the absolute templates were deprecated.
BOT approval requests
Help
Other discussions
A comment on the place of {{nop}}
In proofreading other works, I came across pages where the {{nop}} was placed prior to section codes, page end references, and occasionally followed by a space. Am quite sure that {{nop}} must be placed as the very last line of the page on its own, because anything that follows ends up on the next page. This may not be critical and just poor coding practice with hidden wiki codes, but it affects the following text line if a space follows the template.— Ineuw talk 17:04, 8 April 2014 (UTC)
- I think there was an issue a while back where, it was working inconsistently. I have some memories that imply I may have added it to of the next page to get it working as desired. Then again, I may be remembering incorrectly. JeepdaySock (AKA, Jeepday) 18:52, 8 April 2014 (UTC)
- It may be helpful to avoid fixating upon usage of {{nop}} only at page endings, and think on it more as a directive to the wiki* system that you (the editor) actually know what you are doing at that point and don't want the system/parser second-guessing your intentions. Ironically, MW provides a rarely-used keyword <nowiki/> for precisely this purpose; but it was either unavailable or unknown to the original author of the "do-nothing" template. In its current incarnation (an empty <div>) it actually forces a new line start and so it does not, in fact, "do nothing," and as a result cannot be placed just anywhere without undesirable side-effects; whereas <nowiki/> may be safely used for in-line effects such as 'italic' phrases containing leading single quotes. Try to do that using {{nop}}. (Hint: it won't work!)
In essence there are two distinct and unrelated situations where {{nop}} may be usefully utilised:
- at page endings to enforce a paragraph (traditional usage)
- as a "marker hint" of points where the editor assesses a new paragraph may begin. In this latter use {{nop}} may appear almost anywhere in the text, but typically at points like table-row-ends or line-height changes where mediawiki sometimes does not "take the hint" that a typography change is required. (Special note to Ineuw: I've not experimented with this approach; but I wonder about {{fs90}} et al applications…?)
- AuFCL (talk) 23:51, 8 April 2014 (UTC)
- It may be helpful to avoid fixating upon usage of {{nop}} only at page endings, and think on it more as a directive to the wiki* system that you (the editor) actually know what you are doing at that point and don't want the system/parser second-guessing your intentions. Ironically, MW provides a rarely-used keyword <nowiki/> for precisely this purpose; but it was either unavailable or unknown to the original author of the "do-nothing" template. In its current incarnation (an empty <div>) it actually forces a new line start and so it does not, in fact, "do nothing," and as a result cannot be placed just anywhere without undesirable side-effects; whereas <nowiki/> may be safely used for in-line effects such as 'italic' phrases containing leading single quotes. Try to do that using {{nop}}. (Hint: it won't work!)
- Should have clarified at the beginning of the post I was referring to the end of page use to indicate the beginning of a new paragraph.
- The only two other uses known to me are:
- The start of tables spanning pages.
- It's required at the bottom of a page of page spanning tables which contain a <ref> embedded in one of the cells. Without it the reference goes "haywire".
- Both {{fs90}} (for single paragraphs) and {{fs90/s}}/{{fs90/e}} (enclosing multiple paragraphs) have begin and end padding to distance the enclosed text from the surroundings.— Ineuw talk 02:24, 9 April 2014 (UTC)
- Precisely. Please try, next time you encounter a legitimate use of {{fs90}} (or similar) which might be applied to a couple or more paragraphs on the same page—which normally defeats a single encompassing template use; at least for the first paragraph—this combination: {{fs90|{{nop}}text…}} and indicate the results here. If I encounter one first I undertake to do likewise. I suspect the results might prove satisfactory, but (of course) run the usual risk of being totally wrong…AuFCL (talk) 02:56, 9 April 2014 (UTC)
The reason {{nop}} is called "nop" is because it was created to perform no operation, to do nothing. It was useful in a range of situations e.g. one could separate a single quote from italics using ''{{nop}}'
. It annoys me that this no longer works; that the function of this template no longer matches its original intent; that it is now a template for forcing a paragraph break at the end of a page, which was only ever one of many use cases. It would annoy me even more if we were to take the next logical step and mandate a restrictive set of legitimate uses. Hesperian 05:29, 9 April 2014 (UTC)
I dont recall whether we ever tested <nowiki/>, but it wouldnt have been a good idea. {{nop}} is IMO a more user-friendly syntax (less characters and more understandable), and it allowed its implementation to change as required. Also recall that 'nowiki' is/was used extensively as the means to implement the three content areas (header,body,footer) provided by the Proofread Page extension. I dont recall the circumstances that required this 'quick fix' but it wasnt meant to be permanent, and should be revisited. My vague memory is that either MediaWiki or Proofread Page was altered unexpectedly around that time, and large numbers of our namespace 0 pages were broken, so user:billinghurst and I looked for a quick solution and arrived at <div></div> as the only way to restore the majority of our pages to their correct presentation for readers. There was probably a bug raised around that time, but I cant find it quickly. If the bug still exists, we should experiment with using '<span></span>' instead of using div, as that would mean that the template was once more doing nothing. John Vandenberg (chat) 09:43, 19 May 2014 (UTC)
- It is an old template that has a specific purpose of being a placeholder and has been through renditions to account for the vagaries and quirkiness of Mediawiki and its changes, especially as they relate to transcluded pages. To me it equates to the uses of {{!}}, {{[[Template:{{{1}}}|{{{1}}}]]}} all of which are hacks due to MW quirks. If someone believes, and can demonstrate, that there is a better way to do it, then update it, really, no fuss. It is the whole purpose of it being in a template. Just like any other component. If something is likely to cause a bit of noise, then just tell people, and invite them to the conversation. — billinghurst sDrewth 12:17, 19 May 2014 (UTC)
Accept URAA-affected works?
Hello,
Following requests from 4 Wikimedia chapters, the Wikimedia Foundation has issued a statement that Wikimedia projects can host URAA-affected files unless a DMCA is received. A long debate on Commons concluded that URAA would not be a reason for deleting files, although there is still some discussion how do we implement that. Could we host now these files on the English Wikisource? Yann (talk) 15:55, 28 April 2014 (UTC)
- In keeping with my other comments on the issue across several projects, I Oppose this on moral and legal grounds. The Foundation's opinion doesn't change the fact that it would be illegal. It's not even a grey area; such works are explicitly under copyright. Their stance appears to be "We think we can get away with breaking this law". Laws aren't suggestions and I feel they should be respected. Practically, as a host of English text, English Wikisource is the most likely to get caught if we did decide it was OK to start pirating works. - AdamBMorgan (talk) 19:40, 28 April 2014 (UTC)
- i support transcription of URAA works, but i wouldn’t make it a priority. the worst that could happen is that work is deleted. finding an unknown copyright holder to then print on demand is a win. "pirate" is the smear used by the pro-SOPA folks; i trust you might want to rethink that unfortunate euphemism. but then my bias is well established, i kinda like the Hathi trust. Slowking4♡Farmbrough's revenge 01:07, 29 April 2014 (UTC)
- Oppose -- Largely for the same point(s) given by Adam above. However one labels "the act" does not change the realities at hand either. I'd much rather preserve the credibility we've built over time as a Project to date than chance tarnishing it forever by following any such obviously flawed logic. We simply know better and any inspection of the record will surely reflect that when tested. -- George Orwell III (talk) 02:09, 29 April 2014 (UTC)
- Comment: The WMF has not said that Wikimedia projects can host URAA-affected files. That would indeed be an invitation for us to break the law. What it has said is that the URAA is quite complicated, there are very few URAA-affected works, it can be very difficult to determine with certainty the URAA status of a work, and "[I]t requires information that may not be available to a Commons volunteer trying to make a decision without a takedown notice.... A valid [takedown] notice would provide us with the facts necessary to make a determination under the URAA." So essentially, works that are DEFINITELY under copyright due to the URAA must be taken down; but works that are POSSIBLY, even PROBABLY, under copyright due to the URAA may be left up until clarification of their status is received in the form of a valid takedown notice. Hesperian 04:10, 29 April 2014 (UTC)
- Well that is not what was originally stated nor asked in the initial post of this section. The impression made, at least for me, was that the WMF's policy moving forward was to proactively add works [possibly] in URAA question ontop of retroactively restoring works previously removed for [possible] URAA infraction - taking advantage of the difficulty in "proving" status either way and placing the arrival of a DCMA, or not, as the justification to [continue to] host instead. I pray that was due to some lack of language fluency than anything else and leave it alone.
That said, I don't think anything has changed, has it? It's still up to the intial contributor to provide proper licensing and validate that assertion if & when questioned, no? If so, then (to me) this still sounds like a backdoor attempt to prevent any err on the side of caution logic from entering the debate prior to actual questions of validity being raised. -- George Orwell III (talk) 04:42, 29 April 2014 (UTC)
- I agree, that is not what was originally stated. Which is why I wanted to clarify.
- Our community practice is to delete doubtful works. When nominating a work for deletion, I don't have to prove absolutely that it is copyright-encumbered; I merely have to show that it sure looks like it might be. We err on the side of caution. It seems the WMF are leaving open to us the option, with respect to URAA works only, of erring on the other side — leaving these works up unless and until they receive a takedown notice. Hesperian 05:55, 29 April 2014 (UTC)
- Well that is not what was originally stated nor asked in the initial post of this section. The impression made, at least for me, was that the WMF's policy moving forward was to proactively add works [possibly] in URAA question ontop of retroactively restoring works previously removed for [possible] URAA infraction - taking advantage of the difficulty in "proving" status either way and placing the arrival of a DCMA, or not, as the justification to [continue to] host instead. I pray that was due to some lack of language fluency than anything else and leave it alone.
- Yann would receive a personal benefit from the rapid approval of such URAA works on Wikisource as he proposed. It would prevent a second occasion out of hand where, due to a licensing error on his part, a highly popular large work on Wikisource was first permitted to remain and then become deleted when the error was discovered. Eight hours before he wrote this I discovered this second occasion and reported it on the possible copyright violations page, without mentioning his name or assigning blame to anyone.
- I am troubled by what this suspicious circumstance could signify. It might signify an underhanded attempt to shield his reputation. And it might signify that he no longer trusts the members of Wikisource to render judgment on his conduct fairly and discreetly. Under these circumstances, as Yann is up for confirmation this month, I am withdrawing my approve vote and changing it to neutral until such time as he provides an suitable explanation for this strangely advanced proposal. ResScholar (talk) 07:49, 29 April 2014 (UTC)
- Probable chain of events: 1. Yann posts work in good faith. 2. ResidentScholar requests it for deletion based on URAA. 3. Yann sees deletion request, is disappointed that a work they contributed may be deleted. 4. Yann investigates, learns all about URAA, discovers that the issue is controversial in the Wikimedia community, discovers that some projects are now allowing such works, realises that his work may not need to be deleted after all. 5. Yann asks the community "Could we host now these files on the English Wikisource?" — surely a pertinent question in light of the proposed deletion. I'm not seeing anything 'suspicious' or 'underhanded' or otherwise troubling here. It is perfectly normal for general policy discussions to be triggered by specific issues. Hesperian 08:38, 29 April 2014 (UTC)
- I have to admit I had forgotten the first occasion was a URAA case. That was back in 2009. After I get some rest, I'll think about the situation some more. ResScholar (talk) 09:48, 29 April 2014 (UTC)
- here’s some context: we don’t allow people to undo their creative commons licenses; we don’t allow institutions to put copyright on photos of public domain 2D works under a "sweat of the brow" rubric; we do take down FoP germany photos of statues under a DMCA. but "We simply know better" & "err on the side of caution" = no, IANAL; i do not know better; i make errors regardless of how cautious i am = i invite you to join in the spirit of ignorance, uncertainty and doubt; rely on the discretion of the foundation legal department: it’s their reputation and trademark. Slowking4♡Farmbrough's revenge 11:10, 29 April 2014 (UTC)
- With sweat of the brow, it's not a matter of us allowing something or not. United States case law (I think Feist Publications v. Rural Telephone Service) established that sweat of the brow is insufficient to establish copyright. It, like the URAA, is the law; not a project policy. Freedom of Panorama is a Commons thing, and I've never looked into it strongly, but that may also be a legal rather than policy concern, although Commons does apply policies above and beyond their legal requirements. It's not as if the URAA is that complicated. I've definitely run into worse copyright issues on Wikisource. - AdamBMorgan (talk) 13:39, 29 April 2014 (UTC)
- well, we told the national portrait gallery london to get stuffed with their sweat of the brow argument under UK law. (so much for honoring foreign law as well as US) this is the essence of the c:Commons:When to use the PD-Art tag; with the FoP germany the foundation took down photos of sculptures in germany after a DMCA takedown from a US attorney. so, they have gone both ways, but my conclusion is that they have last word, why not defer to them, it’s so much easier. the amateur lawyering is a waste of time. they assess the legal risk under international law, and they rely on the DMCA safe harbor. don’t know why we shouldn’t. Slowking4♡Farmbrough's revenge 02:52, 1 May 2014 (UTC)
- We haven't concerned ourselves with the URAA aspects of works to this point, and I think that we continue to evaluate works on a case by case basis. The URAA primarily affects UK, Canada and Australian published works from the late 1920s and 1930s where the author died prior to 1938, so it is a small area. I think that we would be better to deal with them when they appear, and being wise to them. That may lead to a firmer policy when we have some case studies. — billinghurst sDrewth 13:41, 29 April 2014 (UTC)
- With sweat of the brow, it's not a matter of us allowing something or not. United States case law (I think Feist Publications v. Rural Telephone Service) established that sweat of the brow is insufficient to establish copyright. It, like the URAA, is the law; not a project policy. Freedom of Panorama is a Commons thing, and I've never looked into it strongly, but that may also be a legal rather than policy concern, although Commons does apply policies above and beyond their legal requirements. It's not as if the URAA is that complicated. I've definitely run into worse copyright issues on Wikisource. - AdamBMorgan (talk) 13:39, 29 April 2014 (UTC)
- here’s some context: we don’t allow people to undo their creative commons licenses; we don’t allow institutions to put copyright on photos of public domain 2D works under a "sweat of the brow" rubric; we do take down FoP germany photos of statues under a DMCA. but "We simply know better" & "err on the side of caution" = no, IANAL; i do not know better; i make errors regardless of how cautious i am = i invite you to join in the spirit of ignorance, uncertainty and doubt; rely on the discretion of the foundation legal department: it’s their reputation and trademark. Slowking4♡Farmbrough's revenge 11:10, 29 April 2014 (UTC)
- I have to admit I had forgotten the first occasion was a URAA case. That was back in 2009. After I get some rest, I'll think about the situation some more. ResScholar (talk) 09:48, 29 April 2014 (UTC)
- Probable chain of events: 1. Yann posts work in good faith. 2. ResidentScholar requests it for deletion based on URAA. 3. Yann sees deletion request, is disappointed that a work they contributed may be deleted. 4. Yann investigates, learns all about URAA, discovers that the issue is controversial in the Wikimedia community, discovers that some projects are now allowing such works, realises that his work may not need to be deleted after all. 5. Yann asks the community "Could we host now these files on the English Wikisource?" — surely a pertinent question in light of the proposed deletion. I'm not seeing anything 'suspicious' or 'underhanded' or otherwise troubling here. It is perfectly normal for general policy discussions to be triggered by specific issues. Hesperian 08:38, 29 April 2014 (UTC)
- Reluctantly Oppose. I know of no need to transclude works from Wikisource to outside, so sending URAA-affected works to Canadian Wikilivres should be better. How to deal with them at Commons is much more tricky due to transcluding issues, so I would assume good faith of Yann. However, when waiting for DMCA take-down notice may not be good for long term, using Template:Bibliowiki_page to redirect may be legally better.--Jusjih (talk) 06:26, 30 April 2014 (UTC)
- Oppose There's not a lot of question on most works about whether the URAA would cover them. Virtually all English works not published in the US prior to 1978, and probably up to 1989 in most cases, would be out of copyright and the URAA would have restored them. That's an enormous range of works, and if we ignore the URAA, there's no legal reason under US law to exclude them.--Prosfilaes (talk) 09:36, 22 May 2014 (UTC)
Some page images not displaying
It might just be me, but every couple of pages in Vanity Fair I'm getting errors with loading the page images. E.g. p.533:
"NetworkError: 500 Internal server error - https://upload.wikimedia.org/wikipedia/commons/thumb/c/c5/Vanity_Fair_1848.djvu/page533-1024px-Vanity_Fair_1848.djvu.jpg"
The error is "Error generating thumbnail". Does this image display for other people? I've tried with different browsers.
Thanks! — Sam Wilson ( Talk • Contribs ) … 23:15, 29 April 2014 (UTC)
- I, too, am not loading pages. In my case, they are from the Dictionary of National Biography. ResScholar (talk) 01:12, 30 April 2014 (UTC)
- On my browser both our pages are back (...but for how long?!?). ResScholar (talk) 09:41, 30 April 2014 (UTC)
- Raised by frWS yesterday, see bugzilla:64622 an any commentary that may be useful in assisting. I believe that a code upgrade has been put into place, though unsure when it will rollout. — billinghurst sDrewth 14:16, 30 April 2014 (UTC)
Is the bizarre overlap of page texts on this page a related issue? I've never seen that happen before. --EncycloPetey (talk) 16:09, 2 May 2014 (UTC)
- Nope. That is the effect after a "recent" change to the Proofread Page extension and the certain use of Sidenotes coflicting with it afterwards. -- George Orwell III (talk) 00:41, 3 May 2014 (UTC)
Where did the book go
Where did this book go?
Index:The American Indian.djvu
This was PotM, and now nothing displays on that page! --EncycloPetey (talk) 16:11, 2 May 2014 (UTC)
- It says "Template include size is too large". Maybe converting all those {{dotted TOC page listing}} templates in the contents to tables might help. —Clockery Fairfeld (ƒ=ma) 16:28, 2 May 2014 (UTC)
- ??? It was never a problem before. Did template limitations change recently? --EncycloPetey (talk) 17:19, 2 May 2014 (UTC)
- Well, I wouldn't exactly say "never a problem before"; just one always flirting with the resource limit(s) when {{Dotted TOC page listing}} is applied. This case is different however; the mainspace transclusion displays both the TOC and List of illustrations just fine so the "problem" is primarily with the Proofreading extension itself and its reliance/usage of the MediaWiki:Proofreadpage index template in addition to the application of the Dotted TOC template.
I noted the issue back in January and tried to wrangle that faux template's resource usage back down a bit - with some succcess - but changes elsewhere in the extension itself since then seem to have negated those savings once again. Discussion was already in progress concerning the "deconstruction" of the original PR scheme but the needed core changes concerning the entire Index namespace approach & template never made it into the code. I don't know what else to do about focusing on that overhaul either.
I also tried coming up with a less-resource hungry {{SimpleLeader}} as an alternative to the current monster but it never got the interest needed to insure it as a viable replacement and still sits in "beta" limbo. Sorry I couldn't have been more help with this - it bothered the heck out of me back in January when I first noticed it as well. -- George Orwell III (talk) 00:41, 3 May 2014 (UTC)
- Well, I wouldn't exactly say "never a problem before"; just one always flirting with the resource limit(s) when {{Dotted TOC page listing}} is applied. This case is different however; the mainspace transclusion displays both the TOC and List of illustrations just fine so the "problem" is primarily with the Proofreading extension itself and its reliance/usage of the MediaWiki:Proofreadpage index template in addition to the application of the Dotted TOC template.
- I've converted the pages to two tables—one for contents and the other for the illustrations and it's now displaying fine.
In digging around in the code of {{Dotted TOC page listing}} I see that it creates a table for each invocation and calls a few templates as well. I suspect that creating ca. 450 tables for the TOC alone on the Index page along with whatever the pagelist tag does would have tipped the balance. Beeswaxcandle (talk) 05:42, 3 May 2014 (UTC)
- I've converted the pages to two tables—one for contents and the other for the illustrations and it's now displaying fine.
- Thanks for that, as it's one of the works I use as reference for how to do things. Note however, that chapter VII in the table is not showing up in transclusion. --EncycloPetey (talk) 05:55, 3 May 2014 (UTC)
- Fixed. It was a nop in the wrong place on the page before. Beeswaxcandle (talk) 06:02, 3 May 2014 (UTC)
New paragraph at beginning of page
The default behavior for transclusion is to just add a space between the text of two pages, even when there should be a paragraph break. All I could find on the subject is a discussion from like six years ago. What is the current method for handling a new paragraph at the beginning of a page? Heyzeuss (talk) 04:56, 3 May 2014 (UTC)
- Put a {{nop}} on a line by itself at the end of the prvious page. Beeswaxcandle (talk) 05:06, 3 May 2014 (UTC)
- Thanks. Heyzeuss (talk) 05:44, 3 May 2014 (UTC)
- @Heyzeuss: We do mention the use in some help pages, though seemingly not where you were reading. Feel free to, in fact please, add some suitable text to the pages that you were reading that indicates the use of the template. I know that I have added it to numerous user talk pages over time. — billinghurst sDrewth 03:00, 15 May 2014 (UTC)
- @Heyzeuss: Also to note that we have a gadget that enables you to add the template to a prior page. — billinghurst sDrewth 03:59, 15 May 2014 (UTC)
- Got it, thanks. :) Heyzeuss (talk) 04:01, 15 May 2014 (UTC)
- I've added it to Help:Page breaks. Heyzeuss (talk) 04:43, 15 May 2014 (UTC)
- Got it, thanks. :) Heyzeuss (talk) 04:01, 15 May 2014 (UTC)
- @Heyzeuss: Also to note that we have a gadget that enables you to add the template to a prior page. — billinghurst sDrewth 03:59, 15 May 2014 (UTC)
- @Heyzeuss: We do mention the use in some help pages, though seemingly not where you were reading. Feel free to, in fact please, add some suitable text to the pages that you were reading that indicates the use of the template. I know that I have added it to numerous user talk pages over time. — billinghurst sDrewth 03:00, 15 May 2014 (UTC)
- Thanks. Heyzeuss (talk) 05:44, 3 May 2014 (UTC)
Latest tech news from the Wikimedia technical community. Please inform other users about these changes. Not all changes will affect you. Translations are available.
Recent software changes
- The latest version of MediaWiki (1.24wmf3) was added to test wikis and MediaWiki.org on May 1. It will be added to non-Wikipedia wikis on May 6, and all Wikipedias on May 8 (calendar).
- The Compact Personal Bar was added as a beta feature to test wikis and MediaWiki.org on May 1. It will be added as a beta feature to non-Wikipedia wikis on May 6, and to all Wikipedias on May 8. To test it, you can enable it now in your preferences on MediaWiki.org. [1]
- It is now easier to disable the CodeEditor tool. [2]
VisualEditor news
- External links in VisualEditor are now in the same light blue color as in MediaWiki. [3]
- The template tool now tells you if a parameter is obsolete. [4]
- You can now add "suggested" parameters in TemplateData; VisualEditor will add them like required ones. [5]
- There is a new type for TemplateData parameters:
wiki-file-name
for file names. [6][7] - Editing formulae in VisualEditor will soon be enabled for all users. [8] [9]
- You will soon be able to try a new beta feature to edit text in another language. [10] [11]
Future software changes
- MediaViewer will be enabled for all users on the Japanese (ja), Portuguese (pt), Spanish (es), Swedish (sv) and Telugu (te) Wikipedias on May 8. Feedback is welcome. [12]
- You can help translate about 100 new language names that have been added to our data source. They are used, for example, as hover text for interwiki links. Send an e-mail to Nemo if you want to help.
- If you click on a redirect page in your watchlist, you will soon access the redirect itself. [13] [14]
Problems
- For about 40 minutes around 00:20 UTC on April 29, there were problems with page loading due to high server load.
Tech news prepared by tech ambassadors and posted by MediaWiki message delivery • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.
07:29, 5 May 2014 (UTC)
Is copyright violation really the only problem with this text? I am asking as there is a ticket in OTRS ticket:2014050810001396 and I have no idea how to handle it. It is incomplete at the moment, but it can be resolved. I would appreciate if sb from the community can handle it. Ankry (talk) 08:18, 8 May 2014 (UTC)
- Addressed at Wikisource:Possible_copyright_violations#School_Song_of_New_R._S._J._Public_School. Jeepday (talk) 08:34, 10 May 2014 (UTC)
Latest tech news from the Wikimedia technical community. Please inform other users about these changes. Not all changes will affect you. Translations are available.
Recent software changes
- The latest version of MediaWiki (1.24wmf4) was added to test wikis and MediaWiki.org on May 8. It will be added to non-Wikipedia wikis on May 13, and all Wikipedias on May 15 (calendar).
VisualEditor news
- A new citation system in VisualEditor was enabled on the English Wikipedia. It will soon be enabled on more wikis. [15]
- Templates that were previously broken in VisualEditor should now appear correctly. [16]
Future software changes
- It will soon be possible to move category description pages. Pages in changed categories will still have to be moved independently. [17] [18]
- You will soon be able to clear your watchlist with one click or through the API. [19] [20] [21] [22]
- You will soon be able to link to Flow posts and workflows with
Special:Flow
. [23] [24] - The jQuery JavaScript library will soon be updated. Please check that your gadgets and scripts will still work. [25]
- The Vector skin will work faster, as the sidebar will no longer collapse partly after being loaded. [26] [27] [28]
- MediaViewer will be enabled for all users on Wikimedia Commons on May 15. Feedback is welcome.
- An IRC discussion about Phabricator will take place on May 14 at 18:00 UTC on the channel
#wikimedia-office
on freenode (time conversion). [29] - Toolserver tools will be stopped on June 30. Please make sure to change gadgets that link to the Toolserver to point to Tool Labs instead. [30]
Problems
- There were problems with generating file thumbnails for all wikis between May 3 and May 6 due to a configuration error. [31] [32]
Tech news prepared by tech ambassadors and posted by MediaWiki message delivery • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.
06:00, 12 May 2014 (UTC)
Gulliver's Travels
I've been looking for a First Edition Gulliver's Travels by Swift to replace the unsourced copy of unknown origin we currently have. First editions of this work seem to be very hard to find. Most copies that I've found date circa 1900 or are adapted for school use (or both).
I think I have found a first edition, but it isn't marked as such by the Internet Archive. Would a couple of people please take a look at the copy I've found and let me know what they think? If it isn't a first edition, it might be a facsimile of the same, which could be just as good for our purposes.
The only irregularities I found were in the map located between pages 170 and 171 (of the book), which seems not to have been scanned properly. If that's the only problem, we can probably find a better copy somewhere else.
Opinions please? --EncycloPetey (talk) 02:03, 13 May 2014 (UTC)
- The maps @ 170/171 are only slightly better in the original GoogleBooks scan [33] but at least "seem" to be complete. I don't know what other "free" copies of the 1742 printing are out there; I could not locate any (I'm in the u.s. fwiw). -- George Orwell III (talk) 22:00, 13 May 2014 (UTC)
- OK then. Based on the above (and below) information, this looks like a good first edition from which to work. I'll try to get everything ready to start proofreading it by early June. (I want to at least try to finish one of my other projects here prior to starting this one). We definitely need more 18th century works, and the first edition of Gulliver is one that's hard to come by. --EncycloPetey (talk) 02:39, 14 May 2014 (UTC)
current editions of Gulliver
Currently, we have at least two editions of Gulliver's Travels (that I know of).
One is The Works of the Rev. Jonathan Swift/Volume 6, which is sourced and is part of a multivolume collection of Swift's works. However, it is not linked from the Author page for Swift.
The other is Gulliver's Travels, which is linked from the Author page, but is not sourced. It does, however, contain audio files for at least the first part (Voyage to Lilliput) that the sourced edition does not have.
Additionally, there is no disambiguation page for this work, and I'm not sure what to call it, since:
- (a) Gulliver's Travels is currently a structural mess that we might not even keep.
- (b) The work was not actually titled Gulliver's Travels. Rather, that is a standard shorter title used for the work, whose original title page reads "Travels into several Remote Nations of the World. In Four Parts. By Lemuel Gulliver."
The first edition is labelled "fourth edition" and has notes claiming errors on the part of previous publishers, but this is merely additional humor on the part of Swift about editorial license of publishers.
Recommendations on what to do? --EncycloPetey (talk) 03:49, 13 May 2014 (UTC)
- The "additional humor" appeared in the second edition, and was a crack at the publisher of the first addition, who removed some passages without Swift's authorization, out of fear of political reprisal. The fact that the scan you've linked to doesn't include it is a strong argument for it being a first edition. You need a {{versions}} page, not a disambiguation page. Generally you would throw away the unsourced copy if and only if it is redundant to the sourced copy; i.e. substantially the same text. See The Tenant of Wildfell Hall for an example of a versions page where an unsourced Project Gutenberg text has been kept because it represented a substantially different text to the sourced edition. Susanarb is currently working through The Works of the Rev. Jonathan Swift; she is moderately new to Wikisource and probably just overlooked the need to link from Swift's author page. Hesperian 04:18, 13 May 2014 (UTC)
- Did not mean to appear to impugn the wonderful work Susanarb is doing. The bit about not linked was procedural, to provide full information in case anyone went looking at the links there. --EncycloPetey (talk) 04:51, 13 May 2014 (UTC)
- Thank you to both of you! After I finished the Travels, I knew that I needed to do disambiguation pages for that work as well as a number of other works that were based on other sources. But I got side-tracked, and moved on to proofreading other volumes. I have a detailed chart with notes about what I have and haven't done, and will go back someday to clean up Swift's author page. I'm going much slower these days with the Journal to Stella, as I have been doing the links to people, places, and other things referenced while I'm proofreading. In the end, I think it will be faster, as I'll only need to return to Volume 15 to add a few links to works that are in volumes that aren't proofed yet.
- But I definitely agree that the author page for Swift needs a lot of work. If one of you, or anyone else, would like to take it on, please do. But if you don't, I do intend to fix it all up before I'm done with the good Dean. Susan Susanarb (talk) 23:34, 13 May 2014 (UTC)
Wikisource meetup at Wikimania 2014
Wikimania 2014 will be held in London this August and it will be a great opportunity to discuss how to use the recently created Wikisource Community User Group to coordinate and to better promote Wikisource. We would like to invite the participants of each Wikisource language community to showcase the projects has been working in the past year and, of course, learn from each other experiences. See you there? Sign up in the meeting page.
—The preceding MassMessage was sent by Micru on behalf of the Wikisource Community User Group.--06:59, 13 May 2014 (UTC)
Sidebar menus no longer collapse
I see this was by design per the last TechNews notice just above. Personally, I see no difference in "Vector speed" and rather have them collapse if I want them collapsed and vise versa. Anyone else feel the same way? -- George Orwell III (talk) 22:21, 13 May 2014 (UTC)
- I came here to say 'thank you very much' to whoever worked the technical magic that ensures my Scripts sidebar menu is already open when I create a page! Hesperian 01:17, 15 May 2014 (UTC)
- Fwiw... the proper behavior for all sidebar menus was to open or close pending the last usage of that particular menu. If you opened a menu in previous session it should be opened in the next session of the same circumstance. If it wasn't working like that before, something else is/was out-of-whack or obsolete in your case. -- George Orwell III (talk) 21:02, 16 May 2014 (UTC)
- If you are calling for votes upon this (and of course if you are confident it will not overly tax your time and skill) then yes, please: I Support restoring the collapsing feature. AuFCL (talk) 10:39, 14 May 2014 (UTC)
- Keep the default as the default, and have a gadget for the option to collapse, with the gadget off as the default. If WMF has done the work and research to make a change based on their usability data, we probably should heed that work. — billinghurst sDrewth 02:50, 15 May 2014 (UTC)
- That would be just fine except both the top action tabs & the sidemenus are bastardized in the sense a MediWiki message or .js file dictates display order or manner rather than the skin itself - this is the crux of the problem. Its not a pure skin nor a pure extension. Removing the script only affects load speed; it resolves nothing towards the real issue however.
Judging by the overall negative reaction to the change so far, this might have merely been the needed catalyst made in the interim on a renewed path to a real fix. I'm going to hold off on asking for any local fix such as the mentioned gadget until this plays out some more. -- George Orwell III (talk) 21:02, 16 May 2014 (UTC)
- Well a quick & proper resolution seems unlikely so I've followed Edtoker's lead and Gadgetized the collapsible sidebar menu until the extension/skin/message thing gets sorted out by the coders (Vector only). See the Interface section in your Gadget's tab of your User Preferences. I left the default as Off but the original speed & load argument no longer applies as the scheme now utilizes resource loader (well at least as far as my setups go - I see no difference or hit either way) as opposed to before the change. Ultimately I guess usage should dictate the default state given some time for "absent" Users returning and the like. -- George Orwell III (talk) 01:05, 22 May 2014 (UTC)
- That would be just fine except both the top action tabs & the sidemenus are bastardized in the sense a MediWiki message or .js file dictates display order or manner rather than the skin itself - this is the crux of the problem. Its not a pure skin nor a pure extension. Removing the script only affects load speed; it resolves nothing towards the real issue however.
- Keep the default as the default, and have a gadget for the option to collapse, with the gadget off as the default. If WMF has done the work and research to make a change based on their usability data, we probably should heed that work. — billinghurst sDrewth 02:50, 15 May 2014 (UTC)
Leaders (dots) in table
Hello. Would it be desirable to add leaders (dots) to Page:Lake Ngami.djvu/384, to better approximate the original table? I'm not sure it is worth the effort to do so. If it is, should the TOC dots template be used? User:Djr13 and User:Rastus Vernon discussed this with me on IRC. PiRSquared17 (talk) 02:41, 14 May 2014 (UTC)
- Such esthetics are entirely up to you, especially if you like to gain experience with dot leaders. IMHO, the TOC is already nicely executed.— Ineuw talk 06:41, 14 May 2014 (UTC)
- Currently, none of the in-text tables (like this one) use TOC dots. Most of them do not need them, and this one really doesn't either, now that the font size has been adjusted. --EncycloPetey (talk) 14:48, 14 May 2014 (UTC)
- +1 to EncycloPetey, maintain an existing style. I only use dotleaders where there is a clear advantage. That I don't particularly like dotleaders doesn't, means that I don't particularly see that advantage and I prefer to narrow the width of the table to suit. When people use them with 100% width, and you have a wide screen, they are horrid, though better than nothing. — billinghurst sDrewth 02:55, 15 May 2014 (UTC)
Hathi Trust book wanted
Enterprise and adventure. A collection of interesting anecdotes. by Ralph and Chandos Temple. 1870 [34] If anyone has a login there, could you get this for me please? Moondyne (talk) 14:03, 18 May 2014 (UTC)
I am willing to download those 256 .pdf pages for you Moondyne. After placing them into one .pdf file it would have to be placed on IA to be derived into a .djvu file and then downloaded then uploaded to Commons. But cannot you do the same? Respects, —Maury (talk) 05:05, 19 May 2014 (UTC)
- Moondyne is in Australia (like me). Most of the Hathi Trust archive is unavailable to us. Hesperian 05:36, 19 May 2014 (UTC)
- After e/c. Yes I could do that but I was hoping you might have the ability to download the whole book as one pdf. To do that it says "partner login required." Moondyne (talk) 05:38, 19 May 2014 (UTC)
- I could not ask you to download 256 individual pdfs. In fact, if that was the only way I wouldn’t bother. Moondyne (talk) 05:50, 19 May 2014 (UTC)
- We just had an edit conflict so I lost my long-winded speech. I know of Joe Moondyne and his Australian escapes through our Moondyne here. I would try to escape from Australia too! <smile> I do not have full access to HathiTrust but I will download the book pdf by pdf so let us not do this at the same time. Okay? I consider both of you as friends. I am age 67 as of May 12 and have all the time in the world. Clockery sent me a half-eaten sour lemon cake and that almost killed me. <smile> —Maury (talk) 06:12, 19 May 2014 (UTC)
- P.S. If anyone else wants to have some of that cake, they are welcome to have some from here. And by the way, Maury, what does not kill you, makes you stronger. [Nietzche was wrong!—Maury (talk) 11:45, 19 May 2014 (UTC)] ;) Best regards,—Clockery Fairfeld (ƒ=ma) 06:36, 19 May 2014 (UTC)
- Belated happy birthday to you! I wont be downloading them Maury. It would be an interesting book and if you want to then go ahead. Perhaps defer for a day or two in case someone watching has a "partner login". Moondyne (talk) 06:21, 19 May 2014 (UTC)
- Moondyne, your desired book is in the oven cooking now. All .pdf pages downloaded one by one and each has all watermarks removed. It is all one .pdf A djvu file is being derived at this moment. https://archive.org/details/EnterpriseAndAdventure The name of the file will be Enterprise and Adventure.djvu Kindest regards, —Maury (talk) 11:45, 19 May 2014 (UTC)
- So quick! You are a gentleman and a scholar. Moondyne (talk) 15:31, 19 May 2014 (UTC)
- Moondyne, your desired book is in the oven cooking now. All .pdf pages downloaded one by one and each has all watermarks removed. It is all one .pdf A djvu file is being derived at this moment. https://archive.org/details/EnterpriseAndAdventure The name of the file will be Enterprise and Adventure.djvu Kindest regards, —Maury (talk) 11:45, 19 May 2014 (UTC)
- Belated happy birthday to you! I wont be downloading them Maury. It would be an interesting book and if you want to then go ahead. Perhaps defer for a day or two in case someone watching has a "partner login". Moondyne (talk) 06:21, 19 May 2014 (UTC)
- I could not ask you to download 256 individual pdfs. In fact, if that was the only way I wouldn’t bother. Moondyne (talk) 05:50, 19 May 2014 (UTC)
Latest tech news from the Wikimedia technical community. Please inform other users about these changes. Not all changes will affect you. Translations are available.
Tech News updates
- Tech News is one year old this week; thank you for being with us!
Recent software changes
- The latest version of MediaWiki (1.24wmf5) was added to test wikis and MediaWiki.org on May 15. It will be added to non-Wikipedia wikis on May 20, and all Wikipedias on May 22 (calendar).
- The jQuery JavaScript library was updated on May 16. Please check that your gadgets and scripts still work. [35] [36] [37]
- MediaViewer was enabled for all users on the Kannada (kn) and Telugu (te) Wikipedias on May 13. It will be enabled on the German (de), English (en), Italian (it) and Russian (ru) Wikipedias and on all Wikisource wikis on May 22. Feedback is welcome. [38] [39]
- VisualEditor was added as a beta feature to Wikimedia Commons on May 15. You can enable it in your preferences. [40] [41]
- You can read a summary of the Wikimedia technical report for April 2014.
VisualEditor news
- VisualEditor's buttons and icons can now be accessed using keyboard keys. [42] [43]
- VisualEditor's new citation tool now matches templates like
{{cite_web}}
and not just{{Cite web}}
. [44] [45] - VisualEditor's welcome message will no longer be shown to users who have already seen it. [46] [47]
- VisualEditor now shows a clearer message when you cancel an edit. [48]
- The toolbar of the PageTriage extension will no longer be visible inside VisualEditor. [49] [50]
Future software changes
- User ID number will no longer be visible in preferences. [51] [52]
Problems
- For several hours on May 16, there were problems with loading gadgets on some wikis due to a server problem. [53]
Tech news prepared by tech ambassadors and posted by MediaWiki message delivery • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.
07:18, 19 May 2014 (UTC)
This template was created last year and has only the statement "Under Construction". It is being used, and looks useful, but would need more experienced eyes to verify its syntax and write documentation. --EncycloPetey (talk) 04:03, 20 May 2014 (UTC)
- What, please, is the real issue here? If you are proposing a blitz on all undocumented templates then I for one am all in favour. However, what is the specific interest in this particular template? It looks fairly straightforward, works and is currently used in only a manageable number of cases. Finally: what makes you think there may be problems with its syntax? AuFCL (talk) 23:35, 20 May 2014 (UTC)
- No, no, I'm asking for an either-or. Either the template is a duplicate / unnecessary / unwanted / badly structured and should be deleted, or it should be kept, have its syntax checked for workability, and be properly documented. I don't know which, so I've posted here. I don't have a strong opinon on keep / delete, but do feel that if we are going to use it, then it should be properly checked and documented. --EncycloPetey (talk) 00:41, 21 May 2014 (UTC)
- Thank you for clarifying. That is a very different interpretation upon what I thought you were originally asking for. If the author User:Abjiklam doesn't mind and/or doesn't get around to documenting the thing in the next week or so I am happy to give it an attempt. As I stated above, it is reasonably straight forward with the sole exception parameter 3 is not currently used in any extant invocation, and so I am uncertain as to the specific intended application of this parameter alone. I am unaware of another template entirely duplicating this function; the name chosen seems appropriate; and the internal logic is sound. Obviously some kind of write-up would be nice, however personally I would vote this a good attempt at a useful function and well worthwhile keeping… AuFCL (talk) 08:59, 21 May 2014 (UTC)
- I work with User:Abjiklam on that book off and on, but he hasn't been around for awhile. I will be returning to that project soon to continue proofreading and deal with the template issue. Will report back whether it's worth keeping it or not. In the meanwhile, I will bookmark the page to remind me. — Ineuw talk 03:26, 23 May 2014 (UTC)
- Thank you for clarifying. That is a very different interpretation upon what I thought you were originally asking for. If the author User:Abjiklam doesn't mind and/or doesn't get around to documenting the thing in the next week or so I am happy to give it an attempt. As I stated above, it is reasonably straight forward with the sole exception parameter 3 is not currently used in any extant invocation, and so I am uncertain as to the specific intended application of this parameter alone. I am unaware of another template entirely duplicating this function; the name chosen seems appropriate; and the internal logic is sound. Obviously some kind of write-up would be nice, however personally I would vote this a good attempt at a useful function and well worthwhile keeping… AuFCL (talk) 08:59, 21 May 2014 (UTC)
- No, no, I'm asking for an either-or. Either the template is a duplicate / unnecessary / unwanted / badly structured and should be deleted, or it should be kept, have its syntax checked for workability, and be properly documented. I don't know which, so I've posted here. I don't have a strong opinon on keep / delete, but do feel that if we are going to use it, then it should be properly checked and documented. --EncycloPetey (talk) 00:41, 21 May 2014 (UTC)
- O.K. I've made up an "outsider's view" of documentation for {{ditto}}. If I have missed any subtleties and/or this description is overly functional please all feel free to generally rip/rend/improve as the whim takes you. AuFCL (talk) 03:54, 25 May 2014 (UTC)
- I see two issues with the template. As far as I know, on WS we use the standard double quote (") ANSI 0034. The template uses the Central European languages' opening quote symbol which is vertically positioned on the baseline. The second issue is that the symbol appears left aligned when it should be centered. — Ineuw talk 06:50, 25 May 2014 (UTC)
- Of course, I entirely agree. However, I was trying to be careful not to disrupt existing usage (all four cases! count them!) which might depend upon these chosen defaults. I was really hoping Abjiklam might be free to state his position/assumptions before rocking the boat further. AuFCL (talk) 08:17, 25 May 2014 (UTC)
- I also hope that he'll be back. I will keep using the ANSI 0034 double quote in a centered table column.— Ineuw talk 20:00, 26 May 2014 (UTC)
Hi all. Sorry I’m not very active lately. I’m still not entirely sure my attempt at making a ditto template is useful. The idea is to make it easier to place ditto marks properly. Ideally, it should work regardless of the font, and it should prevent editors from figuring out the exact width of {{gap}}s. I welcome any edit that might improve the template.
The reason I used curly marks sitting on the baseline is because they are the ones used in the book I transcribed and, frankly, I find straight quotes hideous in a text.
The template is still not perfect. It works well where in some cases such as here and here, but other attempts at using it (here for example) are not ideal.
I don’t have much time to work on it at the moment, but feel free to play around with it. Abjiklɐm (tɐlk) 22:34, 26 May 2014 (UTC)
Images failure
Circa UTC 04:35 - 04:40 all images ceased to load on Wikisource. No jpgs, no djvu, not even the Wikisource icon in the top left of the screen. --EncycloPetey (talk) 04:47, 22 May 2014 (UTC)
Further info: the problem is limited to MediaWiki sites, but is browser specific (Safari). I can see the images using FireFox, but FireFox has other problems. :( --EncycloPetey (talk) 05:58, 22 May 2014 (UTC)
- Have you already tried to bypass your browser cache? Don't have a Safari to test with... --AKlapper (WMF) (talk) 03:08, 23 May 2014 (UTC)
- That would cause more havoc than it's worth.
- I'm relying on FireFox for now, and may transfer all my bookmarks and such over. It's just a pain for editing because FireFox has a less pleasant font; I can't get as much text on a line while editing; and I can't figure out how to turn off the spellcheck lines (ick!). Safari did the same thing to me a few weeks ago with YouTube; none of the thumbnails would display; I couldn't activate "About" or add videos to playlists. The problem has since mysteriously corrected itself, but I'm not betting on it continuing to function well.
- You can turn off the spellcheck lines under the Tools menu, Options, Advanced section, General subsection. Beeswaxcandle (talk) 04:37, 23 May 2014 (UTC)
- I was hoping to hear from other Safari users to find out whether it might be the browser. I hope it's not my computer. --EncycloPetey (talk) 03:20, 23 May 2014 (UTC)
- I'm relying on FireFox for now, and may transfer all my bookmarks and such over. It's just a pain for editing because FireFox has a less pleasant font; I can't get as much text on a line while editing; and I can't figure out how to turn off the spellcheck lines (ick!). Safari did the same thing to me a few weeks ago with YouTube; none of the thumbnails would display; I couldn't activate "About" or add videos to playlists. The problem has since mysteriously corrected itself, but I'm not betting on it continuing to function well.
- It's OK with Safari 7.0.4 Mac using OS X Mavericks 10.9.3 --kathleen wright5 (talk) 03:47, 23 May 2014 (UTC)
Media Viewer
Greetings, my apologies for writing in English.
I wanted to let you know that Media Viewer will be released to this wiki in the coming weeks. Media Viewer allows readers of Wikimedia projects to have an enhanced view of files without having to visit the file page, but with more detail than a thumbnail. You can try Media Viewer out now by turning it on in your Beta Features. If you do not enjoy Media Viewer or if it interferes with your work after it is turned on you will be able to disable Media Viewer as well in your preferences. I invite you to share what you think about Media Viewer and how it can be made better in the future.
Thank you for your time. - Keegan (WMF) 21:29, 23 May 2014 (UTC)
--This message was sent using MassMessage. Was there an error? Report it!
Latest tech news from the Wikimedia technical community. Please inform other users about these changes. Not all changes will affect you. Translations are available.
Recent software changes
- The latest version of MediaWiki (1.24wmf6) was added to test wikis and MediaWiki.org on May 22. It will be added to non-Wikipedia wikis on May 27, and all Wikipedias on May 29 (calendar).
- MediaViewer will be enabled on all Wikisource wikis on May 29, and on the German (de) and English (en) Wikipedias on June 3. Feedback is welcome.
VisualEditor news
- VisualEditor's welcome message and wikitext warning now say that you can switch to source mode editing and keep your edits without saving them. [54] [55] [56] [57]
- A bug that caused files not to appear after saving edits in the
File:
namespace was fixed last week. [58] [59] - VisualEditor tabs will no longer appear in namespaces where VisualEditor is disabled. [60] [61]
- It is now possible to edit inline images with VisualEditor; many minor bugs related to images have also been fixed. [62]
- VisualEditor will no longer convert spaces to underscores inside links to pages in namespaces that include spaces in their names. [63]
Future software changes
- Wikimedia Labs will stop working for about 10 minutes around 18:00 UTC on May 30 due to a server upgrade. [64]
- It will soon no longer be possible to upload different files under the same name at the same time using the UploadWizard tool. [65] [66]
- Links to TIFF, DjVu or PDF files created with the syntax
[[File:Name.ext|thumb|page 15 is my favourite]]
will now show an image caption if there is any text after page number; previously they caused the given page to appear. [67] [68] [69] - You will soon see information about global blocks for IP addresses on their contributions page on your local wiki. [70] [71]
Tech news prepared by tech ambassadors and posted by MediaWiki message delivery • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.
08:29, 26 May 2014 (UTC)