[Bug 54957] New: Reference should not be selected after adding it

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=54957

   Web browser: ---
Bug ID: 54957
   Summary: Reference should not be selected after adding it
   Product: VisualEditor
   Version: unspecified
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: Unprioritized
 Component: General
  Assignee: jforres...@wikimedia.org
  Reporter: wikif...@gmail.com
CC: jforres...@wikimedia.org, krinklem...@gmail.com
Classification: Unclassified
   Mobile Platform: ---

When you add a reference, it is automatically selected (blue), instead of
having the cursor positioned directly after it (or better still, with a space
after the ref and the cursor after that). The effec is that if you enter a ref
and then start typing (which is rather normal editing behaviour), your ref
immediately gets removed (overwritten) again, which makes it rather pointless. 

I think that it is much more often the intention to continue typing after
adding a ref, than to have it highlighted, so please change the default
behaviour.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 54917] VisualEditor: (REOPENED typing backwards in Firefox

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=54917

wikif...@gmail.com changed:

   What|Removed |Added

Summary|VisualEditor: typing|VisualEditor: (REOPENED
   |backwards in Firefox|typing backwards in Firefox

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 54917] VisualEditor: (REOPENED) typing backwards in Firefox

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=54917

wikif...@gmail.com changed:

   What|Removed |Added

Summary|VisualEditor: (REOPENED |VisualEditor: (REOPENED)
   |typing backwards in Firefox |typing backwards in Firefox

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 52135] VisualEditor: VE should detect template parameters automatically instead of using hand-written TemplateData

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=52135

Richard Morris  changed:

   What|Removed |Added

 CC||r...@singsurf.org

--- Comment #5 from Richard Morris  ---
It is dead easy all you need to do is scan for {{{1}}}, {{{name}}}, {{{1|
{{{name| etc. I've implemented this at
http://en.wikipedia.org/wiki/User:Salix_alba/TDSkell
and there are a few other implementations about. 

Kipod do you have a direct link to templatewizard as I've like to link to it?

There are 300,000 templates on the English wikipedia so many will never have
their TemplateData written making this an important enhancement. 

A slightly enhanced version of this request was asked at 

http://en.wikipedia.org/w/index.php?title=Wikipedia_talk%3AVisualEditor&diff=574762591&oldid=573484823

in addition to just getting the names it wanted to find the "mandatory"
parameters, a much harder job.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 54917] VisualEditor: typing backwards in Firefox

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=54917

wikif...@gmail.com changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 CC||wikif...@gmail.com
 Resolution|DUPLICATE   |---

--- Comment #2 from wikif...@gmail.com ---
Not a duplicate and/or not resolved. Please just test whatever has been
described before closing bugs, there are too many that need to be reopened.
[https://en.wikipedia.org/w/index.php?title=In_My_Dreams_%28Emmylou_Harris_song%29&diff=575692625&oldid=565930941]

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 50254] VisualEditor: (REOPENED Can't remove heading without header markup leaking to the rest of the page if it is the first element of the page

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=50254

wikif...@gmail.com changed:

   What|Removed |Added

Summary|VisualEditor: Can't remove  |VisualEditor: (REOPENED
   |heading without header  |Can't remove heading
   |markup leaking to the rest  |without header markup
   |of the page if it is the|leaking to the rest of the
   |first element of the page   |page if it is the first
   ||element of the page

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 38187] RuntimeError: command failed with returncode 256

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=38187

--- Comment #8 from josmart  ---
You're right, my $wgScriptPath = "". But it works ok now with a corrected 
Collection.body.php.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 50254] VisualEditor: Can't remove heading without header markup leaking to the rest of the page if it is the first element of the page

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=50254

wikif...@gmail.com changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 CC||wikif...@gmail.com
 Resolution|FIXED   |---

--- Comment #9 from wikif...@gmail.com ---
Nice that this is solved, except that it isn't. I had already noted that at
MediaWiki, it still blanks the header (but doesn't add nowiki). Tested today at
enwiki, and sadly, even worse, again a nowiki was added inside the header
instead of removing the empty header:
[https://en.wikipedia.org/w/index.php?title=Robbers_Cave_State_Park&diff=575691345&oldid=558376701]

Has this patch ever worked anywhere? Diff?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 40009] Special:Import increases NUMBEROFARTICLES for each Revision instead of each Article

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=40009

Andyrom75  changed:

   What|Removed |Added

 CC||andyro...@hotmail.com

--- Comment #11 from Andyrom75  ---
Same thing occurs on http:/it.wikivoyage.org (I think in all voys in general,
if not in all wikis).

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 54911] Log entries are vague

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=54911

Gerrit Notification Bot  changed:

   What|Removed |Added

 Status|NEW |PATCH_TO_REVIEW

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 54911] Log entries are vague

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=54911

--- Comment #2 from Gerrit Notification Bot  ---
Change 87512 had a related patch set uploaded by Legoktm:
Link to specific revision of spamlist that was used

https://gerrit.wikimedia.org/r/87512

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 50964] TemplateData not available to VisualEditor if the template is a redirect

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=50964

--- Comment #4 from Richard Morris  ---
Should a new bug for the Parsoid part be filed, so that the Parsoid team to do
their part of this? This is a very big issues as some of the most common
templates like the iconic {{cn}} are redirect and was asked about again at 
http://en.wikipedia.org/w/index.php?title=Wikipedia%3AVisualEditor%2FFeedback&diff=575686867&oldid=575662727

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 54916] expandtemplates for {{TFA title}} not giving proper title.

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=54916

--- Comment #3 from Harin Sutaria  ---
Thanks for the help. I understand that I have logged bug which was not right.
I will take care next time around.

I had a few other issues with the API and the data which is returned which I
wanted to get clarifications on. Hopefully I can get that from Village pump.

Once again, I apologize for the inconvenience it has caused you.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 54956] New and old log entries have missing or bogus oldid

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=54956

Nemo  changed:

   What|Removed |Added

   See Also||https://bugzilla.wikimedia.
   ||org/show_bug.cgi?id=54239

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 54239] Use new log system for better i18n

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=54239

Nemo  changed:

   What|Removed |Added

   See Also||https://bugzilla.wikimedia.
   ||org/show_bug.cgi?id=54956

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 54956] New: New and old log entries have missing or bogus oldid

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=54956

   Web browser: ---
Bug ID: 54956
   Summary: New and old log entries have missing or bogus oldid
   Product: MediaWiki extensions
   Version: master
  Hardware: All
   URL: https://meta.wikimedia.org/w/index.php?title=Special%3
ALog&type=notifytranslators
OS: All
Status: NEW
  Severity: major
  Priority: Unprioritized
 Component: TranslationNotifications
  Assignee: wikibugs-l@lists.wikimedia.org
  Reporter: federicol...@tiscali.it
CC: alolita.sha...@gmail.com,
amir.ahar...@mail.huji.ac.il, kartik.mis...@gmail.com,
run...@gmail.com, s.mazel...@xs4all.nl,
santhosh.thottin...@gmail.com
Classification: Unclassified
   Mobile Platform: ---

Examples:

https://meta.wikimedia.org/w/index.php?title=Vandal&oldid=vep
22:58, 17 September 2013 Nikerabbit (talk | contribs) sent a notification about
translating page Vandal; language: vep; deadline: none; priority: low; sent to
one recipient, failed for 0 recipients, skipped for 0 recipients 

https://meta.wikimedia.org/w/index.php?title=Wikimedia_Highlights,_July_2012&oldid=
02:20, 3 September 2012 Tbayer (WMF) (talk | contribs) sent a notification
about translating page Wikimedia Highlights, July 2012; languages: all
languages; deadline: none; priority: medium; sent to 825 recipients, failed for
0 recipients, skipped for 12 recipients

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 54955] weird &1 in HTML comment

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=54955

Gerrit Notification Bot  changed:

   What|Removed |Added

 Status|NEW |PATCH_TO_REVIEW

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 54955] weird &1 in HTML comment

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=54955

--- Comment #1 from Gerrit Notification Bot  ---
Change 87509 had a related patch set uploaded by Legoktm:
Use PROTO_CANONICAL correctly.

https://gerrit.wikimedia.org/r/87509

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 54955] New: weird &1 in HTML comment

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=54955

   Web browser: ---
