[Wikitech-l] Re: Help in my tasks in Gerrit

2021-08-14 Thread Bartosz Dziewoński
For configuration changes (that is, any commit in the 
operations/mediawiki-config repository), you'll need to schedule them to 
be deployed, and then show up on IRC at the scheduled time to verify 
each change works as expected.


Please read https://wikitech.wikimedia.org/wiki/Backport_windows and 
follow the instructions under "How to submit a patch for backport". Thanks!


--
Bartosz Dziewoński
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

[Wikitech-l] Re: Changes to Readers-Web-Backlog

2021-07-15 Thread Bartosz Dziewoński
For tasks where you do not have the capacity to work on them, but which 
are not declined, can you instead re-open them and only remove the 
Readers-Web-Backlog project?



--
Bartosz Dziewoński
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

[Wikitech-l] Re: Need Help for MediaWiki Skin Development

2021-06-20 Thread Bartosz Dziewoński
I can't help much with Mustache, but I'll note that all of the older 
documentation is still valid. Skins that do not use Mustache templates 
are still supported.


--
Bartosz Dziewoński
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

Re: [Wikitech-l] Problem with git clone

2021-03-04 Thread Bartosz Dziewoński

I get the same problem occasionally:
https://phabricator.wikimedia.org/T263293

So far, it has always fixed itself after a few minutes or hours.
As a workaround I usually clone/pull from the GitHub mirrors instead.

--
Bartosz Dziewoński

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


Re: [Wikitech-l] The future of UploadWizard

2021-02-04 Thread Bartosz Dziewoński

On 2021-02-03 23:33, Strainu wrote:
One thing that puzzles me in that ticket is this phrase from Mark 
Traceur: "It might be better to look at something (slightly) more 
modern, like the upload dialog in core". Does anyone know what that 
dialog is? AFAIK the uploader in core (Special:Upload) hasn't changed in 
decades, except maybe for the look of the buttons. Its usability is 
rubbish compared to UW. Wikis used to (no, actually they still do) 
customize it using the uselang param,which messes with the user's 
settings. I can't really understand how that would be better...


The upload dialog is this: https://www.mediawiki.org/wiki/Upload_dialog

It's accessible from both the visual and wikitext editors (unless you 
disabled the toolbar), though their dialogs to insert image thumbnails.


--
Bartosz Dziewoński

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


Re: [Wikitech-l] How to get a list of usercontribs for a given date range?

2020-11-20 Thread Bartosz Dziewoński

On 2020-11-19 17:14, Shrinivasan T wrote:

How to add this info in the API documentation page?
https://www.mediawiki.org/wiki/API:Usercontribs


It's actually described on that page:


ucdir

   In which direction to enumerate:

   newer
   List oldest first. Note: ucstart has to be before ucend.
   older
   List newest first (default). Note: ucstart has to be later than
   ucend.


--
Bartosz Dziewoński

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


Re: [Wikitech-l] How to get a list of usercontribs for a given date range?

2020-11-18 Thread Bartosz Dziewoński

On 2020-11-18 12:56, John wrote:
Thats not how those parameters work. You use either or, not both. You 
are either going forward or backwards thru the contribs based on which 
you use. You need to apply some logic on the application layer to filter 
the results to what you need.


This is incorrect, you can use both 'ucstart' and 'ucend' in one query.

--
Bartosz Dziewoński

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


Re: [Wikitech-l] How to get a list of usercontribs for a given date range?

2020-11-18 Thread Bartosz Dziewoński
The contributions are listed in reverse chronological order (newest 
first), so your 'ucstart' and 'ucend' parameters also need to be 
reversed ('ucstart' is the newer timestamp, 'ucend' is the earlier). 
This works:


https://ta.wikisource.org/wiki/சிறப்பு:ApiSandbox#action=query=json=usercontribs=2020-11-17T19%3A34%3A26.000Z=2020-11-14T19%3A34%3A26.000Z=Fathima%20Shaila

Alternatively, you can choose to list the contributions in chronological 
order (earliest first) using 'ucdir=newer', in which case 'ucstart' and 
'ucend' are opposite, like in your original query:


https://ta.wikisource.org/wiki/சிறப்பு:ApiSandbox#action=query=json=usercontribs=2020-11-14T19%3A34%3A26.000Z=2020-11-17T19%3A34%3A26.000Z=Fathima%20Shaila=newer

--
Bartosz Dziewoński

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


Re: [Wikitech-l] PolyGerrit

2020-04-27 Thread Bartosz Dziewoński
I'm afraid that patch editing is not yet available in the new interface 
in the Gerrit version we're using :(


I occasionally switch to the old version for a moment when I need to do 
this (there's a "Switch to Old UI" in the page footer).


--
Bartosz Dziewoński

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] onVerifyFileUpload error message not displayed 'as is' in visual editor upload form

2020-01-24 Thread Bartosz Dziewoński
Can you share your code (or a reduced test case), and a screenshot of 
the error you're getting? I just tried writing the following hook: 
https://phabricator.wikimedia.org/P10258


And defined the error test in MediaWiki:Custom-test-error on my test wiki.

And the VisualEditor uploader displayed the expected error message: 
https://phabricator.wikimedia.org/F31532153


I was testing on MediaWiki 1.35.0-alpha, so perhaps something changed 
since 1.32.2, but please check if that method works for you.



--
Bartosz Dziewoński

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] How to alter the Visual Editor configuration object for tool bar

2020-01-24 Thread Bartosz Dziewoński

On 2020-01-13 12:48, Egbe Eugene wrote:

Yes it appears under "insert" -> 'more'.

Isn't there a way to make it visible on the tool bar so it is easy and more
visible to access?


We don't really support doing that, and there isn't a nice way to do it.

However, it is possible to change the toolbar configuration, if you 
really want. We do something similar to replace the default reference 
tools with the Citoid tools, so you could also do something similar. The 
relevant code is here: 
https://github.com/wikimedia/mediawiki-extensions-Citoid/blob/3c77db340bad572208f69b0cfb53a6c4dc069d5e/modules/ve.ui.Citoid.init.js#L113-L140



--
Bartosz Dziewoński

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Equivalence for using Template:Cite_Web with templates surrounding Wikicode

2020-01-07 Thread Bartosz Dziewoński

On 2020-01-07 08:57, Egbe Eugene wrote:

Thanks very much Bartosz, it works just fine with Cite. Just a follow up
question. *Is Cite responsible for rendering * *?*


Yes.

--
Bartosz Dziewoński

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Equivalence for using Template:Cite_Web with templates surrounding Wikicode

2020-01-06 Thread Bartosz Dziewoński
Sounds like you don’t have Cite installed?

On Monday, January 6, 2020, Egbe Eugene  wrote:

> Thanks very much Bartosz, I tried it on my VE sandbox page on en.Wikipedia
> and it works really cool. However, I get the following error on my local MW
> install
>
>  *jQuery.Deferred exception: ve.dm.MWReferenceModel is not a constructor
> TypeError: ve.dm.MWReferenceModel is not a constructor*
>
> I should be lacking a module or something. Please can you help with this?
>
> Thanks once more,
> --
> Eugene
>
> On Sat, Jan 4, 2020 at 10:10 AM Bartosz Dziewoński 
> wrote:
>
> > I am not really sure what you mean…
> >
> > Here's a complete example that inserts, basically, "Hello[1] world[2]"
> > (text with two different references):
> >
> > https://phabricator.wikimedia.org/P10038
> >
> > Does that help?
> >
> > --
> > Bartosz Dziewoński
> >
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l



-- 
Matma Rex
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Equivalence for using Template:Cite_Web with templates surrounding Wikicode

2020-01-04 Thread Bartosz Dziewoński

I am not really sure what you mean…

Here's a complete example that inserts, basically, "Hello[1] world[2]" 
(text with two different references):


https://phabricator.wikimedia.org/P10038

Does that help?

--
Bartosz Dziewoński

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Equivalence for using Template:Cite_Web with templates surrounding Wikicode

2019-12-31 Thread Bartosz Dziewoński
{{Cite web}} and similar templates can also be used outside of a  
tag, e.g. on a page like this: 
https://en.wikipedia.org/wiki/Review_aggregator#Bibliography (not the 
greatest example, but the best I could find quickly).


If you want it inside of a footnote, it's a bit complicated in visual 
mode, since the footnotes can be reused multiple times. The way it works 
is that there is a separate place in the document where the contents of 
every reference are placed (the "internal list"), and the location of 
the  contains only a small node that links to the internal list.


Manually constructing the data so that both these things refer to each 
other would be a pain, but there is a helper class that makes it more 
convenient, ve.dm.MWReferenceModel.


You'd use it like this:

https://phabricator.wikimedia.org/P10018

I adapted that example from the code in 
ve.ui.MWCitationDialog.prototype.getActionProcess, which is how VE 
itself inserts new references.


