Hi everyone! A new set of corrections have been deployed to Wikisource. Thanks a lot to Phe and Aarti Dwivedi for their help.
Here is a list of the fixed issues: * The Page: pages edit summary contained twice the proofreading level change tag. Now the level change tag isn’t visible during the edit process but is added on submit. * The addition of default header and footer content add a strange string instead of tags like <references />. * Mediawiki:proofreadpage_default_header and Mediawiki:proofreadpage_default_footer wasn’t used as default content for header and footer (this issue is still happening when the page hasn’t an Index) * The body textarea on Page: pages editing was too big. The size defined in User preferences is now used. Here is the remaining known issues (thanks to report ones that haven’t been listed here): * Mediawiki:proofreadpage_default_header and Mediawiki:proofreadpage_default_footer aren’t used for Page: pages without an Index: * Fatal error on submit for a very few pages (a correction is on review) * It isn’t possible anymore to zoom in with a mouse. A fix is on test2.wikipedia.org and will be deployed next Tuesday. Sample: https://test2.wikipedia.org/w/index.php?title=Page:The_book_of_try_and_learn.djvu/1&action=edit * the issue with gadget that Aubrey have reported here (I think that the solution is more on the gadget side that on the extension one) * It’s not possible to edit only the body of a page throw the API * The level change summary tag is not added when a custom edit summary is set (a correction is on review) Thomas PS: For people that ignore it, the maintenance work of the ProofreadPage extension is mostly done by volunteers like you. So, please be kind Le 6 déc. 2013 à 10:29, Thomas Tanon <[email protected]> a écrit : > Hi! > No, there isn’t any doc about it. The Proofread Page doc is very messy and > work on documentation is something really needed (it’s something that any > advanced editor of Wikisource can do). > # yes the bottom of nsPage body is trimmed (it’s normal normalisation of > wikitext content). If it breaks pages we can disable this normalisation. > # you can add a default footer content in Mediawiki:proofread > page_default_footer (it doesn’t works currently because of a bug but it > should be fixed soon (in the worst case at next Tuesday deployment)). If you > want to customize this value for a specific index, just add a new field > called 'Footer’ (the ID is important) in > MediaWiki:Proofreadpage_index_data_config with header:true. en.wikisource use > this feature. > # basically yes > # yes you have to if you use the action=edit API. I’m working on an other API > action that will allow to edit only the body and/or the proofreading level > (and that will be used also by the VisualEditor when it’ll be integrated) > > > Le 6 déc. 2013 à 09:03, Alex Brollo <[email protected]> a écrit : > >> I'm facing with new setting of nsPage editing; I'd like to study in detail >> news about the end of body text and footer. I'ìm a little confused from some >> it.source settings and main server/main javascript settings. Are present >> end-of-page text conventions/settings documented in detail somewhere? >> >> # is bottom of nsPage body trimmed for white spaces and/or new lines? Is >> there some need to use a tl|nop to close a paragraph when needed? >> # how can we customize footer content? >> # it.source added a <reference/> tag info footer by default; something >> changed and I've to add it manually. If I add it into the first row of >> footer, I see a problem (the last line of body text is converted into a >> paragraph); it can be prevented adding a new line into the footer, before >> references tag. Can I solve this issue customizing the default footer >> content? >> >> About API editing of nsPage: >> # have I to add header and footer code when creating new pages by our bot? >> Is this the only difference when managing nsPage text by bots? >> >> Alex >> >> >> 2013/12/6 billinghurst <[email protected]> >> There are two things that we can do to better inform >> 1) use the new MassMessage tool, and utilise a defined list at a defined >> wiki. We would have the list have all the WSes resspective Scriptoriums or >> their equivalents. I would suggest that this is the preferred means, as we >> can utilise mulWS Wikisource:Proofread Page for the place to host full >> explanation to text and links to Bugzillas, testing environment and what we >> want people to do >> 2) We can look to use the CentralNotice function at meta to put something >> on each WS wiki central notice filed. Just need to work through the >> translation functions, and not overdo the use. This would be best for >> important messages. >> >> Regards, Billinghurst >> >> On Thu, 5 Dec 2013 15:22:23 +0100, Thomas Tanon <[email protected]> >> wrote: >> > Hi! >> > I’ve send a message here a week before the deployment calling for tests >> on >> > test2.wikipedia.org. >> > The en.wikisource community had put a warning after this email on their >> > scriptorium and centralize bug reports. It was very easy for me to see >> the >> > bugs that affect us. >> > I believe that the best way to help us is to do as they does, put a >> > warning on your scriptorium, centralize bug reports their and, if you >> can, >> > translate them on bugzilla. >> > Here is the link to submit a bug for ProofreadPage: >> > >> https://bugzilla.wikimedia.org/enter_bug.cgi?product=MediaWiki%20extensions&component=ProofreadPage >> > Thomas >> > >> > Le 5 déc. 2013 à 15:09, Andrea Zanni <[email protected]> a écrit >> : >> > >> >> Thank you Thomas, >> >> I will copy and paste this message on the Italian Scriptorium. >> >> >> >> I perfectly know that the maintenance work of the (beloved) >> >> Proofreadpage extension falls almost on you and other brave heroes, >> >> and I would like to thank you for that. >> >> >> >> My question in fact is: >> >> how could we help you? I'm not very skilled with bugzilla and I do not >> >> code, >> >> but I am an admin on it.source and I can put a big red message on the >> >> sitenotice everytime there is a deployment. >> >> >> >> I suggest that, one two days in advance, you developers use this list >> to >> >> announce a deployment, >> >> so the community is ready to tackle problems and issues. >> >> It is frustrating for everyone if we have issues and we do not know >> why, >> >> and it is frustrating for you as well to run and fix the issues and >> also >> >> try to explain why and how. >> >> >> >> This mailing list is here for these kind of things: >> >> please use it, and let us help you when we can. >> >> >> >> Thanks! >> >> >> >> Aubrey >> >> >> >> >> >> >> >> >> >> >> >> On Thu, Dec 5, 2013 at 2:56 PM, Thomas Tanon <[email protected]> >> wrote: >> >> Hi everyone! >> >> >> >> I’m really sorry for all the issues affecting Wikisources. A fix for >> >> most of them have just been deployed (it have been an hard work) and >> I’ll >> >> try to fix all the remaining ones for the next Tuesday deployment. >> >> >> >> Here is a list of the fixed issues: >> >> * The image didn’t appear for Page: pages that are member of a >> multipage >> >> file but that haven’t as Index: page a page called >> Index:NAME_OF_THE_DJVU >> >> (it have affected mostly pl.wikisource) >> >> * A part of some Page: pages body content appeared as part of their >> >> footer in edit mode when those pages contains a <noinclude> tag >> >> * The color of the link to a Page: page was red in the Index: page when >> >> its level category name contained a whitespace (to fix this issue a >> purge >> >> of each Page: page affected is required) >> >> * The creation of a Page: page using the API caused a fatal error >> >> * An indentation was displayed on the first paragraph of a Page: page >> >> >> >> Here is the remaining known issues (thanks to report ones that haven’t >> >> been listed here): >> >> * The Page: pages edit summary contains twice the proofreading level >> >> change tag. A fix for it is on review that will let the software adds >> the >> >> tag on Page: page saving (the tag won’t be visible during the editing >> >> process. >> >> * The addition of default header and footer content adds a strange >> >> string instead of tags like <references />. A fix for it is on review >> >> * The body textarea on Page: pages editing is too big. I’m working on a >> >> fix that would use the size defined in User preferences instead. >> >> * Fatal error on submit for a very few pages (a fix is on review) >> >> * It isn’t possible anymore to zoom in with a mouse. I’m working on a >> >> fix >> >> * the issue with gadget that Aubrey have reported here (I think that >> the >> >> solution is more on the gadget side that on the extension one) >> >> * It’s not possible to edit only the body of a page throw the API >> >> >> >> I’m going to work on automatized tests in the next weeks in order to >> >> avoid a so major number of bugs the next times. >> >> >> >> Sorry again, >> >> >> >> Thomas >> >> >> >> PS: For people that ignore it, the maintenance work of the >> ProofreadPage >> >> extension is mostly done by volunteers like you. So, please be kind >> >> _______________________________________________ >> >> Wikisource-l mailing list >> >> [email protected] >> >> https://lists.wikimedia.org/mailman/listinfo/wikisource-l >> >> >> >> _______________________________________________ >> >> Wikisource-l mailing list >> >> [email protected] >> >> https://lists.wikimedia.org/mailman/listinfo/wikisource-l >> >> _______________________________________________ >> Wikisource-l mailing list >> [email protected] >> https://lists.wikimedia.org/mailman/listinfo/wikisource-l >> >> _______________________________________________ >> Wikisource-l mailing list >> [email protected] >> https://lists.wikimedia.org/mailman/listinfo/wikisource-l > > _______________________________________________ > Wikisource-l mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/wikisource-l
_______________________________________________ Wikisource-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikisource-l