Bug ID: 54955
   Summary: weird &1 in HTML comment
   Product: MediaWiki extensions
   Version: unspecified
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: Unprioritized
 Component: MassMessage
  Assignee: wikibugs-l@lists.wikimedia.org
  Reporter: legoktm.wikipe...@gmail.com
CC: b...@mzmcbride.com, legoktm.wikipe...@gmail.com
Classification: Unclassified
   Mobile Platform: ---



The &1 shouldn't be there.

> echo Title::newFromText('Main Page')->getFullURL();
http://127.0.0.1:8080/wiki/Main_Page
> echo Title::newFromText('Main Page')->getFullURL($proto = PROTO_CANONICAL);
http://127.0.0.1:8080/w/index.php?title=Main_Page&1

I think this is because I didn't realize PHP doesn't support out of order
kwargs like python does.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 54911] Log entries are vague

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=54911

Nemo  changed:

   What|Removed |Added

 CC||federicol...@tiscali.it

--- Comment #1 from Nemo  ---
Example for reference:

02:01, 4 October 2013 Eloquence (talk | contribs | block) sent a message to
User:Eloquence/MM (This is a spammy message)

https://test.wikipedia.org/w/index.php?title=Special:Log&offset=20131004020356&limit=1

I wanted to file a request for the link to a specific revision; I'd consider
the recipients count optional.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 38081] mediawiki.Title: Extension should be included when asserting that title is non-empty

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=38081

James Forrester  changed:

   What|Removed |Added

 Status|PATCH_TO_REVIEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from James Forrester  ---
Fixed and merged. Thank you hugely to Timo, and to Roan for merging. Yay.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 54954] Implement some restriction on who can deliver cross-wiki messages

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=54954

--- Comment #1 from Erik Moeller  ---
I'd vote for the feature flag, because it is simplest for now and makes it easy
to reject invalid input for the distribution lists.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 52723] Review and deploy MassMessage extension to Wikimedia wikis

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=52723

--- Comment #52 from Kunal Mehta (Legoktm)  ---
(In reply to comment #48)
> (In reply to comment #39)


I've filed bug 54954 as a blocker to this one. I've asked a few preliminary
questions on how this should be implemented, so if people who have options
could comment there please :)

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 54954] New: Implement some restriction on who can deliver cross-wiki messages

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=54954

   Web browser: ---
Bug ID: 54954
   Summary: Implement some restriction on who can deliver
cross-wiki messages
   Product: MediaWiki extensions
   Version: unspecified
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: Unprioritized
 Component: MassMessage
  Assignee: wikibugs-l@lists.wikimedia.org
  Reporter: legoktm.wikipe...@gmail.com
CC: b...@mzmcbride.com, e...@wikimedia.org,
federicol...@tiscali.it, legoktm.wikipe...@gmail.com,
s...@reedyboy.net
Blocks: 52723
Classification: Unclassified
   Mobile Platform: ---

See rationale on bug 52723 comment 37, counter argument on comment 39, response
to that on comment 48.

This feature was removed in https://gerrit.wikimedia.org/r/#/c/78047/.

There are two different ways we can do this:

* Add a new user-right called 'massmessage-global', and require users sending
notifications cross-wiki have this right.

* Add a config switch ($wgAllowCrossWikiMessages) that allows that wiki to send
messages to another wiki. So this would be turned on for meta, and any user on
meta with 'massmessage' would be able to send cross-wiki.

Personally I favor the user-right implementation since it gives more control
and flexibility, but at the same time, it adds yet another user right >.>

Next question: what should happen if a user attempts to send a message to a
list with cross-wiki targets but does not have the proper permissions (or it is
disabled on the wiki)

* The entire submission is rejected until the spamlist has those entries
removed

* A warning is given to the user and those cross-wiki targets are dropped from
the list.

* If we use the config switch, the parser function could reject any target that
is not on the current site with the red error message we have for invalid
input.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 52723] Review and deploy MassMessage extension to Wikimedia wikis

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=52723

Kunal Mehta (Legoktm)  changed:

   What|Removed |Added

 Depends on||54954

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 46637] Etherpad lite unusable at about 1000 lines or more (CPU load makes it lag)

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=46637

--- Comment #12 from Nemo  ---
(In reply to comment #11)
> (In reply to comment #10)
> > A recently (14 July) merged patch allegedly makes the most common case one
> > order of magnitude faster, worth testing.
> > https://github.com/ether/etherpad-lite/issues/1763#issuecomment-21423689
> > https://github.com/ether/etherpad-lite/pull/1833#issuecomment-20943600
> 
> Did it? Are we using that code or not? We no longer have the old etherpad as
> workaround, how are people managing?

I hear that some are still using Chrome to edit the etherpads in question; it
gets very slot to use about now, so around 1700 lines it would seem?
For reference, https://etherpad.wikimedia.org/p/i18n-team-04/timeslider#10309

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 54953] Grid error executing console php script

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=54953

Tim Landscheidt  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Tim Landscheidt  ---
You need to request more memory for the job (for example "jsub -mem 350m php
[…]"); cf. [[wikitech:Nova Resource:Tools/Help#Why am I getting errors about
libgcc_s.so.1 must be installed for pthread_cancel to work?]].

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 52723] Review and deploy MassMessage extension to Wikimedia wikis

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=52723

--- Comment #51 from Isarra  ---
(In reply to comment #48)
If there is any way to do global logs (alongside local ones) this would be a
very good place to use that, as that would make all wikis much more easily
accountable for any usage of this tool.

That said you're probably right in that just enabling the sending part on meta
would be better, since, on top of logs and such all being in one place, usage
guidelines and crap would also be better synced. And implicitly trusting all
admins isn't necessarily a good idea when different projects can have
completely different methods and standards when approaching problems, and on
top of that pretty much anyone can become an admin at least somewhere (which
isn't even necessarily a bad thing, since if they happen to be in the right
place even the most unexpected of folks can prove quite useful, but also
doesn't mean it should carry weight elsewhere).

So just have a request page for anyone new to use, and a right that can be
added to anyone who ain't an admin if they've general use for the spammer and
clearly understand what not to do, or whatever. I'm sure the meta folks can
argue out some actual details there.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 52723] Review and deploy MassMessage extension to Wikimedia wikis

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=52723

--- Comment #50 from Nemo  ---
(In reply to comment #34)
> [...] Last year, there was a broken core change about timestamping slipped 
> through
> Platform review and got deployed. Because of that, a better thought-out and
> previously-developed pending core change for the exact same feature from
> Werdna
> got bumped. [...]

The only thing I found is https://gerrit.wikimedia.org/r/#/c/15746 which was
merged after ignoring code-review for months, causing a developer and
translator revolt.

(In reply to comment #48)
> So I'm not comfortable with a deploy that amounts to giving admins in every
> wiki 'massmessage' permission to every other wiki. I'd be fine with 1)
> limiting
> the availability of the massmessage permission to Meta, or 2) adding back the
> global/local message delivery distinction and enabling local delivery on all
> wikis, and global delivery on Meta.
> 
> Better broadcasting tools should still continually be developed, and the
> imperfections of this approach will hopefully feed into whatever comes next,
> whether it's an iteration on MassMessage or an entirely new approach.

+1
I think this is totally reasonable and was indeed my only true worry about the
extension.
I'd add the permission to a special group, possibly reusing centralnoticeadmin
group, since the first deploy, to avoid needless requests for adminship.
More than that, we could even try to replicate the logging of the messages
content to a wiki page, for enhanced accountability.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 54953] New: Grid error executing console php script

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=54953

   Web browser: ---
Bug ID: 54953
   Summary: Grid error executing console php script
   Product: Wikimedia Labs
   Version: unspecified
  Hardware: All
OS: All
Status: UNCONFIRMED
  Severity: major
  Priority: Unprioritized
 Component: tools
  Assignee: m...@uberbox.org
  Reporter: metat...@online.ms
CC: benap...@gmail.com, t...@tim-landscheidt.de
Classification: Unclassified
   Mobile Platform: ---

If submitting a console php-script jsub refuses w/ error:

libgcc_s.so.1 must be installed for pthread_cancel to work

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 53687] LinksDeletionUpdate skipped, causing revisions to disappear on undelete

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=53687