Hope that helps (and doesn't look too awful).


--
Bartosz Dziewoński

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] (no subject)

2019-12-16 Thread Bartosz Dziewoński

On 2019-12-16 10:46, Egbe Eugene wrote:

After writing to the VE surface from a Gadget, the page saves with just
empty '' tags with no text. I could be missing something in my
config for VE or use of the model. Please can I get a solution for this?

The sample data and the segment which writes to the model is found here[1].
[1] https://etherpad.wikimedia.org/p/sample_VE_model


Each item in the data array must be one character. I don't know how this 
ends up with '', but I get various exceptions when trying to 
type (or do anything with the editor) after running your snippet, so 
clearly something breaks terribly.


The corrected version would be like this:

var data = [
{type: 'mwHeading', attributes: {level: 2}},
'H', 'e', 'a', 'd', 'i', 'n', 'g', ' ', '2',
{type: '/mwHeading'}
];

Or, more convenient to write (using the "spread syntax" for arrays):

var data = [
{type: 'mwHeading', attributes: {level: 2}},
...'Heading 2'.split( '' ),
{type: '/mwHeading'}
];



--
Bartosz Dziewoński

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Changing the action button labels of a OO.ui.confirm dialog

2019-12-13 Thread Bartosz Dziewoński

You can actually customize the labels in OO.ui.confirm() too:

OO.ui.confirm( '...', {
actions: [
{ action: 'accept', label: 'Yes!', flags: 'primary' },
{ action: 'reject', label: 'No…', flags: 'safe' }
]
} ).done( function ( confirmed ) {
...
} );

Make sure to keep the `action: 'accept'` and `action: 'reject'` (the 
dialog uses this to make the two buttons do things), the other pieces 
can be changed.


--
Bartosz Dziewoński

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] mediawiki.api.edit

2019-09-25 Thread Bartosz Dziewoński
I think the least inconvenient solution would be to leave your 
dependency on 'mediawiki.api.edit' in extension.json unchanged, and 
conditionally register that module as an "alias" for mediawiki.api if it 
doesn't exist, using the ResourceLoaderRegisterModules hook.


You could even be super lazy and register it unconditionally in 
extension.json, it seems that the module from core will take precedence 
if it exists, but ResourceLoader will apparently log a warning for this.


--
Bartosz Dziewoński

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] InnoDB / MyISAM

2019-07-27 Thread Bartosz Dziewoński
The 'searchindex' table uses MyISAM because until recently, InnoDB did 
not support fulltext indexes, which MediaWiki uses for the search. All 
other tables should use InnoDB.


According to https://stackoverflow.com/a/9397060 fulltext indexes are 
available on InnoDB since MySQL 5.6.4. If you're running that version or 
newer, it is possible you could use InnoDB for that table, but as far as 
I know no one has tried it before.


According to https://www.mediawiki.org/wiki/Compatibility#Database 
MediaWiki only requires MySQL 5.5.8, so we can't change that in our 
table definitions (yet).


No idea about the 'math' table.


--
Bartosz Dziewoński

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] VE submodule path update

2019-06-03 Thread Bartosz Dziewoński
It has now been backported [1] to the currently supported MediaWiki 
branches: REL1_27, REL1_31 and REL1_32 [2].


[1] 
https://gerrit.wikimedia.org/r/q/I61a5e68e74176f9f25bddf154eb100b224a018f5

[2] https://www.mediawiki.org/wiki/Version_lifecycle

--
Bartosz Dziewoński

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] VE submodule path update

2019-06-03 Thread Bartosz Dziewoński

Yeah, probably!

For what it's worth, the REL1_31 branches etc. still work fine for me (I 
just tried cloning VE from scratch using REL1_31). I only get a message 
like "warning: redirecting to ..." when cloning/pulling. I wonder if you 
might be using an older Git version or something?


--
Bartosz Dziewoński

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] OOUI: problem with button groups

2019-04-15 Thread Bartosz Dziewoński
Using jQuery methods like .remove() and .empty() clears all event 
handlers from the removed elements. That's why the buttons no longer 
work after you remove them (using .empty()) and show them again.


To avoid this, you can use the .detach() method instead, or hide the 
elements rather than remove them. For example, instead of:


dialog.panelBottom.$element.empty().append(dialog.buttonSelect[item.data.group].$element);

You can write:

dialog.panelBottom.$element.children().detach();
dialog.panelBottom.$element.append(dialog.buttonSelect[item.data.group].$element);

--
Bartosz Dziewoński

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Uploading new versions of other people's patches to gerrit

2019-04-09 Thread Bartosz Dziewoński

On 2019-04-09 07:43, Isarra Yos wrote:

On 09/04/2019 05:17, Isarra Yos wrote:
This seems to be broken, or something. It's causing problems for 
collaboration. Please fix. 


I now hear that this is intentional for spam/vandalism reasons. This 
seems unwise. Regardless, where is the documentation about this? What is 
the recommended method to now collaborate on specific patches?


Hopefully this will not stay disabled forever, for I also miss the feature.

In the meantime, you can use the traditional Git way of generating patch 
files and sending them by email (or perhaps, in a modern twist, via 
Phabricator).


To generate a patch file of the most recent commit:

git format-patch -1

(that's 'dash one', and it's critical, because otherwise Git will 
generate patch files for ALL commits)


Then upload the generated file to Phabricator or something.

To apply such a patch file and turn it into a commit:

git am foo.patch

There are some other options for dealing with multiple dependent 
commits, if you ever need them.



--
Bartosz Dziewoński

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Visual Editor and Media namespace

2019-04-06 Thread Bartosz Dziewoński
As I wrote: We fixed this bug in VisualEditor for MediaWiki 1.33:
https://phabricator.wikimedia.org/T198511

Note that you’ll also need a fairly recent version of Parsoid (not sure how
their releases work).


-- 
Matma Rex
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Visual Editor and Media namespace

2019-04-06 Thread Bartosz Dziewoński
W dniu piątek, 5 kwietnia 2019 Carles Pina i Estany 
napisał(a):

>
> Hi,
>
> I've setup a Mediawiki for internal usage with VisualEditor.
>
> Using the "Edit Source" I can do something like:
> [[Media:Traduccio.jpg|test]]
>
> To have a direct link to a file (instead of the page landing page).
>
> Can I achieve the same using VisualEditor?
>
>
If you just type “Media:Traduccio.jpg” in the link dialog, it should work
as expected. Although I believe it might not have autocompletion, unlike
normal links.



> Even a more important question maybe, if a page had a Media link and
> then I use the Visual Editor somewhere in this page it gets changed by:
>
> [//localhost:8080/images/c/ce/Traduccio.jpg test]
>
> (note that this instance has $wgServer = "http://localhost:8080;; ,
> but I would like the link to stay as Media:File.jpg or at least to be
> like /images/c/ce/Traduccio.jpg without the hostname... but ideally
> leaving the Media)
>
> Is it possible using VisualEditor? Some configuration that needs to be
> changed?
>
> I downloaded it from here, shoul be this one:
> https://extdist.wmflabs.org/dist/extensions/VisualEditor-
> REL1_31-6854ea0.tar.gz
>
>
We fixed this bug in VisualEditor for MediaWiki 1.33:
https://phabricator.wikimedia.org/T198511

Note that you’ll also need a fairly recent version of Parsoid (not sure how
their releases work).


Thank you very much,
>
> --
> Carles Pina i Estany
> GPG Key 0x8CD5C157
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l



-- 
Matma Rex
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] resource loader; 1.32 alpha; 1.32 stable breaking change loading scripts in widgets

2019-04-04 Thread Bartosz Dziewoński
Best practice is to use the PHP methods which generate the required 
wrappers. Have a look at ResourceLoader::makeLoaderConditionalScript() 
and ResourceLoader::makeInlineCodeWithModule().


Alternatively, if it's possible, it is ideal to put the initialization 
code into another module and load it with addMobules() etc. as usual, 
instead of inlining the code in the HTML source.


--
Bartosz Dziewoński

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] New Gerrit privilege policy

2019-03-16 Thread Bartosz Dziewoński

On 2019-03-16 14:48, Merlijn van Deen (valhallasw) wrote:

1. According to the policy, self-+2'ing is grounds for revocation of Gerrit
privileges. For a Toolforge tool, self +2-ing is common and expected: the
repository is hosted on Gerrit to allow for CI and to make contributions
from others easier, not necessarily for the code review features.


The policy calls out this case as acceptable:

"For extensions (and other projects) not deployed to the Wikimedia 
cluster, the code review policy is up to the maintainer or author of the 
extension. Some non-Wikimedia extensions follow Wikimedia's policy of 
prohibiting self-merges, but there is no requirement of that. If you are 
the only person writing the extension and have nobody to review your 
change, or if the extension is abandoned, it is acceptable to self-merge 
your changes."


--
Bartosz Dziewoński

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Thank you Tuesday

2019-03-15 Thread Bartosz Dziewoński

