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 <thomaspt@hotmail.fr> 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 <alex.brollo@gmail.com> 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 <billinghurst@gmail.com>
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 <thomaspt@hotmail.fr>
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 <zanni.andrea84@gmail.com> 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 <thomaspt@hotmail.fr>
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
>> Wikisource-l@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikisource-l
>>
>> _______________________________________________
>> Wikisource-l mailing list
>> Wikisource-l@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikisource-l

_______________________________________________
Wikisource-l mailing list
Wikisource-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikisource-l

_______________________________________________
Wikisource-l mailing list
Wikisource-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikisource-l

_______________________________________________
Wikisource-l mailing list
Wikisource-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikisource-l