--- Comment #10 from Gerrit Notification Bot  ---
Change 87505 had a related patch set uploaded by Tim Starling:
Fix revision table cleanup on delete

https://gerrit.wikimedia.org/r/87505

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 53687] LinksDeletionUpdate skipped, causing revisions to disappear on undelete

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=53687

Gerrit Notification Bot  changed:

   What|Removed |Added

 Status|NEW |PATCH_TO_REVIEW

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 52723] Review and deploy MassMessage extension to Wikimedia wikis

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=52723

--- Comment #49 from Erik Moeller  ---
s/ReviewerBot/MessengerBot/

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 52723] Review and deploy MassMessage extension to Wikimedia wikis

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=52723

Erik Moeller  changed:

   What|Removed |Added

 CC||e...@wikimedia.org

--- Comment #48 from Erik Moeller  ---
(In reply to comment #39)
> This was considered and it's probably easy enough to implement these
> restrictions, but as I said above, I'm not sure they're necessary. My view
> was
> to take a "wait and see" approach. If local administrators begin to abuse or
> misuse the tool, we can always add in restrictions later.

I would actually look at it differently. Right now, as I understand it,
cross-wiki message delivery is only configured to be run from Meta, where it's
easy to see who's configuring what "spams" and for what audiences. It's easy
for folks to have a shared conversation about what's appropriate and what
isn't, and even for people to revert additions that they see as unreasonable.

So you've actually created a very clever tool that plays well into the norms of
the wiki community, and uses an existing shared space (Meta) in the intended
manner.

In contrast, enabling admins everywhere to _easily_ post bulk messages across
wikis from anywhere, with the audit trail being HTML comments in the messages
that are left, is IMO quite likely to play against the norms of the wiki,
because messages _will_ be sent in a manner that's inconsistent with the norms
of a given target wiki, and it'll be harder for the community to have a shared
conversation about it or even to easily see what's happening (because there is
no central message log at that point).

Because actions such as compiling target lists are dispersed, the normal
processes of community peer review won't kick in as effectively to moderate and
monitor behavior.

Yes, anyone can of course post anywhere today, but not everyone has access to a
shared bot account that they can use on any wiki to do so, nor do they have an
automated delivery tool. ReviewerBot would suddenly take bot actions on wikis
and users would be tasked with figuring out what's going on. That's manageable
if the only possible source is Meta, but more problematic if the source is any
of our wikis.

Cross-wiki bulk messages to anywhere from anywhere are a significant change
from the status quo that requires more consideration. And on that point, WMF
will certainly get the blame if the tool is misused.

So I'm not comfortable with a deploy that amounts to giving admins in every
wiki 'massmessage' permission to every other wiki. I'd be fine with 1) limiting
the availability of the massmessage permission to Meta, or 2) adding back the
global/local message delivery distinction and enabling local delivery on all
wikis, and global delivery on Meta.

Better broadcasting tools should still continually be developed, and the
imperfections of this approach will hopefully feed into whatever comes next,
whether it's an iteration on MassMessage or an entirely new approach.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 54847] Data leakage user table "new" databases like wikidatawiki_p and the wikivoyage databases

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=54847

Kunal Mehta (Legoktm)  changed:

   What|Removed |Added

 CC||legoktm.wikipe...@gmail.com

--- Comment #20 from Kunal Mehta (Legoktm)  ---
(In reply to comment #19)

> Maybe it's just a mediawiki.org thing?

Confirmed, the message doesn't exist on mw.o Filed as bug 54952.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 54952] New: 'Bug-54847-password-reset-prompt' message is missing on MediaWiki

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=54952

   Web browser: ---
Bug ID: 54952
   Summary: 'Bug-54847-password-reset-prompt' message is missing
on MediaWiki
   Product: Wikimedia
   Version: wmf-deployment
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: Unprioritized
 Component: General/Unknown
  Assignee: wikibugs-l@lists.wikimedia.org
  Reporter: legoktm.wikipe...@gmail.com
Classification: Unclassified
   Mobile Platform: ---

https://www.mediawiki.org/wiki/MediaWiki:Bug-54847-password-reset-prompt is
missing.

See bug 54847 comment 18 and 19

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 51927] Thanks icon is a little disturbing

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=51927

Isarra  changed:

   What|Removed |Added

 CC||zhoris...@gmail.com

--- Comment #8 from Isarra  ---
I had a similar reaction when I saw it. The smiley face seems both creepy and
just plain out of place, though not necessarily any more than a heart would
have been.

Thing is, though, 'thanking' isn't really a concept that can be described
visually. Some things just aren't, and trying to assign icons to them may not
be the best approach in light of that.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 54952] 'Bug-54847-password-reset-prompt' message is missing on MediaWiki.org

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=54952

Kunal Mehta (Legoktm)  changed:

   What|Removed |Added

Summary|'Bug-54847-password-reset-p |'Bug-54847-password-reset-p
   |rompt' message is missing   |rompt' message is missing
   |on MediaWiki|on MediaWiki.org

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 54847] Data leakage user table "new" databases like wikidatawiki_p and the wikivoyage databases

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=54847

--- Comment #19 from Terry Chay  ---
> Hm, I can't test right now because I don't have an account that's flagged,
> but
> we definitely didn't have that issue yesterday. Where are you getting this,
> Terry?
> https://en.wikipedia.org/wiki/MediaWiki:Bug-54847-password-reset-prompt
> loads the message as expected.

I got it when I tried to edit mediawiki.org just now and logged in. I actually
backed out and tried to log in again before I realized that it was a missing
string somewhere.

I should have screenshotted it, or not reset my password, but I thought that
maybe this is so common that it isn't an issue. Maybe it's just a mediawiki.org
thing?

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 41484] Default icon in vector for "profile" in personal tools should be gender neutral and fit with other site icons look & feel

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=41484

Siddhartha Ghai  changed:

   What|Removed |Added

 CC||siddhartha.g...@gmail.com

--- Comment #38 from Siddhartha Ghai  ---
(In reply to comment #28)
> Another design practice that I'm a fan of is to go with more abstract user
> icons or animal icons e.g. github's
> https://dribbble.s3.amazonaws.com/users/8063/screenshots/873671/
> github_icon_vector_shape_teaser.png

I'd just like to point out that animal icons would not be wise since languages
may associate certain animals with certain genders by default. For example, a
user with native language hindi might consider a cat icon to be female and a
lion to be male. Cat: male: बिल्ला, female: बिल्ली, latter is what is generally
default usage. Lion invokes a male idea since hindi, like English, defaults to
lion (शेर), not lioness (शेरनी)

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 54847] Data leakage user table "new" databases like wikidatawiki_p and the wikivoyage databases

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=54847

PiRSquared17  changed:

   What|Removed |Added

 CC||pirsquare...@gmail.com

--- Comment #17 from PiRSquared17  ---
See also: [[m:Talk:October 2013 private data security issue]]

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 54847] Data leakage user table "new" databases like wikidatawiki_p and the wikivoyage databases

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=54847

--- Comment #18 from Kunal Mehta (Legoktm)  ---
(In reply to comment #14)
> Would be nice if the following string were actually updated:
> 
> 
> 
> I think it's confusing to users when they successfully log in and are asked
> to
> change the password with this as the prompt. ;-)

Note this was also mentioned in #mediawiki earlier today: (my timestamps are
PDT, log trimmed for relevance)

[05:13:34 PM]  Just got this on mw.org
"" when trying to log in
[05:17:54 PM]  tfinc: can you file a bug and CC csteipp, anomie &
me?
[05:18:45 PM]  ori-l: haven't been able to replicate past the two
times that i saw it

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 54847] Data leakage user table "new" databases like wikidatawiki_p and the wikivoyage databases

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=54847

MZMcBride  changed:

   What|Removed |Added

 CC||b...@mzmcbride.com

--- Comment #16 from MZMcBride  ---
(In reply to comment #11)
> The script in question is not in any repo (or so I think -- certainly not in
> Puppet or WikimediaMaintenance) and I believe it was run manually. It needs
> to be a more robust solution.

Yowza. This seems worthy of its own bug report.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 54847] Data leakage user table "new" databases like wikidatawiki_p and the wikivoyage databases

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=54847