Any day can be Tuesday if you really want.

* Thanks to Strainu for insightful comments on the "Backlog on bugs" thread.

* Thanks to Roan and Ed for stepping up to review major OOUI patches 
this week (and to Moriel, Cormac and Matthias who proposed said patches).


--
Bartosz Dziewoński

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Question to WMF: Backlog on bugs

2019-03-12 Thread Bartosz Dziewoński
I get an impression from this thread that the problem is not really the 
size of the backlog, but rather certain individual tasks that sit in 
said backlog rather than being worked on, and which according to John 
are actually major issues.


It's hard to disagree or agree with this without knowing which tasks it 
is actually about though.


--
Bartosz Dziewoński

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Community-Engineering gaps as defined in configuration

2019-03-11 Thread Bartosz Dziewoński

On 2019-03-09 16:12, Eran Rosenthal wrote:

- wmgUseSandboxLink
   - Enabled in 80 wikis. Why not enabling it everywhere?


It was enabled on all wikis that were already adding a link to a user's 
personal sandbox using site JS or a gadget enabled by default.


I wrote that extension as part of my volunteer work, and the goal was to 
improve page load performance on wikis that already had that link. In my 
experience discussing any interface changes to Wikimedia wikis is very 
unfun and I had no particular interest in doing that for this.


--
Bartosz Dziewoński

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Question to WMF: Backlog on bugs

2019-03-11 Thread Bartosz Dziewoński

On 2019-03-09 12:25, Strainu wrote:

The discussion athttps://lists.gt.net/wiki/wikitech/889489  is relevant, I
believe. The request there was to not decline low-priority issues that
might be resolved by volunteers and this clearly increases the number of
open bugs (as I said, there are good reasons for that :) ). There were a
number of proposals on how to track such issues so that reporters have a
clear image of the status of the bugs. Have any of them been tried by at
least one of the teams at wmf? If so, is there a way to share the results
with other teams? If not, how can we convince the wmf to give them a
chance?


In my experience WMF teams usually have a way to distinguish "bugs we're 
going to work on soon" and "bugs we're not planning to work on, but we'd 
accept patches". This is usually public in Phabricator, but not really 
documented.


For example for VisualEditor, if a task is put in the "Freezer" or 
"External" columns on the workboard [1], then we're not planning to work 
on it. I know other teams use a similar system, but the workboards were 
created independently by every group and have various differences.


[1] https://phabricator.wikimedia.org/project/board/483/?hidden=true

--
Bartosz Dziewoński

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Code sniff for verbose conditionals

2019-02-11 Thread Bartosz Dziewoński

On 2019-02-11 18:42, Daimona wrote:

Hi,
All patches in the codesniffer repo have a sample run against mwcore set up
in CI. As can be seen in [0], the current version is triggered 13 times by
MW core. No idea about extensions, though.
Daimona

[0]:
https://integration.wikimedia.org/ci/job/mw-tools-codesniffer-mwcore-testrun/966/console


Thanks for that link. I looked at them and submitted a change (please do 
not merge it) to demonstrate what changes this would require:

https://gerrit.wikimedia.org/r/c/mediawiki/core/+/489759

In my opinion most of these changes are clear improvement or harmless, 
except for the pattern in LBFactorySimple.php/LoadBalancer.php, which is 
a little tricky and probably clearer in the original version.


--
Bartosz Dziewoński

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Article geotags missing in geo_tags table for some WP languages?

2018-11-07 Thread Bartosz Dziewoński
The coordinates template/module needs to use the {{#coordinates:…}} 
parser function for the page to be geotagged.


--
Bartosz Dziewoński

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] non-obvious uses of in your language

2018-10-15 Thread Bartosz Dziewoński

On 2018-10-15 16:34, Trey Jones wrote:

I'm not sure how much impact it would have on existing link specifications
to make the change, but I think MGChecker has a good solution. The
"[[target|linktext]]extra" format allows you to specify exactly what part
of the text should have a link, while "[[target]]extra" would be understood
as a shortcut to "[[target|targetextra]]". This solves the linktrails
problem without introducing any extra tags or using nowiki in weird ways.


Sounds like a cute small syntax improvement! :)



Are their any other linktrails setting other than off and on? We'd want to
make sure any changes didn't do weird things to Chinese or other spaceless
languages.


There are two things to consider:

* Linktrails are language-specific. For example, in English, only ASCII 
a-z are handled in linktrails, while Polish also allows accented letters 
ęóąśłżźćńĘÓĄŚŁŻŹĆŃ. Chinese actually effectively disables linktrails 
(disallows everything). This is defined using $linkTrail variables in 
files like MessagesEn.php etc.


* There is also something called "linkprefix", used by e.g. Arabic 
(MessagesAr.php uses $linkPrefixExtension = true). I am not sure how 
this feature works, but it probably complicates everything a bit.


--
Bartosz Dziewoński

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Wikitech-ambassadors] Translations on hold until further notice

2018-10-04 Thread Bartosz Dziewoński
Good news: l10n-bot appears to be exporting translations again. I assume
crisis has been averted.

-- 
Matma Rex
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Wikitech-ambassadors] Translations on hold until further notice

2018-09-27 Thread Bartosz Dziewoński
As I understand, nothing terrible will happen if you add new messages to 
en.json. But new translations will not be added, so any new interfaces 
will be in English for everyone, which is a poor experience.


--
Bartosz Dziewoński

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Overriding MW core messages via extension

2018-09-06 Thread Bartosz Dziewoński

On 2018-09-06 22:33, James Montalvo wrote:

Is it possible to override messages part of MediaWiki core via an
extension. I tried adding to an extension's en.json file and that didn't
seem to work, but am wondering if there's another way.


Yes, but it's a bit of a hack. You have to define a different message 
(under a different key/name), then use the 'MessageCache::get' hook [1] 
to make MediaWiki load your message instead of the original one. On 
Wikimedia wikis we use this in the WikimediaMessages extension to use a 
different wording for some messages [2].


[1] https://www.mediawiki.org/wiki/Manual:Hooks/MessageCache::get
[2] 
https://phabricator.wikimedia.org/diffusion/EWME/browse/master/WikimediaMessages.hooks.php$15


--
Bartosz Dziewoński

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] OOUI v0.28.0 released

2018-08-20 Thread Bartosz Dziewoński
I grepped a bunch and at least the following projects still use the removed
icons:

mediawiki/extensions/BlueSpiceBlog
Uses 'newspaper' icon in resources/ve/ve.ui.BlogInspectorTool.js. It needs
a dependency on 'oojs-ui.styles.icons-editing-citation' to continue
displaying the icon. (Filed T202336.)

mediawiki/extensions/ProofreadPage
Uses 'clip' icon in modules/ve/node/ve.ui.MWPagequalityInspectorTool.js.
(Filed T202337.)

mediawiki/extensions/VisualEditor
Uses 'settings' icon in modules/ve-mw/ui/pages/ve.ui.MWSettingsPage.js.
(Apparently this has already been spotted by our excellent QA engineers and
reported in T202101. Thank you!)

oojs/ui
Heh, we still use the 'settings' icon in demos and documentation. Oops…
(Filed T202338.)

-- 
Matma Rex
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Tidy removed on all Wikimedia wikis (final update)

2018-08-16 Thread Bartosz Dziewoński
I'd like to offer additional thanks to Izno, who appears to be going
through all of the old Tidy-related tasks, meticulously testing to see if
they're fixed in Remex, and closing them! :)

-- 
Matma Rex
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] OOUI v0.28.0 released

2018-08-16 Thread Bartosz Dziewoński
Here's the complete list of renamed, moved or removed icons in each icon
pack. Your code will need updates if you're using any of them:

(I generated this with `git diff v0.27.6 v0.28.0 --
src/themes/wikimediaui/*.json` and some manual editing.)

icons-alerts:
* 'comment' – Use 'speechBubble' instead.

icons-content:
* 'book' – Moved to the 'editing-citation' pack.
* 'citeArticle' – Moved and renamed. Use 'reference' from
'editing-citation' pack.
* 'journal' – Moved to the 'editing-citation' pack.
* 'newspaper' – Moved to the 'editing-citation' pack.

icons-editing-advanced:
* 'find' – Use 'articleSearch' of 'content' pack instead.

icons-interactions:
* 'settings' – Use 'pageSettings' instead.

icons-moderation:
* 'clip' – Use 'bookmarkOutline' instead.
* 'unClip' – Use 'bookmark' instead.

icons-user:
* 'userActive' – Use 'userAvatar' instead.
* 'userInactive' – Use 'userAnonymous' instead.

-- 
Matma Rex
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] MediaWiki action api - query categories property of allimages list?

2018-08-04 Thread Bartosz Dziewoński
Yes, you have to use 'allimages' as a "generator" for a 
'prop=categories' query.


Example: 
https://en.wikipedia.org/w/api.php?action=query=categories=allimages=E


