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
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
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&... 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
Hi Thomas, Yes, that is a very good piece of advice, and I think now many people have learnt today what "major update" means :) I did some testing when you sent the message about 2 weeks ago and it is perfectly normal to expect some bugs during the deployment. At least the remaining problems don't seem that bad and you were quick to react to solve the critical bugs.
It is important to note for people that follow the list but not participate much in the discussions, that this update was really necessary to ensure that the Proofread Page extension can be further mantained and developed. It is the result of months of work and were several volunteers involved. On appearance it doesn't change anything, but it has made the code much more understandable that it was and it has built a solid foundation for the future.
Maybe by the next major update (I think that will be the Wikidata deployment in January) we should make a bigger communication effort and send a mass message and contact administrators/ambassadors. Hopefully that will work better.
Cheers, Micru
On Thu, Dec 5, 2013 at 3:22 PM, 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&... 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
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&...
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
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
- 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&...
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
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
- 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&...
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
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... * 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
- 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&...
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
On Fri, Dec 6, 2013 at 12:27 PM, Thomas Tanon thomaspt@hotmail.fr wrote:
- 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...
Would it be possible to add a zoom level slider and/or zooming shortcuts? I usually don't have a mouse wheel available. Another thing that I have noticed is that when I connect a mouse and I scroll up or down over the image, the view zooms in or out smoothly, but the page also scrolls up or down.
Micru
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)
by Thomas
Thanks for details; usually we are learning by "try and learn" and explicit details like those you give save hours of tries!
# trimming bottom of the page: IMHO it's an excellent idea. The simple trick to add (manually or by a script launched at onSubmit event) a tl|nop at the bottom of the page when needed to force the closure of a paragraph at the bottom of the page and saves many transclusion issues. # in the meantime, since we have to activate such a "final cleanup routine", it would be easy to "take a look" to body text and to add a references tag (after a new line) into the footer only when needed (t.i. when text contains a ref tag or a template building a ref tag - an infrequent case. # I only use wikipedia.Page .put() method to edit pages by bot, I don't know if it uses API action=edit, but anyone writing by itself scripts to edit nsPage is used to test carefully the header-body-footer stuff so that here some try-and-learn will clarify the matter.
I'm going to copy-and-paste your message.... as soon as this unavoidable "bug explosion" will rest, I've many other questions for you.... but not now. :-)
Thanks again.
Alex
The trim final routine is done automatically by the Wikitext content representation. So, it have been very easy to implement. If you are interested, here is the internal representation of a Page: page: https://git.wikimedia.org/blob/mediawiki%2Fextensions%2FProofreadPage.git/84... About automatic addition of the references tag, it’s a good idea. Feel free to hack the extension (you are really invited to do so :-)) or to fill a bug on bugzilla. Thomas
Le 6 déc. 2013 à 14:28, Alex Brollo alex.brollo@gmail.com 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)
by ThomasThanks for details; usually we are learning by "try and learn" and explicit details like those you give save hours of tries!
# trimming bottom of the page: IMHO it's an excellent idea. The simple trick to add (manually or by a script launched at onSubmit event) a tl|nop at the bottom of the page when needed to force the closure of a paragraph at the bottom of the page and saves many transclusion issues. # in the meantime, since we have to activate such a "final cleanup routine", it would be easy to "take a look" to body text and to add a references tag (after a new line) into the footer only when needed (t.i. when text contains a ref tag or a template building a ref tag - an infrequent case. # I only use wikipedia.Page .put() method to edit pages by bot, I don't know if it uses API action=edit, but anyone writing by itself scripts to edit nsPage is used to test carefully the header-body-footer stuff so that here some try-and-learn will clarify the matter.
I'm going to copy-and-paste your message.... as soon as this unavoidable "bug explosion" will rest, I've many other questions for you.... but not now. :-)
Thanks again.
Alex
Wikisource-l mailing list Wikisource-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikisource-l
Thanks Thomas but.... I can't write php, just a little of python and javascript. But more or less I can read it (if statements are simple) , thanks for link.
Alex
2013/12/6 Thomas Tanon thomaspt@hotmail.fr
The trim final routine is done automatically by the Wikitext content representation. So, it have been very easy to implement. If you are interested, here is the internal representation of a Page: page: https://git.wikimedia.org/blob/mediawiki%2Fextensions%2FProofreadPage.git/84... About automatic addition of the references tag, it’s a good idea. Feel free to hack the extension (you are really invited to do so :-)) or to fill a bug on bugzilla. Thomas
Le 6 déc. 2013 à 14:28, Alex Brollo alex.brollo@gmail.com 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)
by ThomasThanks for details; usually we are learning by "try and learn" and explicit details like those you give save hours of tries!
# trimming bottom of the page: IMHO it's an excellent idea. The simple trick to add (manually or by a script launched at onSubmit event) a tl|nop at the bottom of the page when needed to force the closure of a paragraph at the bottom of the page and saves many transclusion issues. # in the meantime, since we have to activate such a "final cleanup routine", it would be easy to "take a look" to body text and to add a references tag (after a new line) into the footer only when needed (t.i. when text contains a ref tag or a template building a ref tag - an infrequent case. # I only use wikipedia.Page .put() method to edit pages by bot, I don't know if it uses API action=edit, but anyone writing by itself scripts to edit nsPage is used to test carefully the header-body-footer stuff so that here some try-and-learn will clarify the matter.
I'm going to copy-and-paste your message.... as soon as this unavoidable "bug explosion" will rest, I've many other questions for you.... but not now. :-)
Thanks again.
Alex
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
Hi!
Some improvements and bug corrections have been deployed some minutes ago as part of MediaWiki 1.23wmf6:
Here is a list of fixed issues: * A JavaScript fatal error in Page: pages editing interface is solved for Internet Explorer 8 or less and old Safari versions. * Mediawiki:proofreadpage_default_header and Mediawiki:proofreadpage_default_footer and text layer extraction now works for Page: pages without index. * It is possible again to zoom in on mouse scroll. * The level change summary tag is now added when you click on the level selector (it’s what was done before the new Page: pages editing interface deployment)
Here is the remaining known issues (thanks to report ones that haven’t been listed here): * Fatal error on submit for a very few pages (a correction is on review) * 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 isn't possible to edit only the body of a page throw the API * The body content editing area doesn’t fit the scan height in vertical editing mode. I’m looking for a clean way to fix this problem. * The tab order in Page: pages editing interface is strange. A correction for it is ready and will be deployed soon.
Thomas
Le 6 déc. 2013 à 23:53, Alex Brollo alex.brollo@gmail.com a écrit :
Thanks Thomas but.... I can't write php, just a little of python and javascript. But more or less I can read it (if statements are simple) , thanks for link.
Alex
2013/12/6 Thomas Tanon thomaspt@hotmail.fr The trim final routine is done automatically by the Wikitext content representation. So, it have been very easy to implement. If you are interested, here is the internal representation of a Page: page: https://git.wikimedia.org/blob/mediawiki%2Fextensions%2FProofreadPage.git/84... About automatic addition of the references tag, it’s a good idea. Feel free to hack the extension (you are really invited to do so :-)) or to fill a bug on bugzilla. Thomas
Le 6 déc. 2013 à 14:28, Alex Brollo alex.brollo@gmail.com 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)
by ThomasThanks for details; usually we are learning by "try and learn" and explicit details like those you give save hours of tries!
# trimming bottom of the page: IMHO it's an excellent idea. The simple trick to add (manually or by a script launched at onSubmit event) a tl|nop at the bottom of the page when needed to force the closure of a paragraph at the bottom of the page and saves many transclusion issues. # in the meantime, since we have to activate such a "final cleanup routine", it would be easy to "take a look" to body text and to add a references tag (after a new line) into the footer only when needed (t.i. when text contains a ref tag or a template building a ref tag - an infrequent case. # I only use wikipedia.Page .put() method to edit pages by bot, I don't know if it uses API action=edit, but anyone writing by itself scripts to edit nsPage is used to test carefully the header-body-footer stuff so that here some try-and-learn will clarify the matter.
I'm going to copy-and-paste your message.... as soon as this unavoidable "bug explosion" will rest, I've many other questions for you.... but not now. :-)
Thanks again.
Alex
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
Gday Tpt,
I would like to thank you for all the work that you have been doing to firstly convert the ProofreaPage extension away from the javascript methodology, into the new schema. Then all the time that you have spent bug fixing this past week. It probably sounds as though we are complaining at times with raising issues, but to let you know personally that I think that the work that you have been doing for the editing community, and then for the reading community, is magnificent.
So that big thank you to you, and to those who have helped problem solve this past week. Really appreciated.
Regards Billinghurst
On Tue, 10 Dec 2013 21:34:09 +0100, Thomas Tanon thomaspt@hotmail.fr wrote:
Hi!
Some improvements and bug corrections have been deployed some minutes
ago
as part of MediaWiki 1.23wmf6:
Here is a list of fixed issues:
- A JavaScript fatal error in Page: pages editing interface is solved
for
Internet Explorer 8 or less and old Safari versions.
- Mediawiki:proofreadpage_default_header and
Mediawiki:proofreadpage_default_footer and text layer extraction now
works
for Page: pages without index.
- It is possible again to zoom in on mouse scroll.
- The level change summary tag is now added when you click on the level
selector (it’s what was done before the new Page: pages editing
interface
deployment)
Here is the remaining known issues (thanks to report ones that haven’t been listed here):
- Fatal error on submit for a very few pages (a correction is on review)
- 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 isn't possible to edit only the body of a page throw the API
- The body content editing area doesn’t fit the scan height in vertical
editing mode. I’m looking for a clean way to fix this problem.
- The tab order in Page: pages editing interface is strange. A
correction
for it is ready and will be deployed soon.
Thomas
Le 6 déc. 2013 à 23:53, Alex Brollo alex.brollo@gmail.com a écrit :
Thanks Thomas but.... I can't write php, just a little of python and javascript. But more or less I can read it (if statements are simple) , thanks for link.
Alex
2013/12/6 Thomas Tanon thomaspt@hotmail.fr The trim final routine is done automatically by the Wikitext content representation. So, it have been very easy to implement. If you are interested, here is the internal representation of a Page: page:
https://git.wikimedia.org/blob/mediawiki%2Fextensions%2FProofreadPage.git/84...
About automatic addition of the references tag, it’s a good idea. Feel free to hack the extension (you are really invited to do so :-)) or to fill a bug on bugzilla. Thomas
Le 6 déc. 2013 à 14:28, Alex Brollo alex.brollo@gmail.com 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)
by ThomasThanks for details; usually we are learning by "try and learn" and explicit details like those you give save hours of tries!
# trimming bottom of the page: IMHO it's an excellent idea. The simple trick to add (manually or by a script launched at onSubmit event) a tl|nop at the bottom of the page when needed to force the closure of a paragraph at the bottom of the page and saves many transclusion
issues.
# in the meantime, since we have to activate such a "final cleanup routine", it would be easy to "take a look" to body text and to add a references tag (after a new line) into the footer only when needed
(t.i.
when text contains a ref tag or a template building a ref tag - an infrequent case. # I only use wikipedia.Page .put() method to edit pages by bot, I
don't
know if it uses API action=edit, but anyone writing by itself scripts
to
edit nsPage is used to test carefully the header-body-footer stuff so that here some try-and-learn will clarify the matter.
I'm going to copy-and-paste your message.... as soon as this unavoidable "bug explosion" will rest, I've many other questions for you.... but not now. :-)
Thanks again.
Alex
Header and footer sections aren't being displayed on pt.wikisource.
Maybe it's due to local scripts?
Example: https://pt.wikisource.org/w/index.php?title=P%C3%A1gina:Phar%C3%B3es.pdf/45&...
On Wed, Dec 11, 2013 at 12:52 AM, billinghurst billinghurst@gmail.comwrote:
Gday Tpt,
I would like to thank you for all the work that you have been doing to firstly convert the ProofreaPage extension away from the javascript methodology, into the new schema. Then all the time that you have spent bug fixing this past week. It probably sounds as though we are complaining at times with raising issues, but to let you know personally that I think that the work that you have been doing for the editing community, and then for the reading community, is magnificent.
So that big thank you to you, and to those who have helped problem solve this past week. Really appreciated.
Regards Billinghurst
On Tue, 10 Dec 2013 21:34:09 +0100, Thomas Tanon thomaspt@hotmail.fr wrote:
Hi!
Some improvements and bug corrections have been deployed some minutes
ago
as part of MediaWiki 1.23wmf6:
Here is a list of fixed issues:
- A JavaScript fatal error in Page: pages editing interface is solved
for
Internet Explorer 8 or less and old Safari versions.
- Mediawiki:proofreadpage_default_header and
Mediawiki:proofreadpage_default_footer and text layer extraction now
works
for Page: pages without index.
- It is possible again to zoom in on mouse scroll.
- The level change summary tag is now added when you click on the level
selector (it’s what was done before the new Page: pages editing
interface
deployment)
Here is the remaining known issues (thanks to report ones that haven’t been listed here):
- Fatal error on submit for a very few pages (a correction is on review)
- 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 isn't possible to edit only the body of a page throw the API
- The body content editing area doesn’t fit the scan height in vertical
editing mode. I’m looking for a clean way to fix this problem.
- The tab order in Page: pages editing interface is strange. A
correction
for it is ready and will be deployed soon.
Thomas
Le 6 déc. 2013 à 23:53, Alex Brollo alex.brollo@gmail.com a écrit :
Thanks Thomas but.... I can't write php, just a little of python and javascript. But more or less I can read it (if statements are simple) , thanks for link.
Alex
2013/12/6 Thomas Tanon thomaspt@hotmail.fr The trim final routine is done automatically by the Wikitext content representation. So, it have been very easy to implement. If you are interested, here is the internal representation of a Page: page:
https://git.wikimedia.org/blob/mediawiki%2Fextensions%2FProofreadPage.git/84...
About automatic addition of the references tag, it’s a good idea. Feel free to hack the extension (you are really invited to do so :-)) or to fill a bug on bugzilla. Thomas
Le 6 déc. 2013 à 14:28, Alex Brollo alex.brollo@gmail.com 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)
by ThomasThanks for details; usually we are learning by "try and learn" and explicit details like those you give save hours of tries!
# trimming bottom of the page: IMHO it's an excellent idea. The simple trick to add (manually or by a script launched at onSubmit event) a tl|nop at the bottom of the page when needed to force the closure of a paragraph at the bottom of the page and saves many transclusion
issues.
# in the meantime, since we have to activate such a "final cleanup routine", it would be easy to "take a look" to body text and to add a references tag (after a new line) into the footer only when needed
(t.i.
when text contains a ref tag or a template building a ref tag - an infrequent case. # I only use wikipedia.Page .put() method to edit pages by bot, I
don't
know if it uses API action=edit, but anyone writing by itself scripts
to
edit nsPage is used to test carefully the header-body-footer stuff so that here some try-and-learn will clarify the matter.
I'm going to copy-and-paste your message.... as soon as this unavoidable "bug explosion" will rest, I've many other questions for you.... but not now. :-)
Thanks again.
Alex
Wikisource-l mailing list Wikisource-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikisource-l
Strange.... I entered and I saw them, both logged and unlogged; I only found a default setting to hide them, but both using preferences or Proofreading tools (Instrumentos de revisão) header and footer can be seen.
Alex
2013/12/14 Luiz Augusto lugusto@gmail.com
Header and footer sections aren't being displayed on pt.wikisource.
Maybe it's due to local scripts?
Example: https://pt.wikisource.org/w/index.php?title=P%C3%A1gina:Phar%C3%B3es.pdf/45&...
On Wed, Dec 11, 2013 at 12:52 AM, billinghurst billinghurst@gmail.comwrote:
Gday Tpt,
I would like to thank you for all the work that you have been doing to firstly convert the ProofreaPage extension away from the javascript methodology, into the new schema. Then all the time that you have spent bug fixing this past week. It probably sounds as though we are complaining at times with raising issues, but to let you know personally that I think that the work that you have been doing for the editing community, and then for the reading community, is magnificent.
So that big thank you to you, and to those who have helped problem solve this past week. Really appreciated.
Regards Billinghurst
On Tue, 10 Dec 2013 21:34:09 +0100, Thomas Tanon thomaspt@hotmail.fr wrote:
Hi!
Some improvements and bug corrections have been deployed some minutes
ago
as part of MediaWiki 1.23wmf6:
Here is a list of fixed issues:
- A JavaScript fatal error in Page: pages editing interface is solved
for
Internet Explorer 8 or less and old Safari versions.
- Mediawiki:proofreadpage_default_header and
Mediawiki:proofreadpage_default_footer and text layer extraction now
works
for Page: pages without index.
- It is possible again to zoom in on mouse scroll.
- The level change summary tag is now added when you click on the level
selector (it’s what was done before the new Page: pages editing
interface
deployment)
Here is the remaining known issues (thanks to report ones that haven’t been listed here):
- Fatal error on submit for a very few pages (a correction is on review)
- 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 isn't possible to edit only the body of a page throw the API
- The body content editing area doesn’t fit the scan height in vertical
editing mode. I’m looking for a clean way to fix this problem.
- The tab order in Page: pages editing interface is strange. A
correction
for it is ready and will be deployed soon.
Thomas
Le 6 déc. 2013 à 23:53, Alex Brollo alex.brollo@gmail.com a écrit :
Thanks Thomas but.... I can't write php, just a little of python and javascript. But more or less I can read it (if statements are simple) , thanks for link.
Alex
2013/12/6 Thomas Tanon thomaspt@hotmail.fr The trim final routine is done automatically by the Wikitext content representation. So, it have been very easy to implement. If you are interested, here is the internal representation of a Page: page:
https://git.wikimedia.org/blob/mediawiki%2Fextensions%2FProofreadPage.git/84...
About automatic addition of the references tag, it’s a good idea. Feel free to hack the extension (you are really invited to do so :-)) or to fill a bug on bugzilla. Thomas
Le 6 déc. 2013 à 14:28, Alex Brollo alex.brollo@gmail.com 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)
by ThomasThanks for details; usually we are learning by "try and learn" and explicit details like those you give save hours of tries!
# trimming bottom of the page: IMHO it's an excellent idea. The simple trick to add (manually or by a script launched at onSubmit event) a tl|nop at the bottom of the page when needed to force the closure of a paragraph at the bottom of the page and saves many transclusion
issues.
# in the meantime, since we have to activate such a "final cleanup routine", it would be easy to "take a look" to body text and to add a references tag (after a new line) into the footer only when needed
(t.i.
when text contains a ref tag or a template building a ref tag - an infrequent case. # I only use wikipedia.Page .put() method to edit pages by bot, I
don't
know if it uses API action=edit, but anyone writing by itself scripts
to
edit nsPage is used to test carefully the header-body-footer stuff so that here some try-and-learn will clarify the matter.
I'm going to copy-and-paste your message.... as soon as this unavoidable "bug explosion" will rest, I've many other questions for you.... but not now. :-)
Thanks again.
Alex
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
I've just found the same scenery on ca.wikisource:
https://ca.wikisource.org/w/index.php?title=P%C3%A0gina:L%27auca_del_senyor_...https://ca.wikisource.org/w/index.php?title=P%C3%A0gina:L%27auca_del_senyor_Esteve_(1912).djvu/145&action=edit
On Sat, Dec 14, 2013 at 8:59 PM, Alex Brollo alex.brollo@gmail.com wrote:
Strange.... I entered and I saw them, both logged and unlogged; I only found a default setting to hide them, but both using preferences or Proofreading tools (Instrumentos de revisão) header and footer can be seen.
Alex
2013/12/14 Luiz Augusto lugusto@gmail.com
Header and footer sections aren't being displayed on pt.wikisource.
Maybe it's due to local scripts?
Example: https://pt.wikisource.org/w/index.php?title=P%C3%A1gina:Phar%C3%B3es.pdf/45&...
On Wed, Dec 11, 2013 at 12:52 AM, billinghurst billinghurst@gmail.comwrote:
Gday Tpt,
I would like to thank you for all the work that you have been doing to firstly convert the ProofreaPage extension away from the javascript methodology, into the new schema. Then all the time that you have spent bug fixing this past week. It probably sounds as though we are complaining at times with raising issues, but to let you know personally that I think that the work that you have been doing for the editing community, and then for the reading community, is magnificent.
So that big thank you to you, and to those who have helped problem solve this past week. Really appreciated.
Regards Billinghurst
On Tue, 10 Dec 2013 21:34:09 +0100, Thomas Tanon thomaspt@hotmail.fr wrote:
Hi!
Some improvements and bug corrections have been deployed some minutes
ago
as part of MediaWiki 1.23wmf6:
Here is a list of fixed issues:
- A JavaScript fatal error in Page: pages editing interface is solved
for
Internet Explorer 8 or less and old Safari versions.
- Mediawiki:proofreadpage_default_header and
Mediawiki:proofreadpage_default_footer and text layer extraction now
works
for Page: pages without index.
- It is possible again to zoom in on mouse scroll.
- The level change summary tag is now added when you click on the level
selector (it’s what was done before the new Page: pages editing
interface
deployment)
Here is the remaining known issues (thanks to report ones that haven’t been listed here):
- Fatal error on submit for a very few pages (a correction is on
review)
- 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 isn't possible to edit only the body of a page throw the API
- The body content editing area doesn’t fit the scan height in vertical
editing mode. I’m looking for a clean way to fix this problem.
- The tab order in Page: pages editing interface is strange. A
correction
for it is ready and will be deployed soon.
Thomas
Le 6 déc. 2013 à 23:53, Alex Brollo alex.brollo@gmail.com a écrit :
Thanks Thomas but.... I can't write php, just a little of python and javascript. But more or less I can read it (if statements are simple) , thanks for link.
Alex
2013/12/6 Thomas Tanon thomaspt@hotmail.fr The trim final routine is done automatically by the Wikitext content representation. So, it have been very easy to implement. If you are interested, here is the internal representation of a Page: page:
https://git.wikimedia.org/blob/mediawiki%2Fextensions%2FProofreadPage.git/84...
About automatic addition of the references tag, it’s a good idea. Feel free to hack the extension (you are really invited to do so :-)) or to fill a bug on bugzilla. Thomas
Le 6 déc. 2013 à 14:28, Alex Brollo alex.brollo@gmail.com 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)
by ThomasThanks for details; usually we are learning by "try and learn" and explicit details like those you give save hours of tries!
# trimming bottom of the page: IMHO it's an excellent idea. The
simple
trick to add (manually or by a script launched at onSubmit event) a tl|nop at the bottom of the page when needed to force the closure of
a
paragraph at the bottom of the page and saves many transclusion
issues.
# in the meantime, since we have to activate such a "final cleanup routine", it would be easy to "take a look" to body text and to add a references tag (after a new line) into the footer only when needed
(t.i.
when text contains a ref tag or a template building a ref tag - an infrequent case. # I only use wikipedia.Page .put() method to edit pages by bot, I
don't
know if it uses API action=edit, but anyone writing by itself scripts
to
edit nsPage is used to test carefully the header-body-footer stuff so that here some try-and-learn will clarify the matter.
I'm going to copy-and-paste your message.... as soon as this unavoidable "bug explosion" will rest, I've many other questions for you.... but not now. :-)
Thanks again.
Alex
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
Hi! Thanks for this bug report. Everything works fine for me too on pl and ca wikisources. Could you report us your browser name, your skin (vector, mono book…), your toolbar (WikiEditor or the old toolbar) and a link to your common.js? It would help us to find the cause of the issue. Thomas
Le 16 déc. 2013 à 03:16, Luiz Augusto lugusto@gmail.com a écrit :
I've just found the same scenery on ca.wikisource:
https://ca.wikisource.org/w/index.php?title=P%C3%A0gina:L%27auca_del_senyor_...
On Sat, Dec 14, 2013 at 8:59 PM, Alex Brollo alex.brollo@gmail.com wrote: Strange.... I entered and I saw them, both logged and unlogged; I only found a default setting to hide them, but both using preferences or Proofreading tools (Instrumentos de revisão) header and footer can be seen.
Alex
2013/12/14 Luiz Augusto lugusto@gmail.com Header and footer sections aren't being displayed on pt.wikisource.
Maybe it's due to local scripts?
Example: https://pt.wikisource.org/w/index.php?title=P%C3%A1gina:Phar%C3%B3es.pdf/45&...
On Wed, Dec 11, 2013 at 12:52 AM, billinghurst billinghurst@gmail.com wrote: Gday Tpt,
I would like to thank you for all the work that you have been doing to firstly convert the ProofreaPage extension away from the javascript methodology, into the new schema. Then all the time that you have spent bug fixing this past week. It probably sounds as though we are complaining at times with raising issues, but to let you know personally that I think that the work that you have been doing for the editing community, and then for the reading community, is magnificent.
So that big thank you to you, and to those who have helped problem solve this past week. Really appreciated.
Regards Billinghurst
On Tue, 10 Dec 2013 21:34:09 +0100, Thomas Tanon thomaspt@hotmail.fr wrote:
Hi!
Some improvements and bug corrections have been deployed some minutes
ago
as part of MediaWiki 1.23wmf6:
Here is a list of fixed issues:
- A JavaScript fatal error in Page: pages editing interface is solved
for
Internet Explorer 8 or less and old Safari versions.
- Mediawiki:proofreadpage_default_header and
Mediawiki:proofreadpage_default_footer and text layer extraction now
works
for Page: pages without index.
- It is possible again to zoom in on mouse scroll.
- The level change summary tag is now added when you click on the level
selector (it’s what was done before the new Page: pages editing
interface
deployment)
Here is the remaining known issues (thanks to report ones that haven’t been listed here):
- Fatal error on submit for a very few pages (a correction is on review)
- 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 isn't possible to edit only the body of a page throw the API
- The body content editing area doesn’t fit the scan height in vertical
editing mode. I’m looking for a clean way to fix this problem.
- The tab order in Page: pages editing interface is strange. A
correction
for it is ready and will be deployed soon.
Thomas
Le 6 déc. 2013 à 23:53, Alex Brollo alex.brollo@gmail.com a écrit :
Thanks Thomas but.... I can't write php, just a little of python and javascript. But more or less I can read it (if statements are simple) , thanks for link.
Alex
2013/12/6 Thomas Tanon thomaspt@hotmail.fr The trim final routine is done automatically by the Wikitext content representation. So, it have been very easy to implement. If you are interested, here is the internal representation of a Page: page:
https://git.wikimedia.org/blob/mediawiki%2Fextensions%2FProofreadPage.git/84...
About automatic addition of the references tag, it’s a good idea. Feel free to hack the extension (you are really invited to do so :-)) or to fill a bug on bugzilla. Thomas
Le 6 déc. 2013 à 14:28, Alex Brollo alex.brollo@gmail.com 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)
by ThomasThanks for details; usually we are learning by "try and learn" and explicit details like those you give save hours of tries!
# trimming bottom of the page: IMHO it's an excellent idea. The simple trick to add (manually or by a script launched at onSubmit event) a tl|nop at the bottom of the page when needed to force the closure of a paragraph at the bottom of the page and saves many transclusion
issues.
# in the meantime, since we have to activate such a "final cleanup routine", it would be easy to "take a look" to body text and to add a references tag (after a new line) into the footer only when needed
(t.i.
when text contains a ref tag or a template building a ref tag - an infrequent case. # I only use wikipedia.Page .put() method to edit pages by bot, I
don't
know if it uses API action=edit, but anyone writing by itself scripts
to
edit nsPage is used to test carefully the header-body-footer stuff so that here some try-and-learn will clarify the matter.
I'm going to copy-and-paste your message.... as soon as this unavoidable "bug explosion" will rest, I've many other questions for you.... but not now. :-)
Thanks again.
Alex
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
2013/12/14 Luiz Augusto lugusto@gmail.com Header and footer sections aren't being displayed on pt.wikisource.
Isn't it the Safari 4.0/5.1 and IE < 8 trouble we got also on fr.wp ?
Browsers tested: * Google Chrome 31.0.1650.63 m * Firefox 26.0 * Internet Explorer 11.0.9600.16476 all on Windows 7 Home Premium SP1 x64
skin Vector with WikiEditor
https://pt.wikisource.org/wiki/MediaWiki:Common.js + gadgets default enabled to all users: https://pt.wikisource.org/wiki/MediaWiki:Gadget-Extra_toolbar.js https://pt.wikisource.org/wiki/MediaWiki:Gadget-Edittools.js https://pt.wikisource.org/wiki/MediaWiki:Gadget-Modernizacao.js https://pt.wikisource.org/wiki/MediaWiki:Gadget-LanguageConverter.css https://pt.wikisource.org/wiki/MediaWiki:Gadget-Correlatos.js https://pt.wikisource.org/wiki/MediaWiki:Gadget-Internet_Explorer.js + we on pt.wikisource have also FlaggedRevs enabled on some namespaces, including the Página one (ns:106)
https://ca.wikisource.org/wiki/MediaWiki:Common.js - they don't have neither gadgets enabled to all users neither FlaggedRevs extension
I hope that helps =)
Many thanks, Luiz
On Mon, Dec 16, 2013 at 8:42 AM, phil.el@free.fr wrote:
2013/12/14 Luiz Augusto lugusto@gmail.com Header and footer sections aren't being displayed on pt.wikisource.
Isn't it the Safari 4.0/5.1 and IE < 8 trouble we got also on fr.wp ?
-- Phe
Wikisource-l mailing list Wikisource-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikisource-l
Andrea Zanni, 05/12/2013 15:09:
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?[...]
Tpt mentioned testing. Cc quality assurance list: if they're available to give some pointers, maybe experienced Wikisource users could help by writing a bunch of acceptance tests/feature descriptions, i.e. "stories" of how things are supposed to work, in plain English, designed to be later made into "proper" regular tests. https://www.mediawiki.org/wiki/Quality_Assurance/Browser_testing/Writing_tests This is an example (I don't know how current) for another extension, ULS. https://www.mediawiki.org/wiki/Language_Testing_Plan/ULS_Test_Scenarios Coding, refactoring, maintaining and running such sets of tests is a huge burden, but writing down things could make it easier to choose a subset of them to focus on/commit to.
Nemo
On Thu, Dec 5, 2013 at 2:56 PM, Thomas Tanon <thomaspt@hotmail.fr mailto: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 <mailto: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@lists.wikimedia.org