--- Comment #15 from Erik Moeller  ---
Hm, I can't test right now because I don't have an account that's flagged, but
we definitely didn't have that issue yesterday. Where are you getting this,
Terry? https://en.wikipedia.org/wiki/MediaWiki:Bug-54847-password-reset-prompt
loads the message as expected.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 54847] Data leakage user table "new" databases like wikidatawiki_p and the wikivoyage databases

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=54847

Terry Chay  changed:

   What|Removed |Added

 CC||tc...@wikimedia.org

--- Comment #14 from Terry Chay  ---
Would be nice if the following string were actually updated:



I think it's confusing to users when they successfully log in and are asked to
change the password with this as the prompt. ;-)

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 54902] Deprecate MediaWiki's purge action? (It's a hack.)

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=54902

Siddhartha Ghai  changed:

   What|Removed |Added

 CC||siddhartha.g...@gmail.com

--- Comment #8 from Siddhartha Ghai  ---
It would be nice if this purging wasn't needed at all. There's a gadget
specifically for this at the english wikipedia [1] and probably several other
wikipedias as well.

IIRC, whenever a highly used template is changed at the english wikipedia, bots
are used to purge all pages where the template was used.

[1]: https://en.wikipedia.org/wiki/MediaWiki:Gadget-purgetab.js

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 52723] Review and deploy MassMessage extension to Wikimedia wikis

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=52723

--- Comment #47 from Terry Chay  ---
> > To the first document which has its origins in the SVN days, the first stop
> > with Howie Fung and his product management team. To my knowledge the only
> > person asked was a Dan Garry, and not as a first stop on anything. 
> 
> Dan was cc'd by Greg in comment 13. I wasn't aware that Platform and/or
> Features were supposed to be in the loop so I never bothered to do it.

It's unfortunate. Dan is new and is not really in a position to speak for
product, and I don't think that was the intent of comment 13 to make him make a
call.

The implication of Platform or Features is in the later stage of code review
for deployment. There was a time that Sumana would manage that using 20% time
volunteered by Features, but that was over a year ago. :-( Since then
commitment to maintain deployed extensions has fallen through the crack between
Platform and Features.

> Correct. I had spoken with Greg a few days earlier about emailing wikitech-l
> /
> Aaron / Tim for the architecture review, and he recommended that I wait for
> your comments ;-)

Oh, well then why was it added to the deploy calendar? Can we remove it backand
wait for comments to make sure it's okay to deploy before adding it to the lsit
of things to be deployed? As it stands now, my position is I'm okay with it
because Ori is okay with helping you support and monitor it for issues that
might crop up like comment 37 above.

> > The second document is newly written by Platform not vetted by anyone in
> > Features.
> 
> For someone outside of the WMF who is trying to get an extension deployed,
> the
> distinction between Platform and Features isn't very clear, nor really
> important. Was VipsScaler (also written by a volunteer) handled by Features?

No, and in earlier incarnations of the queue, I think [[mw:VipsScaler]] was
linked. Development on it was started in 2011, I think multimedia team
(originally a Features team, now in Platform) deployed it. That team is
obviously committed to maintain. :-)

> All we really want is our code deployed :P

Totally understandable. :-)


> The checklist is fine, it just seems like its missing one step according to
> you
> (notify Features and/or Platform teams).

I'm okay with clarifying that a design review means a product design review and
PM signoff and adding that a plan for engineering, product, and design
maintenance needs to be in place going forward (beyond simply bugzilla).

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 54902] Deprecate MediaWiki's purge action? (It's a hack.)

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=54902

MZMcBride  changed:

   What|Removed |Added

Summary|Re-evaluate MediaWiki's |Deprecate MediaWiki's purge
   |purge action|action? (It's a hack.)

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 54902] Re-evaluate MediaWiki's purge action

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=54902

--- Comment #7 from MZMcBride  ---
(In reply to comment #5)
> MZMcBride: When would this bug be "evaluated", so action could take place?

Looks like one of Wikimedia's (or MediaWiki's) architects confirmed that the
purge action is a hack in comment 4. :-)

Any hack should eventually be killed (I believe that's the nature of a hack).
If we're not going to expose the purge action in the user interface, I think we
should work toward deprecating it.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 52723] Review and deploy MassMessage extension to Wikimedia wikis

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=52723

--- Comment #46 from Terry Chay  ---
(In reply to comment #41)
> (In reply to comment #7)
> > == TODO/Check list ==
> > Extension page on mediawiki.org: yes
> > Bugzilla component: yes
> > Extension in Gerrit: yes
> > Design Review: no
> > Archeticecture/Performance Review: no
> > Security Review: no
> > Screencast (if applicable): no
> > Community support: no?
> 
> As a designer, I did a design review over IRC. I said something along the
> lines
> of 'looks shiny'.
> 
> I hope that helps, as I'm not sure what more you could want with this kind of
> extension. Other issues beyond the interface itself have generally already
> been
> established by precedent (EdwardsBot).

We'd have to ask Greg what he really meant by this when he added that to
[[mw:Review queue]] instead of leaving the process pointing back to
[[mw:Writing_an_extension_for_deployment]], but if I were to hazard a guess:

I think Greg tried to clear the review queue because it was suffering from
neglect. He tried summarize the original linked document:
[[mw:Writing_an_extension_for_deployment#Design_review]] by saying it has a
proper "design review." It clearly implies design review as being a product
design review with a design UI design component
[[mw:WMF_Project_Design_Review_Process]] probably dating back to when they were
in the same department.

If you look at an earlier revision
[https://www.mediawiki.org/w/index.php?title=Review_queue&oldid=697844], you
can see the tracking list that was its original purpose since Brion created it.
Around that time, it was getting unmanageable four months ago with little
movement. My guess is that there simply had been no recent Extensions (other
than in-flight extensions like Math and SignupAPI) that had actually gone
through this process and in an effort to systematize the process into a
workable checklist, it got morphed over time from "send it to product design
for review" to "send an e-mail to a designer and to the design mailing list."
*shrug*

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 51927] Thanks icon is a little disturbing

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=51927

MZMcBride  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #7 from MZMcBride  ---
(In reply to comment #6)
> MZMcBride, due to your track record of high quality thoughtful bugs and
> comments on discussions in the community, I honestly assumed this was a joke. 

Not a joke, no. But I'm fine with closing this bug. More below.

> If you are truly "disturbed" by the icon perhaps it is some deeper issue that
> may have nothing to do with the icon itself but a fear of smiling?

:-)

I'm not a huge fan of smiley faces being used in the user interface (e.g.,
[[mw:Extension:MoodBar]]). I think it often comes across as childish and/or
amateurish and/or creepy. I think the green square-headed variety of smilies
are particularly strange and off-putting.

> Either way, the icon was arrived at because the original icon (a heart) was
> found to be confusing to some cultures, a smile on the other hand while
> skirting the line of us trying to avoid iconography with human forms (eyes,
> hands, etc) was selected because with a few small caveats smiles and smiling
> are felt to be a universal sign of happiness and good will. 
> 
> As Quim mentioned, the new icon seems to have overwhelming acceptance
> compared to any previous iteration of the iconography, and we've not gotten
> any significant complaints.

Okay. Different people naturally respond differently. This bug was actually
changed from the default "new" resolution to "unconfirmed" because I wasn't
sure if anyone else had the same reaction as I did. If nobody else minds the
green square-headed smiley face, we can close this bug as "worksforme".

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 38081] mediawiki.Title: Extension should be included when asserting that title is non-empty

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=38081

--- Comment #6 from Gerrit Notification Bot  ---
Change 83047 merged by jenkins-bot:
mw.Title: Rewrite from scratch (porting logic from Title.php)

https://gerrit.wikimedia.org/r/83047

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 52723] Review and deploy MassMessage extension to Wikimedia wikis

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=52723

--- Comment #45 from Kunal Mehta (Legoktm)  ---
(In reply to comment #40)
> (In reply to comment #38)
> 
> > > The requirement for extensions to be deployed has ALWAYS been that 
> > > Features
> > > Engineering sign off on a commitment to maintain the extension.
> > 
> > This isn't consistent with the documentation at [[mw:Writing an extension 
> > for
> > deployment]], [[mw:Review queue]] and Greg's checklist in comment 7.
> 
> Interesting links.
> 
> To the first document which has its origins in the SVN days, the first stop
> with Howie Fung and his product management team. To my knowledge the only
> person asked was a Dan Garry, and not as a first stop on anything. 

Dan was cc'd by Greg in comment 13. I wasn't aware that Platform and/or
Features were supposed to be in the loop so I never bothered to do it.

> I mentioned
> in my original post why that people should know better. The second stop was
> wikitech-l. To my knowledge mine was the first post on the subject.

Correct. I had spoken with Greg a few days earlier about emailing wikitech-l /
Aaron / Tim for the architecture review, and he recommended that I wait for
your comments ;-)