More about generators: https://www.mediawiki.org/wiki/API:Query#Generators

--
Bartosz Dziewoński

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Add modules=site.styles inline

2018-07-20 Thread Bartosz Dziewoński

Also, I should note that I tested with MW 1.32 alpha (Git master).
I don't know if older versions behave differently.

--
Bartosz Dziewoński

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Add modules=site.styles inline

2018-07-20 Thread Bartosz Dziewoński
I tested locally and deleting MediaWiki:Common.css removed the  
for 'site.styles' module from pages.


Make sure that you're not actually viewing cached page HTML that still 
has it.


Also make sure that you're not using the other MediaWiki pages that are 
included in this module: MediaWiki:Print.css and MediaWiki:Vector.css 
(or MediaWiki:Monobook.css, etc., depending on the skin).


If you still see this behavior and want to try debugging it, start in 
ResourceLoaderWikiModule::isKnownEmpty() and its callers, this is the 
method that decides whether the  will be generated.


--
Bartosz Dziewoński

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Add modules=site.styles inline

2018-07-20 Thread Bartosz Dziewoński
The  will not be generated if the page is actually deleted, rather 
than existing but empty.


--
Bartosz Dziewoński

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Add modules=site.styles inline

2018-07-19 Thread Bartosz Dziewoński
There is one important reason why we use  instead of 
…: when the rendered page HTML is cached, e.g. using a 
caching proxy like Varnish [1] or MediaWiki file cache [2], then if we 
used …, you would have to purge every page on the wiki 
before changes to MediaWiki:Common.css would actually take effect, 
because the CSS would be embedded in the cached HTML.


Using  means that it only takes as long as it takes the cached 
resource to expire in the users' browsers. (By default, they are set to 
expire after 5 minutes.)


If you don't have caching enabled, then of course that wouldn't matter – 
but also, if you don't have caching enabled, then that is probably a 
much worse performance problem than not embedding the styles :)


[1] https://www.mediawiki.org/wiki/Manual:Varnish_caching
[2] https://www.mediawiki.org/wiki/Manual:File_cache

--
Bartosz Dziewoński

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Please comment on the draft consultation for splitting the admin role

2018-06-11 Thread Bartosz Dziewoński

On 2018-06-11 15:28, Petr Bena wrote:

Is there any historical evidence that sysops being able to edit JS /
CSS caused some serious issues? Your point that "most of
administrators don't understand JS / CSS" is kind of moot. They are
usually trustworth and intelligent people. They don't mess up with
something they don't understand and therefore it makes little sense to
restrict them from being able to do that.


Yes, in the recent months there have been several incidents of a sysop 
accounts on Wikimedia wikis being taken over by an attacker, and the 
first thing done by the compromised accounts was adding nasty code to 
sitewide JavaScript to take over further accounts.



--
Bartosz Dziewoński

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Can/should my extensions be deleted from the Wikimedia Git repository?

2018-06-08 Thread Bartosz Dziewoński
On Fri, Jun 8, 2018 at 3:26 PM, Stephan Gambke 
wrote:
>
> It is not the first time that individual developers have misused their +2
> rights to sidestep community processes and enforce their political views.
> It is this kind of repeated overreach and casual disregard for the wishes
> and opinions of the repo owner that makes people choose GitHub over Gerrit.
>
> ...
>
> Incidentally, what is the procedure to request removal of +2 rights for
> somebody on my extension repo?
>

If you really wanted, and your extension is not deployed to Wikimedia
wikis, I think it could be done if you requested it on Phabricator. There
are definitely repositories where the "normal" +2 reviewers (able to +2/-2
patches in mediawiki/core and extensions) do not have access (e.g.
operations/mediawiki-config). But I'm not sure how it is implemented
technically, the reviewers' righs might apply to the "mediawiki/*
namespace"? in which case it could be a problem to change it for one repo.

In this particular case though, Chad is a Gerrit administrator, so he would
be able to merge the patch anyway. I don't think this problem calls for a
technical solution.

-- 
Matma Rex
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Can/should my extensions be deleted from the Wikimedia Git repository?

2018-06-08 Thread Bartosz Dziewoński
On Fri, Jun 8, 2018 at 12:56 PM, Nischay Nahata 
wrote:

> Also, its strange that someone can just remove someone else's code review
> just like that on gerrit, add their own review and merge a patch.
>

This ability is very useful in some cases - for example, imagine a
VisualEditor patch marked as "-2 Do not merge until Parsoid patch  is
deployed"; after said deployment, it is normal for someone else to remove
the -2 review and approve the patch (imagine further that the original
reviewer is on vacation).

Note that only people with the right to give -2/+2 reviews can remove
others' reviews. The fact that the review was removed is recorded in a
comment, so the potential for abuse seems low.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] function drawmap not defined when loading external js with resourceLoader

2018-06-04 Thread Bartosz Dziewoński
Scripts loaded via ResourceLoader are not executed in global scope, so 
your variables/functions will not be global.


To make them global, you have to explicitly attach them to the `window` 
object – add this at the end of your external_script.js:


window.drawmap = drawmap;

--
Bartosz Dziewoński

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] 2018-05-02 Scrum of Scrums meeting notes

2018-05-07 Thread Bartosz Dziewoński

On 2018-05-06 08:33, Federico Leva (Nemo) wrote:

Jargon such as "AFC improvement" would use a link.


Assuming you meant to ask what it means, I believe this refers to 
English Wikipedia's "Articles for Creation" process: 
https://en.wikipedia.org/wiki/Wikipedia:WikiProject_Articles_for_creation


--
Bartosz Dziewoński

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Getting a local dump of Wikipedia in HTML

2018-05-03 Thread Bartosz Dziewoński

On 2018-05-03 20:54, Aidan Hogan wrote:
I am wondering what is the fastest/best way to get a local dump of 
English Wikipedia in HTML? We are looking just for the current versions 
(no edit history) of articles for the purposes of a research project.


The Kiwix project provides HTML dumps of Wikipedia for offline reading: 
http://www.kiwix.org/downloads/


Their downloads use the ZIM file format, looks like there are libraries 
available for reading it in many programming languages: 
http://www.openzim.org/wiki/Readers


--
Bartosz Dziewoński

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Mobile MonoBook

2018-04-03 Thread Bartosz Dziewoński

Retraux. Pretty metal.

--
Bartosz Dziewoński

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] OOUI 0.26.0 release

2018-03-21 Thread Bartosz Dziewoński

On 2018-03-21 05:20, Volker E. wrote:

The Design team at the Wikimedia Foundation has established new icon
guidelines over the course of recent months – resulting in a new set
which is part of this release. The set features improved universality,
consistency, neutrality, developer-friendliness and RTL language
support.


Important note to follow-up on this, if your application has any custom 
icons: the old icons were 24x24px, while the new ones are 20x20px.


The dimensions of the graphics are actually mostly unchanged (the old 
ones were drawn with large "margins"), but you will need to adjust your 
icon files, otherwise they will be scaled down to 20px and look rather 
small compared to built-in icons.


If your icons already fit the guidelines [1], you can often just trim 
the canvas by 2px on each side.


I've updated some extensions in Wikimedia version control, but others 
will need work from their maintainers [2] – at a quick glance, this 
includes CodeEditor, CodeMirror, ContentTranslation, Echo, Flow, 
Kartographer, and MobileFrontend.


[1] 
https://wikimedia.github.io/WikimediaUI-Style-Guide/visual-style_icons.html

[2] https://phabricator.wikimedia.org/T177432#4066077

--
Bartosz Dziewoński

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Some images are not visible in the preview when you hover over a link to another wikipedia webpage

2018-01-01 Thread Bartosz Dziewoński
I am guessing you are using "Page previews": 
https://www.mediawiki.org/wiki/Page_Previews


(This has to be enabled by each user on 
https://fr.wikipedia.org/wiki/Spécial:Préférences under "Aperçus de page".)


The tool loads its data from here:

https://fr.wikipedia.org/api/rest_v1/page/summary/Pince_à_avoyer
https://fr.wikipedia.org/api/rest_v1/page/summary/Pince_universelle

The first of these pages has a "thumbnail" defined, the second doesn't. 
Unfortunately I don't know what generates this data, but perhaps someone 
else can help.


--
Bartosz Dziewoński

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] FLIF for Wikimedia

2017-12-11 Thread Bartosz Dziewoński
If you want to work on implementing support for FLIF, I would recommend 
doing it as an extension (similar to e.g. 
https://www.mediawiki.org/wiki/Extension:PdfHandler) rather than in 
MediaWiki core.


--
Bartosz Dziewoński

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] On InvalidArgumentException and user-facing errors

2017-12-07 Thread Bartosz Dziewoński

On 2017-12-07 21:05, Chad wrote:

Yeah, and when you throw ErrorPageError deep enough in a code path, it can
explode on cli operations. I've seen this before.