> The second document is newly written by Platform not vetted by anyone in
> Features.

For someone outside of the WMF who is trying to get an extension deployed, the
distinction between Platform and Features isn't very clear, nor really
important. Was VipsScaler (also written by a volunteer) handled by Features?
All we really want is our code deployed :P

> The third link refers to someone who has been at the WMF even less time than
> me. If we're to use MZMcBrides seniority rules, the fact that some
> newly-minted, improperly vetted document was used by a relatively new
> engineer
> doesn't carry weight.

The checklist is fine, it just seems like its missing one step according to you
(notify Features and/or Platform teams).

> I hope that documentation is updated.

Be bold!

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 52723] Review and deploy MassMessage extension to Wikimedia wikis

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=52723

--- Comment #44 from Kunal Mehta (Legoktm)  ---
(In reply to comment #41)
> As a designer, I did a design review over IRC. I said something along the
> lines
> of 'looks shiny'.

For reference, Isarra created [[commons:File:Massmessage preview (uncyc).png]],
and pointed out a few flaws in the initial design, like using tables for the
form (now switched to proper s), and the submit/preview buttons stacked on
top of each other (now side-by-side).

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 52723] Review and deploy MassMessage extension to Wikimedia wikis

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=52723

--- Comment #43 from Kunal Mehta (Legoktm)  ---
(In reply to comment #39)
> (In reply to comment #37)
> > Is the current thinking to give users on any wiki the right to use
> > Special:MassMessage to spam users on any other wiki?
> 
> Yes. The design idea here was that this is already possibly by any user.
> Anyone
> can open up a bunch of browser tabs and post to dozens of wikis quickly
> without
> even logging in. Or, for example, I've been posting to hundreds of wikis for
> years without a privileged account using only a very simple Python script.

It might be worth noting that the MassMessage bot account used automatically
adds itself to the 'bot' group, but isn't able to override full protections or
anything like that.

> 
> > It seems to me you'd want something like:
> > 
> > * Users on Meta can trigger cross-wiki notifications;
> > * Users on any other wiki can only trigger local notifications.
> 
> This was considered and it's probably easy enough to implement these
> restrictions, but as I said above, I'm not sure they're necessary.

An initial version of the extension had this differentiation, but it was
removed in https://gerrit.wikimedia.org/r/#/c/78047/. I don't mind revisiting
the concept either (file a bug for it?), as it wouldn't be hard to implement
technically.

> My view was
> to take a "wait and see" approach. If local administrators begin to abuse or
> misuse the tool, we can always add in restrictions later.
> 
> > Otherwise you end up with an audit trail mess. Having a single log in one
> > place and a single place to set policy around these things seems highly
> > desirable.

I actually wrote [[mw:Extension:CentralLogging]] for this problem a while back,
but it wouldn't work in the WMF environment.


> The bot currently provides an audit trail by (optionally?) appending an HTML
> comment containing the originating wiki, message sender's name, etc., I
> believe. Lego can confirm this.

The audit trail is not optional (though a wiki could choose to blank the
message and make it useless). An example is
,
which includes the origin wiki, sender, and spamlist used.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 52723] Review and deploy MassMessage extension to Wikimedia wikis

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=52723

--- Comment #42 from MZMcBride  ---
(In reply to comment #40)
> Do you have a link to this doctrine regarding software deployments and
> sign-offs? [...] perhaps there's a guideline you've written on mediawiki.org,
> wikitech.wikimedia.org, or Meta-Wiki. Please share.

Go on. I'll wait.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 35306] Global (to a wiki farm or family) message delivery (thoughts)

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=35306

MZMcBride  changed:

   What|Removed |Added

   Priority|High|Normal
  Component|Echo|General/Unknown
Product|MediaWiki extensions|Wikimedia
   Target Milestone|Future release  |---
   Severity|enhancement |normal

--- Comment #24 from MZMcBride  ---
(In reply to comment #21)
> I'm going to move this bug to Echo, we might not solve all the issues there,
> but we can get some real headway in a month. A longer explanation will
> follow.

File your own bug. We already discussed this above. Ryan K., who was actively
working on Echo at the time, and I (in consultation with others) decided that
Echo was not the best path forward in order to resolve this bug. If you want
Echo to have the ability to post to cross-wiki user talk pages, file a separate
bug report that you can manage and add to whatever backlog you'd like.

This bug is actually a Wikimedia bug that should hopefully be resolved/fixed by
the end of this month. Re-classifying it as such.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 52723] Review and deploy MassMessage extension to Wikimedia wikis

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=52723

--- Comment #41 from Isarra  ---
(In reply to comment #7)
> == TODO/Check list ==
> Extension page on mediawiki.org: yes
> Bugzilla component: yes
> Extension in Gerrit: yes
> Design Review: no
> Archeticecture/Performance Review: no
> Security Review: no
> Screencast (if applicable): no
> Community support: no?

As a designer, I did a design review over IRC. I said something along the lines
of 'looks shiny'.

I hope that helps, as I'm not sure what more you could want with this kind of
extension. Other issues beyond the interface itself have generally already been
established by precedent (EdwardsBot).

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 52723] Review and deploy MassMessage extension to Wikimedia wikis

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=52723

--- Comment #40 from Terry Chay  ---
You're going to resort to ad hominem instead of attacking the argument when
you're already getting what you want?

I am not trying to "dictate" anything to volunteers. Volunteers didn't deploy
the code onto test and test2, it was Reedy. Volunteers are free to develop.
They're not free to have their developed code deployed on the cluster. Nobody
is.

As for the proof of this "doctrine," just like MediaWiki core has always been
the responsibility of Platform, the Extensions space has traditionally been the
responsibility of Features Engineering. Historically, new extension deploy and
a commitment to deploy was done by Brion and later by Roan. This used to be
enforced in terms of SVN access, and the artifact still exists in the form of
who has +2 on Gerrit. In the case of deploying a new extension, it requires +2
on gerrit, shell access, and an implied commitment to maintain.

I've been trying to relax this as I feel this is unscalable solution, but with
that right comes the responsibility. If you or other community developers are
unwilling to hold yourselves to the same responsibility that every engineer of
the Foundation is held to, you are free to do so. But nobody has the right to
have +2, nobody has the right to shell access, etc. Just as Platform and Ops
reserve the right as policy to rescind my +2 access and my non-existent shell
access, they could rescind anyone else's, even yours if it existed.


(In reply to comment #38)

> > The requirement for extensions to be deployed has ALWAYS been that Features
> > Engineering sign off on a commitment to maintain the extension.
> 
> This isn't consistent with the documentation at [[mw:Writing an extension for
> deployment]], [[mw:Review queue]] and Greg's checklist in comment 7.

Interesting links.

To the first document which has its origins in the SVN days, the first stop
with Howie Fung and his product management team. To my knowledge the only
person asked was a Dan Garry, and not as a first stop on anything. I mentioned
in my original post why that people should know better. The second stop was
wikitech-l. To my knowledge mine was the first post on the subject.

The second document is newly written by Platform not vetted by anyone in
Features. I assume that if Platform wants to operate that way then they're
committed to maintaining an extension approved that that process, that's cool
with me and entirely consistent to my statements. In it's original incarnation
it was Sumana's way of managing code review of existing extensions.

The third link refers to someone who has been at the WMF even less time than
me. If we're to use MZMcBrides seniority rules, the fact that some
newly-minted, improperly vetted document was used by a relatively new engineer
doesn't carry weight.

I hope that documentation is updated.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 52723] Review and deploy MassMessage extension to Wikimedia wikis

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=52723

--- Comment #39 from MZMcBride  ---
(In reply to comment #37)
> Is the current thinking to give users on any wiki the right to use
> Special:MassMessage to spam users on any other wiki?

Yes. The design idea here was that this is already possibly by any user. Anyone
can open up a bunch of browser tabs and post to dozens of wikis quickly without
even logging in. Or, for example, I've been posting to hundreds of wikis for
years without a privileged account using only a very simple Python script. The
difference here in functionality isn't very big. The primary difference is that
we're adding a proper user interface for delivery submissions and reducing the
need for an external dependency (a bot).

> It seems to me you'd want something like:
> 
> * Users on Meta can trigger cross-wiki notifications;
> * Users on any other wiki can only trigger local notifications.

This was considered and it's probably easy enough to implement these
restrictions, but as I said above, I'm not sure they're necessary. My view was
to take a "wait and see" approach. If local administrators begin to abuse or
misuse the tool, we can always add in restrictions later.

> Otherwise you end up with an audit trail mess. Having a single log in one
> place and a single place to set policy around these things seems highly
> desirable.

Again, anyone can go around posting messages to any wiki right now without even
logging in. Giving local administrators the ability to send cross-wiki messages
with a simpler tool doesn't seem to warrant much concern from my perspective,
but if you consider this a requirement for wider deployment, Lego can add in
the restrictions.

The bot currently provides an audit trail by (optionally?) appending an HTML
comment containing the originating wiki, message sender's name, etc., I
believe. Lego can confirm this.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 54951] New: Rename namespace module to Malayalam in Malayalam language wikis

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=54951

   Web browser: ---
Bug ID: 54951
   Summary: Rename namespace module to Malayalam in Malayalam
language wikis
   Product: Wikimedia
   Version: wmf-deployment
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: Unprioritized
 Component: Site requests
  Assignee: wikibugs-l@lists.wikimedia.org
  Reporter: me.prav...@gmail.com
CC: benap...@gmail.com, dereck...@espace-win.org,
wikimedia.b...@snowolf.eu
Classification: Unclassified
   Mobile Platform: ---

Please rename namespace "Module" to Malayalam in Malayalam language wikis. 


Module = ഘടകം
Module talk = ഘടകത്തിന്റെ_സംവാദം

And also put these aliases: 'Module' and 'Module_talk' themselves and 'ഘ' (for
Module) 'ഘസം' (for Module talk) as short aliases.

Community notification:
https://ml.wikipedia.org/wiki/?oldid=1838664#Module_Namespace

Wikis:
ml.wiktionary.org
ml.wikiquote.org
ml.wikisource.org
ml.wikibooks.org
ml.wikipedia.org

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 53687] LinksDeletionUpdate skipped, causing revisions to disappear on undelete

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=53687

--- Comment #9 from Tim Starling  ---
The content of attachment 13415 has been deleted by
Tim Starling 
who provided the following reason:

contains private IP address

The token used to delete this attachment was generated at 2013-10-04 02:22:01
UTC.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 52723] Review and deploy MassMessage extension to Wikimedia wikis

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=52723

--- Comment #38 from Kunal Mehta (Legoktm)  ---
(In reply to comment #35)
> Ori has stepped up and is willing to commit his time to help Legoktm in
> supporting MassMessage on an ongoing basis. According to the current standard
> of the above, there is no longer any block on bug 52723.

Thank you Ori!

> The requirement for extensions to be deployed has ALWAYS been that Features
> Engineering sign off on a commitment to maintain the extension.

This isn't consistent with the documentation at [[mw:Writing an extension for
deployment]], [[mw:Review queue]] and Greg's checklist in comment 7.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 52723] Review and deploy MassMessage extension to Wikimedia wikis

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=52723

--- Comment #37 from Erik Moeller  ---
Is the current thinking to give users on any wiki the right to use
Special:MassMessage to spam users on any other wiki?

It seems to me you'd want something like:

* Users on Meta can trigger cross-wiki notifications;
* Users on any other wiki can only trigger local notifications.

Otherwise you end up with an audit trail mess. Having a single log in one place
and a single place to set policy around these things seems highly desirable. If
we're on the same page on that, I'm significantly less concerned about the long
term impact of the extension.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 52723] Review and deploy MassMessage extension to Wikimedia wikis

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=52723

--- Comment #36 from MZMcBride  ---
(In reply to comment #35)
> The requirement for extensions to be deployed has ALWAYS been that Features
> Engineering sign off on a commitment to maintain the extension.

You've been at the Wikimedia Foundation for, what, two years? You really feel
it's appropriate to lecture me and others about how things have "always" been?
You seem to have absolutely no sense of how software deployments have operated
for the majority of Wikimedia's existence.

You're attempting to dictate to volunteers as though they're your subordinates.
This is wildly inappropriate.

Do you have a link to this doctrine regarding software deployments and
sign-offs? As far as I can tell, you've just made it up here on this bug. But
perhaps there's a guideline you've written on mediawiki.org,
wikitech.wikimedia.org, or Meta-Wiki. Please share.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 53177] Create graph feature not working

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=53177

Diederik van Liere  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Diederik van Liere  ---
Solved

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 53155] Search datasource is not working

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=53155

Diederik van Liere  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from Diederik van Liere  ---
Solved

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 52723] Review and deploy MassMessage extension to Wikimedia wikis

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=52723

--- Comment #35 from Terry Chay  ---
Ori has stepped up and is willing to commit his time to help Legoktm in
supporting MassMessage on an ongoing basis. According to the current standard
of the above, there is no longer any block on bug 52723.

Time still has to be made to handle the rollout, but I'm assuming what is
already in-process in Platform, and Ori can assist beyond that.

The requirement for extensions to be deployed has ALWAYS been that Features
Engineering sign off on a commitment to maintain the extension. I've relaxed it
to be: "If another engineering department in collaboration with product is
willing to commit to it, Features will not block." I'd like to someday relax
this further to: "If any engineering department or community development in
collaboration with the other core competencies (features, product, design, and
community) are willing to commit to it, no one should block." We are not there
yet, and trying to rail against that is winning a battle at the cost of the war
breaking down these silos and having shared ownership and responsibility in our
organization, in our community, and in our movement.

Please realize the current state of affairs is that new Extension deploy can be
done under the following frameworks:

1) The traditional "Features signs off on all extensions" that has always been
in place. For Features to sign off on this, like with our own engineering
staff, we require collaboration and buy-in in affected areas like the product
managers and designers who will lose productivity or might be retasked on this.
We must be good stewards of each-others times, and I would not have permitted
(and will not permit) my engineers to task Platform and Design engineers for
MassMessage in the manner that has happened to date (water under the bridge at
this point).
2) The above can and has been be bypassed on a directive from the VPE as was
the case for BetaFeatures.
3) Like LanguageEngineering's use of TranslationNotifications instead of Echo,
if another team consisting of engineering, product, and design is willing to
commit to supporting on an ongoing basis, then extension deploy proceeds
without the traditional rule of discussing Features. Note, in this example we
have an assumption that the feature set of MassMessage is as-is so it currently
doesn't involve Product or Design, nor does it require more engineering
resources inside the WMF beyond Ori who is currently untasked.

We still eventually want to reach the point where the criteria is not the
amalgam of rules above but a simpler one based on intent, expertise-sharing and
consensus-building: "If any engineering department or community developer in
collaboration with the other core competencies (engineering, product, design,
and community) are willing to commit to ongoing maintenance of a feature, then
no one group should block it."

We haven't reached there yet, and please realize that when me make exceptions
as in this case, it compromises the larger picture of our need to break down
these silos and create shared ownership and responsibility in the WMF, in our
communities, and in the movement as a whole.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 53128] Allow recordings to be uploaded to central media repository (Commons)

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=53128

--- Comment #2 from Matthew Flaschen  ---
For reference, the Beta config for CORS is at
https://git.wikimedia.org/blob/operations%2Fmediawiki-config/3a9cdd74eefd74b3224af540c1abf419c5a71c44/wmf-config%2FCommonSettings-labs.php#L106

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 54673] LESS compiler should preserve the position of CSSMin / CSSJanus annotations

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=54673

Ori Livneh  changed:

   What|Removed |Added

 Status|PATCH_TO_REVIEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Ori Livneh  ---