Indeed you did, you even fixed this bug a couple months ago ;)
I'm pretty sure it's safe to use now.

25c3c061b51cbfe377ebb2decbe09f7db7bc7397
https://gerrit.wikimedia.org/r/#/c/363660/

--
Bartosz Dziewoński

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] On InvalidArgumentException and user-facing errors

2017-12-07 Thread Bartosz Dziewoński
For "expected" exceptions, you can throw ErrorPageError or one of its 
subclasses, which is handled internally to produce a pretty user-facing 
error page.


--
Bartosz Dziewoński

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Engineering] Tech talk: Selenium tests in Node.js

2017-10-30 Thread Bartosz Dziewoński

On 2017-10-31 01:36, John wrote:

Željko, Im tempted to throw a {{trout}} at you. Please never repeat what
you did in this post and talk via emoji. We do not write in hieroglyphics.


Luckily enough, everything was also written in normal text 

--
Bartosz Dziewoński

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Editing module in the wiki editor lead to overloading resouces of processor

2017-10-30 Thread Bartosz Dziewoński

When you next experience the issue, you can try to debug it:

0. You should be viewing the page using MediaWiki's debug mode to make 
the results easier to interpret (add =1 to the page address). Note 
that this will make pages load slower.
1. Open the Firefox developer tools (Ctrl+Shift+I, or Tools → Web 
Developer → Toggle Tools).

2. Switch to the "Debugger" tab.
3. Click the "Pause" button.

Screenshot: https://phabricator.wikimedia.org/F10524704 (this is Firefox 
57 on Windows 10, but the layout should be similar everywhere)


This will pause the execution of JavaScript on the page and reveal the 
script that was executing (if nothing is currently executing, it will 
pause at the beginning of the next function to execute). You can 
right-click the file name to copy/reveal the full path of the script.


For example, in this screenshot the execution paused inside the code to 
toggle the blinking cursor in the CodeMirror editor: 
https://phabricator.wikimedia.org/F10524713


(Please also take a screenshot of the entire debugger when filing a task 
about this, the "Call stack" on the right is very useful if the script 
itself is large.)


Afterwards click the "Resume" button (in the same location as "Pause") 
to let the page continue executing. Try doing this a few times, in case 
multiple scripts are running, to increase the chance of seeing each one.



--
Bartosz Dziewoński

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Person of interest to blame

2017-10-11 Thread Bartosz Dziewoński
(For future reference, this seems to be related to
https://phabricator.wikimedia.org/T176367 and there was an answer there.)

On Wed, Oct 4, 2017 at 1:16 PM, יגאל חיטרון  wrote:

> Thank you all.
> ​Unfortunately, I can't create my wiki. I have no skills or ability to do
> this.
> I checked the list of tasks you sent, and maybe one of them fits, and maybe
> not. This one talks about the watchlist disign copyed to another engine, as
> far as I understood. Maybe during this move the bug that did not bolded
> unseen revidions inside the groups "fixed by itself", who knows.
> Igal
> ​
>
> 2017-10-03 22:48 GMT+03:00 Brian Wolff :
>
> > Realistically its probably in the enhancedChanges list base class
> somewhere
> > and not watchlist itself.
> >
> > --
> > bawolff
> >
> > On Tuesday, October 3, 2017, C. Scott Ananian 
> > wrote:
> > > git log includes/specials/SpecialWatchlist.php suggests:
> > >
> > > T172757 / I27bdaa1401323fa3143f79a57dc5b9773e48fd1d (sep 27)
> > > T176857 / I90c79ef9c4819a34060515b863277fd185828ed9 (sep 27)
> > > T176348 / If6280ad6fbad65909e1d0b2a48344e24d485aca2 (sep 21)
> > > T173533 / I4138fde22bdd8cc55c65846b91184c3ad3057244 (sep 19)
> > > T176155 / Idc4e450c9fa03fc78a012fb5eefa60174bb1245a (sep 18)
> > > T175965 / I14ba792f1cd435f89b2e09067b0a0e894a0a2557 (sep 14)
> > > T168376 / I3c75f9f2f6287414bf330f116d959d078250392d (aug 23)
> > > T174725 / I1cb402559edb242b40a77f509480560f0636264d (sep 1)
> > > T172030 / I65c50d75b21b3e5d7b69fdecb79c032f5d1d8853 (aug 31)
> > > -  / I1c50b67b0a4aaddb561e79fdacd9849ffe0ded8c (aug 31)
> > > and a bunch more in late august related to "WLFilters".
> > >
> > > As Sebastien suggests, the easiest way to identify the problem is to
> run
> > a
> > > local copy and use git-bisect to identify exactly where the problematic
> > > change occurred.
> > >  --scott
> > >
> > >
> > > On Tue, Oct 3, 2017 at 2:37 PM, יגאל חיטרון 
> > wrote:
> > >
> > >> Hello. There was a patch, or a bug, or a bug fix in the last month
> that
> > I'm
> > >> trying to find. Something changed the Special:Watchlist view and
> broke a
> > >> couple of gadgets. I wanted to find what was the gerrit patch, or at
> > least
> > >> some explanation, what exactly was done, but nobody knows (Thanks a
> lot
> > to
> > >> Quiddity which spent many time trying to help, you are awesome).
> > >> The problem is different HTML structure of Special:Watchlist, at least
> > when
> > >> "Group changes by page in recent changes and watchlist" in preferences
> > is
> > >> on. I even can't describe the difference, because it's just "looks
> > >> different". I read a roadmap for the last 50 days, and can't find
> > anything.
> > >> A couple of people I asked can't help. One of the symptoms is
> different
> > css
> > >> inside the revisions groups, bold vs unbold.
> > >> Maybe somebody can help to find a gerrit to blame? Thank you,
> > >> Igal (User:IKhitron)
> > >> ___
> > >> Wikitech-l mailing list
> > >> Wikitech-l@lists.wikimedia.org
> > >> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> > >
> > >
> > >
> > >
> > > --
> > > (http://cscott.net)
> > > ___
> > > Wikitech-l mailing list
> > > Wikitech-l@lists.wikimedia.org
> > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>



-- 
Matma Rex
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] The target revision does not exist

2017-10-01 Thread Bartosz Dziewoński
This issue seems to be filed as .

-- 
Matma Rex
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Wiki farm configuration

2017-09-11 Thread Bartosz Dziewoński

On 2017-09-11 15:41, Manuel Vacelet wrote:

It is recommended to use a different DB for each wiki (By setting a
different $wgDBname
<https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:$wgDBname> for
each wiki). However if you are limited to a single database, you can use a
different prefix ($wgDBprefix
<https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:$wgDBprefix>)
to separate the different installs.


But it's not detailed why it's recommended. I'd like to know if there is
any downside of using the prefix strategy (peformances, upgrades, etc) ?


I think the only downside is that you'll have to keep the prefixes in 
mind when writing your own SQL queries. Making and restoring database 
backups for individual wikis will also be less convenient.


You might also occasionally run into bugs in extensions which did not 
keep the prefixes in mind in their SQL queries. But I've had table name 
prefixes on my development wiki for years and don't remember the last 
time I ran into this.


--
Bartosz Dziewoński

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Update to web print styles

2017-08-30 Thread Bartosz Dziewoński
On Mon, Aug 28, 2017 at 10:18 PM, Isarra Yos  wrote:

> Are these changes in core, or in the skins themselves (Vector and
> Minerva)? In other words, will printing from other deployed skins such as
> MonoBook also see improvement, or is it up to the maintainers of each other
> skin to independently apply similar changes?
>

As far as I know, the big features are only in Vector, but core styles have
also received a few tweaks.

https://gerrit.wikimedia.org/r/#/q/message:print+(project:mediawiki/core+OR+project:mediawiki/skins/Vector)+is:merged


-- 
Matma Rex
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Timeless skin now available on mw.org

2017-08-12 Thread Bartosz Dziewoński
W dniu sobota, 12 sierpnia 2017 Amir Ladsgroup 
napisał(a):

> It's fantastic, it will be my default skin when it gets deployed in
> Wikipedia.
>
> One thing: OOjs UI has a different theme for monobook (apex theme) and for
> vector the theme is "mediawiki", Are you planning to design another OOjs UI
> theme for this skin?
>
>
Timeless has some styles for MediaWiki UI buttons and forms, extending that
to other things included in OOjs UI is probably possible.

The main obstacle right now would be that skins have no way to define their
own custom OOjs UI theme - I have change
https://gerrit.wikimedia.org/r/#/c/343239/ pending review which would allow
that.


-- 
Matma Rex
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Timeless skin now available on mw.org

2017-08-11 Thread Bartosz Dziewoński
On Fri, Aug 11, 2017 at 7:31 PM, Kartik Mistry <kartik.mis...@gmail.com>
wrote:
>
> Nice work! It took me sometime to find language selector, but other
> than that, looks very nice!
>

If you mean on mediawiki.org (with its configuration to put it in the
personal bar) – I think somebody was suggesting today that we should pull
out the ULS menu item out of the dropdown, like we already do for Echo
notifications. I don't think there's a task for this yet.

-- 
Bartosz Dziewoński
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Log of nulledits

2017-07-25 Thread Bartosz Dziewoński
I've looked over the code briefly and it looks like null edits are not 
logged in any way, not even in private server logs.


However, for the purposes of preventing abuse, null edits check the 
'linkpurge' rate limit (which is set to 30 actions per minute by 
default), and exceeding rate limits is logged in server logs.


--
Bartosz Dziewoński

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] SkinOOUIThemes

2017-07-18 Thread Bartosz Dziewoński
Currently it is not possible to use a custom theme without hacking core 
a little bit. I've actually worked on implementing this, and a lot of 
work went through [1], but the important patches are still waiting for 
review [2] (they're low priority mostly because not that many people are 
asking for the feature). See T100896 [3] for more.


Using OOjs UI widgets with no styles at all is not necessarily a good 
idea – we still need *some* styling for basic things, like having the 
contents of dropdown lists actually hide while they are not open, etc.
OOjs UI includes a theme called "Blank" which kind of does that, but 
MediaWiki doesn't currently make it available. I'm not sure if it is 
actually complete enough to be used in practice.


[1] 
https://gerrit.wikimedia.org/r/#/q/status:merged+topic:custom-ooui-themes

[2] https://gerrit.wikimedia.org/r/#/q/status:open+topic:custom-ooui-themes
[3] https://phabricator.wikimedia.org/T100896

--
Bartosz Dziewoński

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [WikimediaMobile] MobileFrontend disruption: Plans to break Minerva out into its own repository

2017-07-04 Thread Bartosz Dziewoński

On 2017-07-04 19:46, יגאל חיטרון wrote:

Hi. The link [5] is dead.
IKhitron



It seems the list formatting broke it. The correct link is:

https://www.mediawiki.org/wiki/Reading/Web/MobileFrontend_and_Minerva#..._but_why_do_we_care_about_Minerva_as_a_desktop_skin.3F

Shortened: http://tinyurl.com/y8jl2526


--
Bartosz Dziewoński

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] "Unloading"/reloading ResourceLoader modules the proper way?

2017-06-19 Thread Bartosz Dziewoński
I don't think "unloading" modules will ever be a thing. While
ResourceLoader could be made to keep track of modules' CSS to be able to
remove it, we can't "unload" JavaScript modules at all (because their code
has already executed), so I'm not sure if we'd want to add such special
case.

If you want a slightly less horrible hack than you do now – you could
generate an appropriate load.php URL yourself (with =styles) and add
that in a  tag to the page, much like we did back in the old days
with importStylesheetURI(). ResourceLoader won't even know the module is
loaded. And this way, you can remove the  tag later without messing
with ResourceLoader's internals.

-- 
Matma Rex
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Fwd: OOjs UI 0.22.0 release (breaking change)

2017-06-05 Thread Bartosz Dziewoński
Some extra notes on the more interesting breaking/deprecating changes:

Breaking changes since last release:
>
> [...]
>
> * icons: Drop the deprecated core icon pack (James D. Forrester)
> Dropped 'core' icon pack, deprecated in v0.20.1 and already moved all
> of its icons
> to different, more clearly labelled, icon packs back then. Now removed
> entirely.
>

This affects a large number of extensions. James and I have been working on
updating them on task T166730 [1], and all of the extensions in Wikimedia
production are by today updated (or have patches awaiting review), but a
few others still need updates. Feel free to help, especially for projects
you maintain.

[1] https://phabricator.wikimedia.org/T166730


Deprecations since last release:
>
> * Rename the 'MediaWiki' theme to 'WikimediaUI' (James D. Forrester)
> In order to clarify and simplify connection between the default theme's
> development focus on Wikimedia user interfaces and connected resources
> we've decided to rename it. Currently there's an alias for the old name,
> which
> should allow your software to work as is. Still, consider renaming your
> style
> and script references in the time being.
>

MediaWiki has been updated for this and this is unlikely to affect your
code, unless you hardcoded the theme name somewhere.


>
>

> [Deprecations since last release:]

* WindowManager: Deprecate using `openWindow`/`closeWindow` returns as
> promises (Bartosz Dziewoński)
> The return value is now a WindowInstance object. Rather than using the
> "nested promises" to wait for window to open/close, you should instance use
> its
> properties (opening, opened, closing, closed) to wait for the given
> step of window
> lifecycle.
>

This also affects a number of extensions, some in Wikimedia production.
I've updated a few of them on task T166729 [2], but more remain; feel free
to help, especially for projects you maintain. You will see deprecation
warnings for the deprecated usage.

[2] https://phabricator.wikimedia.org/T166729

On Tue, Jun 6, 2017 at 1:04 AM, James Forrester <jforres...@wikimedia.org>
wrote:

> Hello everyone,
>
> It looks like Volker's e-mail, below, didn't get distributed by the list on
> Wednesday; re-sending now. With apologies.
>
> -- Forwarded message --
> From: Volker Eckl <vol...@wikimedia.org>
> Date: Wed, May 31, 2017 at 1:30 AM
> Subject: OOjs UI 0.22.0 release (breaking change)
> To: Wikimedia developers <wikitech-l@lists.wikimedia.org>
>
>
> Hello everyone,
>
> We've released OOjs UI 0.22.0, today. It will be in MediaWiki core from
> 1.30.0-wmf.4, which will be deployed to Wikimedia production in
> the regular train, starting on Tuesday 6 June. As there are three breaking
> changes in this release, at least nominally, please carefully consider if
> they
> affect your code.
>
>
> Breaking changes since last release:
>
> * TextInputWidget: Remove deprecated search related methods (Prateek
> Saxena)
> After being deprecated back in v0.18.0, we removed search related
> methods entirely. The TextInputWidget got slimmed down and a more
> specialized SearchInputWidget is available since November 2016.
> If you still use search methods, please switch over to SearchInputWidget.
>
> * icons: Drop the deprecated core icon pack (James D. Forrester)
> Dropped 'core' icon pack, deprecated in v0.20.1 and already moved all
> of its icons
> to different, more clearly labelled, icon packs back then. Now removed
> entirely.
>
> * icons: Remove unused 'bookmark' icon (Volker E.)
> The 'bookmark' icon has been added, but has never been used in
> production nor is it planned, so it got removed.
>
>
> Deprecations since last release:
>
> * Rename the 'MediaWiki' theme to 'WikimediaUI' (James D. Forrester)
> In order to clarify and simplify connection between the default theme's
> development focus on Wikimedia user interfaces and connected resources
> we've decided to rename it. Currently there's an alias for the old name,
> which
> should allow your software to work as is. Still, consider renaming your
> style
> and script references in the time being.
>
> * WindowManager: Deprecate using `openWindow`/`closeWindow` returns as
> promises (Bartosz Dziewoński)
> The return value is now a WindowInstance object. Rather than using the
> "nested promises" to wait for window to open/close, you should instance use
> its
> properties (opening, opened, closing, closed) to wait for the given
> step of window
> lifecycle.
>
>
> Additional details are in the full changelog[0]. If you have any
> further queries or need help dealing with breaking changes, please let
> me know. As always, a general set of lib

Re: [Wikitech-l] Editing JSON in MediaWiki

2017-04-10 Thread Bartosz Dziewoński

On 2017-04-10 06:17, Denny Vrandečić wrote:

On Sat, Apr 8, 2017 at 11:30 PM James Hare <jamesmh...@gmail.com> wrote:


Why, exactly, do you want a wikitext intermediary between your JSON and
your HTML? The value of wikitext is that it’s a syntax that is easier to
edit than HTML. But if it’s not the native format of your data, nor can
browsers render it directly, what’s the point of having it?



Ah, good question indeed. The reason is that users would be actually
putting fragments of wikitext into the JSON structure, and then the JSON
structure gets assembled into wikitext. Not only would I prefer to have the
users work with fragments of wikitext than fragments of HTML, but some
things are almost impossible with HTML - e.g. making internal links red or
blue depending on the existence of the article, etc.


It would be more reliable to parse each fragment of wikitext separately, 
and then build the HTML out of them. If you try to make a big chunk of 
wikitext with user-supplied fragments, you'll soon run into two problems:


* Users will accidentally put '' or something into one of the 
fields and completely mess up the rendering.
* Users will intentionally put '[[Foo|' in one field and ']]' into 
another and then be mad at you when you change the structure in a minor 
way and their link no longer works.


--
Bartosz Dziewoński

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Error when using OOjs UI/Windows/Message Dialogs

2017-02-22 Thread Bartosz Dziewoński
Looks like you're not loading the OOjs UI code you're trying to use. 
Assuming that you're writing this as part of MediaWiki (or an 
extension), you need to add a dependency on the 'oojs-ui' ResourceLoader 
module.