Closing as fixed. I still do think we could handle embedding / flipping better
via LESS constructs, but I'm glad we have time to work on it now.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 38048] Root article paths allow bypassing of nofollow and attacks on Special:Random

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=38048

--- Comment #8 from Daniel Friesen  ---
(In reply to comment #7)
> I think in this case 
> 
> wfUrlencode("/example.com") should return "%2Fexample.com", not
> "/example.com".

We don't need to hack wfUrlencode to fix this bug. wfUrlencode is used in
places other than just the root where such a hack is excessive.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 54673] LESS compiler should preserve the position of CSSMin / CSSJanus annotations

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=54673

--- Comment #5 from Gerrit Notification Bot  ---
Change 86616 merged by jenkins-bot:
Update lessphp to 261f1bd28

https://gerrit.wikimedia.org/r/86616

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 50549] VisualEditor: round-trip adjacent and nested annotations

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=50549

James Forrester  changed:

   What|Removed |Added

   Priority|Unprioritized   |Normal
 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from James Forrester  ---
This has been fixed for some time in the DM. Marking as such.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 54877] Parsoid treats [[[[Foo]]]] as plain text, but the PHP parser treats it as [[Foo]]

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=54877

James Forrester  changed:

   What|Removed |Added

   Priority|Unprioritized   |Lowest
 CC||ssas...@wikimedia.org
  Component|General |General
   Assignee|jforres...@wikimedia.org|gwi...@wikimedia.org
Product|VisualEditor|Parsoid
Summary|VisualEditor: Unable to |Parsoid treats Foo
   |save a wikilink surrounded  |as plain text, but the PHP
   |by "[[" and "]]" text   |parser treats it as [[Foo]]

--- Comment #3 from James Forrester  ---
Re-re-phrasing the title (and yes, this appears to be a Parsoid bug, but a very
low priority one).

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 54050] GitBlit markdown parser doesn't handle ` starting on a newline

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=54050

Marcin Cieślak  changed:

   What|Removed |Added

 Status|PATCH_TO_REVIEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Marcin Cieślak  ---
Closing for now, it is debatable how upstream should behave (spec does not
explain this, we aim at github behaviour). Solved by improving markdown markup.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 53128] Allow recordings to be uploaded to central media repository (Commons)

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=53128

Matthew Flaschen  changed:

   What|Removed |Added

 CC||has...@free.fr

--- Comment #1 from Matthew Flaschen  ---
You should probably start by making a config variable for the API URL.  Check
out how MobileFrontend does it
(https://git.wikimedia.org/blob/mediawiki%2Fextensions%2FMobileFrontend.git/a4372c2b5402db3d406f176d4235d726d5cc9d99/MobileFrontend.php#L163).

You can export that to JavaScript with
https://www.mediawiki.org/wiki/Manual:Hooks/ResourceLoaderGetConfigVars .

Then, pass that to the UploadWizard config.  

However, you will need to deal with CORS
(https://developer.mozilla.org/en-US/docs/HTTP/Access_control_CORS).  In the
past, such cross-domain AJAX requests never worked.  Now, they can, but only if
CORS is configured.  You will need to change UploadWizard to deal with this,
since it does the actual uploading.

MobileFrontend shows how to handle CORS as well (look at PhotoApi.js).

However, you will not be able to change the production (actual Wikimedia
Commons) CORS config to allow access from
http://pronunciationrecording.instance-proxy.wmflabs.org/

You might be able to get permission to test against
https://commons.wikimedia.beta.wmflabs.org/w/api.php (Beta Commons) (ccing
Antoine for this).  Otherwise, you'll need to set up your own destination wiki
to test with (separate from
http://pronunciationrecording.instance-proxy.wmflabs.org/).

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 54947] VisualEditor: When user changes a link anchor which has the same link target, suggest that they may wish to change the link target too

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=54947

James Forrester  changed:

   What|Removed |Added

   Priority|Unprioritized   |Normal
 Status|UNCONFIRMED |ASSIGNED
Summary|Wikilink target & text  |VisualEditor: When user
   |check   |changes a link anchor which
   ||has the same link target,
   ||suggest that they may wish
   ||to change the link target
   ||too
 Ever confirmed|0   |1
   Severity|normal  |enhancement

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 54919] Tabs (Read / View Source / Search) wrap to next line and cover content if screen width < ~700px

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=54919

--- Comment #6 from Gavin Munro  ---
If there are technical problems then one alternative could be to have an option
for the old and new method - similar to the option for the old and new editor.

Another option - I noticed a gap between the two lines of wrapped text: if this
gap could be eliminated and perhaps the tab line reduced in height when half
width then perhaps the headings would not be covered. I dont know if this is
easier than moving the text down a line or not.

I do not have technical knowledge as to the feasibility of different options
unfortunately.

By way of explanation, I do translations and my method is to put two windows
side-by-side to read in French and write in English. As I have several Chrome
tabs open and switch between them, seeing the headings helps me to identify
where I am plus I also frequently have to copy the headings. This problem
definitely slows down the work.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 53687] LinksDeletionUpdate skipped, causing revisions to disappear on undelete

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=53687

--- Comment #8 from Tim Starling  ---
(In reply to comment #7)
> Thanks for the detailed explanation, Tim! Yes, please, could you recover the
> deleted edits? (if it's not too much) I'm intended to restore the page or so,
> but it's always useful to have all the contribs and deleted contribs around.

Done.

> Also: is it possible to check whether this has happened elsewhere too?

I will work on it.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 52723] Review and deploy MassMessage extension to Wikimedia wikis

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=52723

--- Comment #34 from Terry Chay  ---
(In reply to comment #33)

> This comparison carries no value: 1) LQT can't be undeployed because we'd
> lose
> critical data (discussions) from the wiki, 2) AFT is being expanded right now
> with no exit strategy I'm aware of (probably under the understanding that
> nobody cares if all that data disappears from the wikis after undeployment).

It carries more value that bug 31235 does to implement bug 52723. MassMessage
is an extension, as an extension it is under the same rules as all other
extensions for deployment.

1) LQT can't be underplayed and we're stuck with it for an uncertainf eatures
2) ReaderFeedback, AFT, and AFTv5 are all different extensions.

> I highly doubt I do. My sentence started with an "If" for a reason: I've no
> idea who's responsible for Echo.

Then I apologize, it's easy to read your statement and not have the hidden
assumption that someone is responsible for Echo. Nobody is, it, like everything
else, is a shared responsibility.

> Let me note that I asked how you planned to coordinate with other pieces of
> code/devs working in this area already 9 months ago: [[m:IRC office
> hours/2013-01-08]].

Hmm, I didn't read what you said as being related to this, most of what was in
that discussion was posted on the grandparent bug and little movement has been
done since then.

As to your logs: currently there is only one Dev working on Echo: bsitu.
RoanKattouw and matthiasmullie never got the chance to work on this project,
lwelling is no longer with us, Krenair is a community dev who I assume is
wrapped up in other issues with core, kaldari is now in Mobile, fabriceflorin
is in Multimedia and Werdna is on Flow. I don't know the state of
[[mw:Extension:TranslationNotifications]] but I believe it's under active
development/maintenance by Language Engineering. Their contributions are in
this log, on mediawiki, in the code base, and in fabriceflorin's notes. When
work on Echo is restarted, bsitu will be involved in it.


> I gather that you feel insulted and circumvented or something like that and
> I'm
> sorry for this personal pain you're suffering, but all this talk about
> exploiting doesn't look helpful.

I'm not insulted. I pushed back one time in a close-door meeting (I prevented
deployment on mediawiki.org with the understanding from all the participants of
the meeting that MassMessage would not be deployed on the cluster). Since
people aren't aware of it, I am trying to explain the decision and the
reasoning behind it.

I apologize for this language of "exploiting." Here was the topline of my
original discussion which is relevant (but deleted from the bug comment):

> When I use to loaded words like "back-dooring" etc, I believe that no malice 
> was intended and the discussions so far have been in good faith from all 
> parties. I think people have a valid concern and want it addressed and are 
> wondering honestly how decisions have been made. In particular, my decision 
> to not allow the MassMessage Extension to roll out onto MediaWiki last week, 
> since that occurred during a meeting that didn't even involve or derive have 
> consultation (except ex-post-facto) with any product manager or engineer here.

It is very likely that adding the previous deploy and this one to the deploy
calendar on Thursday would have someone like me either missing it or taking it
at face value (that someone outside my own team added it and has adopted
responsibility).

Last week, I didn't have time to figure out the parameters of where the
decision to deploy MassMessage came from, so I only pushed back on
mediawiki.org. The understanding from me and all the participants of the Friday
meeting was that MassMessage would not be deployed beyond that.

The fact is at that moment this spent all of one day on the deploy calendar
added by someone outside the WMF, one and a half weeks in public development on
obscure parts of the wiki and bugzilla, had no discussion with product, no plan
for support, etc.

No new feature would have been deployed to even test or test2 without
discussions from Features, Design and Product. I didn't realize that any of
this had occurred.

This is not a standard anymore for deployment of an extension, nor has it been
for quite a while.

> This is not a reply to my line you quoted.

Hmm, I feel it is but I guess this depends on the definition of what is is? :-)

If it is unreasonable to require sign off for Features Engineering for
Extension deploy than it is an unreasonable thing that has been in place long
before me. I'm trying to relax that requirement, one area of relaxing is to
find another home for deployment and support.

Last year, there was a broken core change about timestamping slipped through
Platform review and got deployed. Because of that, a better thought-out and
previously-developed pending core change for the exact same feature from Werdna
got bumped. To get this fixed,

[Bug 50459] VisualEditor: References in media captions appear but aren't editable or successfully insertable

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=50459

James Forrester  changed:

   What|Removed |Added

 CC||jan_eissfe...@gmx.net

--- Comment #5 from James Forrester  ---
*** Bug 54949 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 54949] Editing refs in image descriptions

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=54949

James Forrester  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from James Forrester  ---
Happily this is already fixed in the code that just went to MediaWiki.org
today, and will be available on dewiki (and elsewhere) in a week's time.
Merging with bug 50459.

*** This bug has been marked as a duplicate of bug 50459 ***

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 53776] The round-trip server seems to leak memory in production

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=53776

--- Comment #2 from Gabriel Wicke  ---
Just happened again. Had to kill -9 it, normal restart did not help. top showed
1.4G rss.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 54314] VisualEditor: A pawn appears when undoing "select transclusion and replace with text"

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=54314

James Forrester  changed:

   What|Removed |Added

   Priority|Unprioritized   |High
 Status|NEW |ASSIGNED
 CC||i...@wikia-inc.com,
   ||or...@framezero.com
  Component|General |ContentEditable
   Assignee|jforres...@wikimedia.org|i...@wikia-inc.com
   Target Milestone|--- |VE-deploy-2013-10-03

--- Comment #1 from James Forrester  ---
This is now fixed, AFAICS. Marking as such.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 52386] VisualEditor: Edit notices (and other toolbar notices) should have a close button

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=52386

James Forrester  changed:

   What|Removed |Added

   Target Milestone|--- |VE-deploy-2013-10-10

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 52386] VisualEditor: Edit notices (and other toolbar notices) should have a close button

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=52386

--- Comment #5 from Gerrit Notification Bot  ---
Change 87034 had a related patch set uploaded by Jforrester:
Toolbar action widgetization and UI refactoring

https://gerrit.wikimedia.org/r/87034

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 52386] VisualEditor: Edit notices (and other toolbar notices) should have a close button

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=52386

Gerrit Notification Bot  changed:

   What|Removed |Added

 Status|ASSIGNED|PATCH_TO_REVIEW

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 52386] VisualEditor: Edit notices (and other toolbar notices) should have a close button

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=52386

James Forrester  changed:

   What|Removed |Added

   Assignee|krinklem...@gmail.com   |tpars...@wikimedia.org

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 54950] wfExpandUrl() should expand relative URLs again

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=54950

Gerrit Notification Bot  changed:

   What|Removed |Added

 Status|NEW |PATCH_TO_REVIEW

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 54950] wfExpandUrl() should expand relative URLs again

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=54950

--- Comment #1 from Gerrit Notification Bot  ---
Change 87482 had a related patch set uploaded by saper:
wfExpandUrl should expand relative URLs, too

https://gerrit.wikimedia.org/r/87482

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 54910] Rename Toolbox to Tools

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=54910

Bartosz Dziewoński  changed:

   What|Removed |Added

   Keywords||i18n

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 54910] Rename Toolbox to Tools

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=54910

--- Comment #3 from Bartosz Dziewoński  ---
I've looked through a few translations in languages I can understand at least a
little bit. Almost all used a single word with meaning equivalent to simply
"Tools"; several used "Box of tools" (most languages aren't as flexible as
English with word formation), which looks rather awkward (notably French).

I'm definitely supporting "Tools", but "Utilities" might be worth considering
as well. I'm not sure if it's not too wordy, though.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 54928] VisualEditor: [Regression] Page settings dialog broken in Chrome (Uncaught TypeError: scrollTop of undefined)

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=54928

James Forrester  changed:

   What|Removed |Added

 Status|PATCH_TO_REVIEW |RESOLVED
 Resolution|--- |FIXED

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 54712] VisualEditor: Snowmen appear near newly added references

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=54712

James Forrester  changed:

   What|Removed |Added

   Target Milestone|--- |VE-deploy-2013-10-03

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 54950] New: wfExpandUrl() should expand relative URLs again

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=54950

   Web browser: ---
Bug ID: 54950
   Summary: wfExpandUrl() should expand relative URLs again
   Product: MediaWiki
   Version: unspecified
  Hardware: All
OS: All
Status: NEW
  Severity: major
  Priority: Unprioritized
 Component: General/Unknown
  Assignee: wikibugs-l@lists.wikimedia.org
  Reporter: marcin.cies...@gmail.com
CC: b...@mzmcbride.com, cste...@wikimedia.org,
developm...@pediapress.com, federicol...@tiscali.it,
krinklem...@gmail.com,
mediawiki-b...@nadir-seen-fire.com,
mflasc...@wikimedia.org, pleasest...@live.com
Blocks: 37868, 38048
Classification: Unclassified
   Mobile Platform: ---

In a fix to bug 32168 r103208 in line 458 introduced a case where relative URL
(the one NOT containing "/") will *not* be expanded with $wgServer.

This caused bug 37868 as well as ancillary issue with bug 38048 (wrong
redirect).

I believe this behaviour should be reinstanted

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 54928] VisualEditor: [Regression] Page settings dialog broken in Chrome (Uncaught TypeError: scrollTop of undefined)

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=54928

--- Comment #8 from Roan Kattouw  ---
(In reply to comment #3)
> Change 87442 merged by jenkins-bot:
> ve.Element: Fallback to body, window is not scrollable
> 
> https://gerrit.wikimedia.org/r/87442
This was just deployed.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 38048] Root article paths allow bypassing of nofollow and attacks on Special:Random

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=38048

Marcin Cieślak  changed:

   What|Removed |Added

 Depends on||54950

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 37868] empty wgScriptPath make exporting to PDF fail

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=37868

Marcin Cieślak  changed:

   What|Removed |Added

 Depends on||54950

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 54712] VisualEditor: Snowmen appear near newly added references

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=54712

Roan Kattouw  changed:

   What|Removed |Added

 Status|PATCH_TO_REVIEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #18 from Roan Kattouw  ---
(In reply to comment #12)
> Change 87455 had a related patch set uploaded by Catrope:
> When cloning the InternalList, pass through properties that aren't rebuilt
> 
> https://gerrit.wikimedia.org/r/87455

I just deployed this change, and the article linked in comment 0 now works for
me on frwiki.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 54919] Tabs (Read / View Source / Search) wrap to next line and cover content if screen width < ~700px

[bugzilla-daemon]

https://bugzilla.wikimedia.org/show_bug.cgi?id=54919

--- Comment #5 from Bartosz Dziewoński  ---
(In reply to comment #4)
> If I recall, previously there was a down arrow where you could
> access the tabs that were not visible which I thought was a good
> solution and similar to the solutions adopted in the major browsers
> like Chrome and IE8.

This was only done – and still is done – for the "History" link.
Don't ask me why.

> If a wrap around solution is preferred then could the text be moved
> down a line so that the wrap-around does not cover the heading?

It would require a large rewrite or an ugly hack. But it's technically
possible, yes.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l