--
Bartosz Dziewoński

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] MediaWiki-Vagrant needs testers for Debian Jessie changes

2017-02-15 Thread Bartosz Dziewoński

It works! (On Windows, do setup.bat rather than ./setup.sh.)

This is actually the third time I'm trying MediaWiki-Vagrant, and the 
first time I've gotten it to run (previous attempts ended with obscure 
error messages). So I'd say the Jessie migration was a success :)


--
Bartosz Dziewoński

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Mediawiki core has reached to its 400th contributor

2017-02-07 Thread Bartosz Dziewoński
The commits from SVN era are confounded in both directions. On one hand,
like Brian says, people who still commit today are counted double. On the
other, patches that were submitted through Bugzilla or mailing lists by
one-time contributors are counted under the name of the committer who
applied them (and not the real author), unlike today when you submit them
through Gerrit.

-- 
Matma Rex
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] catching errors in local JavaScript

2017-01-19 Thread Bartosz Dziewoński
Oh, and also, a more general limitation: the error messages may be 
localised, depending on the browser. I hope you speak Korean.


--
Bartosz Dziewoński

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] catching errors in local JavaScript

2017-01-19 Thread Bartosz Dziewoński
UploadWizard has such a mechanism, recording all JavaScript exceptions 
that happen on https://commons.wikimedia.org/wiki/Special:UploadWizard
(using some of the machinery originally designed for Sentry, some custom 
glue code, and some EventLogging definitions).


Using EventLogging mostly works, but it has some strict limitations on 
the size of data you can record there, so we can't save for example 
error backtraces. That's still much better than nothing at all, though.


You'll also find that, unless a problem is affecting literally everyone 
on every page, it's really difficult to separate problems in code you 
can fix from problems in code you can't. Turns out that a large number 
of people use very broken browser extensions, or user scripts, or 
browser, or entire computers, that throw exceptions left and right 
whenever the user looks at it wrong. Since browsers' security features 
and ResourceLoader's mechanisms often hide the real source of the error, 
you have to investigate everything by hand. And that's my experience 
only looking at errors happening on one page, on one wiki. :)



--
Bartosz Dziewoński

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] I8n

2017-01-07 Thread Bartosz Dziewoński
No.

-- 
Matma Rex

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] SOLVED Re: VisualEditor in 1.28 - fails after upgrade from 1.27

2016-12-19 Thread Bartosz Dziewoński

On 2016-12-20 06:22, Daniel Barrett wrote:

The real issue is that a custom callback for the hook "SpecialPages_initList" is 
invoking RequestContext::getMain()->getUser()->isLoggedIn().

Apparently that doesn't work.

I'll take a guess that SpecialPages_initList runs too early for this check to 
succeed?


My goal is to remove some special pages for anonymous users but permit 
logged-in users to see them.
Is there a better way to check for a logged-in user at this hook point? Or a 
better way to remove
special pages for anonymous users?


Yes, the list of special pages can't depend on anything related to the 
current user.


Instead, you should check whether the user is logged in when displaying 
the special page. You can just call `$this->requireLogin();` at the 
beginning of the special page's execute() function – this will check 
whether the user is logged in, and if not, display an error message and 
abort execution. You can optionally pass a custom error message. See 
e.g. /includes/specials/SpecialWatchlist.php in MediaWiki for an example.


--
Bartosz Dziewoński

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Development on img_auth.php

2016-12-16 Thread Bartosz Dziewoński
img_auth.php is used in some private Wikimedia wikis, so you might be 
able to get WMF people to review your changes. It also means that they 
will be scrutinized more closely before they're merged.


--
Bartosz Dziewoński

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] About the frontend development tools we use

2016-11-23 Thread Bartosz Dziewoński
On Fri, Nov 18, 2016 at 11:16 AM, Niklas Laxström
 wrote:
> I was reading http://stateofjs.com/2016/introduction/#sections and
> could not avoid noticing that the frameworks or technologies we use
> are not among the most popular or most liked among the participants of
> this survey.
>
> Examples:
> * Frontend frameworks: We use jQuery and OOjs UI. The latter does not
> appear at all in the list, jQuery is not in the top ten. This question
> might be biased though on what people perceive as a framework.

I definitely wouldn't call jQuery a framework. (My rule of thumb is:
if you call its functions, it's a library. If it calls your functions,
it's a framework.) But it's interesting how low it appears. I guess
jQuery provides less functionality over bare JavaScript in modern
browsers.

Given that OOjs UI was developed by us, for our needs, and that we've
put basically no effort into promoting it (folks have gotten it on
https://cdnjs.com/ recently, though), I'm not surprised no one outside
of us heard of it.


> * Testing framework: We mostly use qUnit, Cucumber, Selenium. Of these
> only Cucumber appears in the top 6 and it has very low satisfaction
> (people who have used do not like it).

QUnit wasn't even in their survey, yet it took second place among the
"write-in" votes.

Parsoid uses Mocha (the most popular in the survey) for testing. We
experimented with Jasmine (second most popular) in MediaWiki around
2012, but it was abandoned in favor of QUnit.


> * CSS tools: We use plain CSS and Less. Less has considerable lower
> satisfaction than SASS/SCSS and is less popular.

CSS has high usage and satisfaction scores though. I always said
allowing Less was a mistake ;)

Less is more accessible than SASS to developers who know CSS,
syntax-wise. SCSS is almost the same though, I honestly don't see why
you'd prefer one to the other.

We experimented with SCSS too, for MediaWiki UI styling. It was
abandoned in favor of Less in 2013, mostly because we have Less
support and SCSS required a build step before committing.


> * Build tools: We don't use these in core to my knowledge, but many
> extensions seem to use Grunt for running linting tools. Again, Grunt
> has very low satisfaction compared to other tools.

Just about everything that includes any JavaScript code uses Grunt for
linting, including MediaWiki core.


-- 
Matma Rex

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Update on WMF account compromises

2016-11-21 Thread Bartosz Dziewoński
Just for the record, I'm not having such problems, so it might be in 
some way specific to you. I've heard someone else recently complaining 
about getting logged in often, I don't think this is related to 2FA.


If you need to disable it, you can do it yourself (visit Preferences, 
click "Disable two-factor authentication" and follow the steps).


--
Bartosz Dziewoński

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Deploying the UrlShortener extension to Wikimedia wikis

2016-11-12 Thread Bartosz Dziewoński
The restricted task there is actually a straight duplicate of T44085
(it's closed and marked as such). It's private because it was imported
from the internal RT issue tracker as part of the migration ot
Phabricator. I removed it as a blocker.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Erroneous duration of block

2016-11-04 Thread Bartosz Dziewoński
Tgr noticed that this is apparently filed as
https://phabricator.wikimedia.org/T55907.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Erroneous duration of block

2016-11-04 Thread Bartosz Dziewoński
The problem seems to be in the block log formatter. 
BlockLogFormatter::getMessageParameters() calls 
Language::translateBlockExpiry() to format the string "2 months" (and 
translate it). That in turn uses strtotime() to parse this value, and 
does not specify the $now parameter correctly, so January 1, 1970 is 
assumed. And two months, counting from January 1, 1970, is 59 days. Two 
months counting from today, when you made the block, is 61 days, and 
this correctly appears everywhere else (the block expires 
2017-01-04T06:30:06Z).


BlockLogFormatter::getMessageParameters() and 
Language::translateBlockExpiry() should probably be fixed to use the 
date when the block was made for the $now parameter of strtotime().


--
Bartosz Dziewoński

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Need example code in Javascript to login API

2016-10-26 Thread Bartosz Dziewoński
Firstly, I'm afraid that page might not be up to date; there have been 
some changes to modernize the login API recently, and that page was last 
updated in 2013. The canonical documentation is 
<https://www.mediawiki.org/wiki/API:Login> (in English).


Secondly, login API is mostly intended for scripts running in the 
context of the wiki you want to log in to, not for scripts running on 
other pages or browser extensions. I'm not an expert on this, but I 
think you'll want to look into using OAuth: 
<https://www.mediawiki.org/wiki/OAuth>.


--
Bartosz Dziewoński

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Gerrit screen size

2016-09-26 Thread Bartosz Dziewoński
Indeed, the interface is pretty terrible and pretty wide. I also have
a bunch of CSS tweaks locally (mostly to make the "Verified" column
narrower, which Bryan's CSS also does).

Another thing I would recommend is going to Settings → Preferences,
and removing a bunch of entries you don't use from "My Menu" (or
editing them to make labels shorter). It made a big difference in
making the interface fit on my screen.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] RAND for sql

2016-07-30 Thread Bartosz Dziewoński

You have to do it like this:

'ORDER BY' => 'rand()',

Note that 'rand()' is in quotes, to send this string to MySQL and call 
the SQL rand() function – otherwise, you'd call the rand() function in 
PHP and send a random number to MySQL.


In general this is a bad idea, though, since this doesn't mean "select a 
random row and return it" – it means "select all rows, order them 
randomly, then return the first one", which is going to quickly become 
slow if you have more than a couple thousand of rows.


The page_random column John suggested in used for MediaWiki's built-in 
random page functionality, and a much better idea. You would use 
something like:


'page_random >= ' . wfRandom(),

…in the WHERE condition. See how it's used in MediaWiki:
https://phabricator.wikimedia.org/diffusion/MW/browse/master/includes/specials/SpecialRandompage.php;4de667f3c2dd2fea0f246a313a9ed848a793ed2f$116


--
Bartosz Dziewoński

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [[Link]]s deprecated?

2016-07-27 Thread Bartosz Dziewoński

No, of course it's not deprecated.

--
Bartosz Dziewoński

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Gerrit 2.12.2 test instance - PLEASE TEST

2016-07-25 Thread Bartosz Dziewoński

On 2016-07-25 16:25, Ed Sanders wrote:

Will it show multiple children (split trees?)


Yes, unless something changed from how the "new change screen" option 
behaved on 2.8. But it'll just shove all the ancestors and all the 
descendants into a single list.


--
Bartosz Dziewoński

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Gerrit 2.12.2 test instance - PLEASE TEST

2016-07-25 Thread Bartosz Dziewoński

On 2016-07-25 16:20, Ed Sanders wrote:

Where do I find links to the parent commit and child commit(s)? All I can
see currently is a link to the parent's diffusion commit(?!).

As someone who often commits a stack of 5+ dependent commits, these are
very useful to my workflow (or anyone reviewing my code).


They are under the dropdowns on the right, on the "Related Changes" tab. 
New Gerrit actually shows the whole stack there, rather than only direct 
children and parent.


--
Bartosz Dziewoński

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Gerrit 2.12.2 test instance - PLEASE TEST

2016-07-12 Thread Bartosz Dziewoński
I have tested it and I love it. It is all I was hoping it would be and 
more. The inline commit editing is quite nice, the lists of related 
commits are useful, but the warnings about merge conflicts are the best 
thing ever. The sooner it's live, the better!


--
Bartosz Dziewoński

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Phabricator monthly statistics - 2016-05

2016-05-31 Thread Bartosz Dziewoński

On 2016-06-01 02:24, Alex Monk wrote:

Here are the numbers that I'd like to draw people's attentions to:
Tasks created in (2016-05): 2572
Tasks closed in (2016-05): 2275
That's a difference of 297 tasks...
Difference (2016-05): 297
Difference (2016-04): 243
Difference (2016-03): 454
Difference (2016-02): 238
Difference (2016-01): 418
These difference should really be negative, but right now it looks like
we're slowly accumulating more and more bugs...


We are, and we've always been. If you go through the same data from the 
time of Bugzilla, I don't think you'll find a single month where the 
count decreased. I don't remember any myself.


--
Bartosz Dziewoński

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Which Phabricator project for site issues?

2016-05-27 Thread Bartosz Dziewoński
You can also always file a bug without associating any project tags. 
Someone will usually quickly categorize your report :)


--
Bartosz Dziewoński

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Proposal to invest in Phabricator Calendar

2016-05-16 Thread Bartosz Dziewoński

On 2016-05-16 21:03, Joel Aufrecht wrote:

  - what is the difference is between Wikimedia Requests and Upstreamed?


Presumably Upstreamed just means that a task about it has been filed at 
https://secure.phabricator.com/ and there's a link to it on our task.


--
Bartosz Dziewoński

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Reviving SVG client-side rendering task

2016-05-13 Thread Bartosz Dziewoński

On 2016-05-13 22:28, Jon Robson wrote:

The ResourceLoaderImage module is being used widely to generate SVG
icons with png fallbacks. I'd be interested in seeing if we can use
this in some way for optimising SVGs and removing meta data.


I don't know what you have in mind, but please remember that 
ResourceLoaderImage was not written with security in mind. It has a very 
simplified version of our usual SVG rendering code, and it assumes that 
any SVG files passed to it is trusted. We traded some caution for some 
performance. Giving it user-controlled data is going to result in 
security vulnerabilities (at the very least some denial of service ones).


--
Bartosz Dziewoński

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Upload tools configuration changes on testwikis

2016-05-10 Thread Bartosz Dziewoński
Hi, I had two changes deployed today that change how UploadWizard and 
the upload dialog are configured on testwiki and test2wiki. I don't 
think this affects anybody but us at Multimedia, but just in case:


* test2wiki no longer has UploadWizard [1] enabled. The configuration
  has always been somewhat broken and hardly anyone used it. It's
  still enabled on testwiki. [2]

* test2wiki can now upload files cross-wiki to testwiki using the
  upload dialog [3]. Upload dialog uploads from testwiki now also
  go to testwiki (locally). Previously they both uploaded to Commons,
  like production wikis. [4]

You can think of these as testwiki acting more like Commons and 
test2wiki acting more like a Wikipedia site. Have fun testing!


[1] https://www.mediawiki.org/wiki/UploadWizard
[2] https://gerrit.wikimedia.org/r/287944
[3] https://www.mediawiki.org/wiki/Upload_dialog
[4] https://gerrit.wikimedia.org/r/285708

--
Bartosz Dziewoński

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] ResourceLoader addModuleStyles() issues

2016-05-08 Thread Bartosz Dziewoński

On 2016-05-04 12:34, Krinkle wrote:

## Proposed solution

...

Thoughts?


Yes. Please. Let's do that!

--
Bartosz Dziewoński

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Docs, use of, and admin privileges for wikimedia github project?

2016-04-25 Thread Bartosz Dziewoński

On 2016-04-25 19:01, Chad wrote:

Honestly, I'm not entirely convinced that "mirror everything" is all that
useful. It mostly results in a ton of unused repos cluttering up lists.


I, for one, appreciate it. GitHub's interface is unfortunately a lot 
more convenient than any of the repository viewers we host ourselves. :(
And fairly often I need to give somebody a link to a code snippet in one 
of our repos.


--
Bartosz Dziewoński

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Problems with building OOjs UI locally and exporting it to MW

2016-04-14 Thread Bartosz Dziewoński

On 2016-04-14 06:13, Matthew Flaschen wrote:

What's the best way to build OOjs UI locally into the MW lib directory
while developing?

I'm having two issues:

1. The README.md says:

"Install dev dependencies and build the distribution files:`$ npm
install`"

This does not actually build to dist for me.


Sorry, it seems we forgot to update this after 
https://gerrit.wikimedia.org/r/#/c/277814/ . The build doesn't happen by 
itself anymore.




I then tried:

npm run-script publish-build

That partly works but has many errors:

https://phabricator.wikimedia.org/P2903

However, it apparently creates the key files.


This definitely should work. `npm run-script publish-build` just runs 
`grunt publish-build`.


For development, you'll probably want to run `grunt build`, which does 
the same thing as `grunt publish-build` but doesn't generate minified 
files. It looks like the errors you're getting (no idea about them, 
sorry) are mostly related to the minification.


There's also `grunt quick-build`, which additionally doesn't generate 
PNG graphics, and doesn't take so incredibly long to run.




2. I see update-oojs-ui.sh, but it looks like it's only intended for
when the OOjs UI change is already published.

I had to hack it up with:

npm install '/home/matthew/Code/Wikimedia/oojs/oojs-ui/'

which seems to basically work.


Yes, update-oojs-ui.sh is for when we release a new OOjs UI version.

For development, I just copy-and-paste everything from the dist/ 
directory over the resources/lib/oojs-ui/ directory in MediaWiki.


(This doesn't update the JSON icon definition files, but that's usually 
not a problem unless you want to test icon changes, in which case you'll 
need to copy these by hand too…)




If there is not yet a proper way to do this, I'll probably add this as
an option.

This should be documented, probably at
https://www.mediawiki.org/wiki/Using_OOjs_UI_in_MediaWiki .


Yeah, the current state is pretty silly… I think we just got used to it 
and no longer question how horrible it is.



--
Bartosz Dziewoński

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Wikipedia in Pig Latin

2016-04-05 Thread Bartosz Dziewoński

On 2016-04-05 17:37, Jon Robson wrote:
> On Tue, Apr 5, 2016 at 5:00 PM, Daniel Kinzler <dan...@brightbyte.de> 
wrote:
>> Yes, please! I have been using a patch that Liangent wrote a few 
years ago, but
>> which never got merged, for exactly this purpose. Piglatin may just 
be a fun
>> easter egg for a production site, but it's a very useful tool for 
development

>> and testing.
>

+1. Where can I +2 this?


https://gerrit.wikimedia.org/r/#/c/72053/

I'm afraid it got stuck because enabling LanguageConverter for English 
caused a number of parser tests to immediately fail, even if no 
conversion was being done. :(


--
Bartosz Dziewoński

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

  1   2   3   4   >