Hey,
I consider myself an image file format nerd, so thanks a lot for
sharing this! FLIF was new to me.
I would like to share two important notes:
1. Unfortunately the flif.info website does not say a word about the
CPU resources their current implementation burns when converting a,
let's say,
> Point was more: Get rid of this bloody Download a JPG, do some Stuff &
Upload a 3 Times locally saved JPG again […]
I'm afraid I did not made my point clear enough. With all respect to your
enthusiasm, but the scenario you describe is exactly what your suggestion
will not improve. How could it?
> Is there any historical evidence that sysops being able to edit JS / CSS
> caused some serious issues?
Oh yes, this happens more often than I feel it needs to. I remember a
situation when I posted a fix for a script in the MediaWiki:…
namespace as an {{edit request}}, and a well-meaning
> Final code cleanup step after major icon refinement […]
Congratulations on that! I especially love how the identifiers for
many icons describe more how they look, and less what their intended
purpose is. E.g. "die" and "funnel" being called like this, and not
"random" and "filter".
However,
Hey!
The syntax "[[Schnee]]reichtum" is quite common in the
German community. There are not many other ways to achieve the same:
or can be used instead.[1] The later is often the
better alternative, but an auto-replacement is not possible. For
example, "[[Bund]]estag" must become
Paladox wrote:
> i am collecting feedback for Gerrit's New UI […]
You might want to check out the CSS tweaks I developed for the old
Gerrit UI. This stylesheet removes a lot of clutter, makes Gerrit
usable on smaller laptop screens, and increases critical click
regions. If the new Gerrit UI
Hey,
I'm sorry to hear about such an issue. I can only assume it means
massive trouble for your team, Greg.
Unfortunately for me being one of the receivers of this message I must
say it does not make the slightest sense.
What happened? Is there a Phabricator ticket I can read up?
What is the
So it turns out this addition is indeed the reason I get constantly
spammed with the same fake review request over and over again, no
matter how often I try to remove myself from a patch.
https://gerrit.wikimedia.org/r/484681
Not only that. The notification mails make it look like Matthias
> Gerrit no longer automatically adds reviewers […]
Thank you very much for reacting so fast.
> https://gerrit.wikimedia.org/r/485184
I'm not sure if the list of issues in this commit message is meant to
be complete. But I noticed it misses the bug I found the most
annoying: The plugin doesn't
Can I please ask again to *ban* this bad plugin entirely from our
systems? Having it sit there for anybody to enable again is a ticking
time bomb. It will start sending out the same misattributed,
uncontrollable, aggressive fake request spam again. I don't want
anybody to experience something like
> […] i have a working prototype working ("Suggest Reviewer") button.
Ok, but that's another extension then. Can we kill the bad one, please?
Best
Thiemo
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
> […] im adding that functionality to reviewers-by-blame.
I'm afraid I don't understand. Does this mean all the issues that make
the plugin send passive-aggressive, misattributed spam will still be
in place, possibly hitting peoples inboxes again any time somebody
decides it would be a good idea
> Is the UserMerge extension actually used on Wikimedia sites?
I don't know if people *use* it, but according to
https://wikiapiary.com/wiki/Extension:UserMerge it is installed on
more than a thousand wikis, including all Wikimedia wikis.
Best
Thiemo
> Fundamentally broken sounds like a bit of a stretch.
A process that annoys people based on nothing but the fact that they
happened to be the last one touching a file *is* fundamentally broken.
This is not how anyone should look for reviewers, neither manually nor
automatically.
Here is a
> […] "people who have worked on this code before" is an excellent metric by
> which to find people to review your code.
Sure. But this is neither what I wrote, nor what the plugin does, nor
what can be done programmatically in the first place, as you
conveniently pointed out yourself:
> […] we
You can link all your accounts via your user settings on Phabricator.
Except for a little confusion here and there I'm not aware of any
consequences of having different names on Wikitech (which includes
Gerrit) and Phabricator. I happen to have slightly different account
names myself.
Best
> […] automatically add reviewers to your changes based on who previously has
> committed changes to the file.
I'm already overwhelmed with review requests. I'm also one of the
latest contributors in sooo many files that I'm worried the plugin
will add me to dozens per day from now on. This
> […] why the tag parameter follow= is not turned off in wiki sites that
> are not wikisource?
As the Technical Wishes team at Wikimedia Germany is currently working
on the Cite extension, I had a look to find an answer to your
question.
The follow="…" feature was introduced in 2010[1] as part
The wikitext snippet you posted appears to be seriously broken. More
precisely: It is unbalanced. Technically, there is no such thing as
"broken" wikitext. The parser will always output something (as he does
in the example). However, this doesn't mean such wikitext is ok. Sure,
nobody is stopping
> I expect from the parser to parse wiki markup before parsing html tags […]
As I said. As neither the wiki markup nor the XML tags in the given
example are valid, one can't expect anything. Seriously. Code like
{{cite|}} is just broken. It's like having two nested Klein
bottles. Both structural
Oh my. These might be the most sensible password policies I have seen
implemented since, I think, ever:
1. Must have a certain length.
2. Can not be one of the most used passwords.
3. Ah, and don't be so silly to repeat your user name.
4. That's all.
No made up rules like "must contain at least
Is there a question assigned with this long email? Is this a call for feedback?
Kind regards
Thiemo
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Sorry it took me so long to respond here.
In https://gerrit.wikimedia.org/r/486813 Gergő wrote:
> […] it adds some fairly complicated code for detecting a pattern that's
> mostly harmless and can be dealt with during normal code review, so the value
> is less than the maintenance cost.
"How it should be done" according to whom? This might be a dumb
question, but I had the impression you are speaking for a larger group
of people in your initial post. I would like to understand the context
better in which the proposed standard came to be.
Personally, I don't support the idea of
I meant half a decade. Thanks for assuming good faith.
> You use naming schemes to avoid name clashes […]
This is by far not the only reason to have a naming scheme. Probably
the least interesting one.
I don't think it makes sense for me to continue contributing to this
conversation, since the
> […] I think mw.ext.EXTNAME should be avoided […]
Can I ask to provide arguments that help others understand this
opinion better? What is the problem with the ".ext" part?
> […] or we should reject this proposal and open phab ticket to wikibase to
> change mw.wikibase to mw.ext.wikibase
> > I'm trying to think of a way to put this politely, but I can't, so: this is
> > insane.
>
> Please try to remain civil and polite, even when things aren't as you want.
It always strikes me hard when people who fear for their mental sanity
are not allowed to call a situation like that. I'm
Jeroen, can you please provide more context? What exactly are you
trying to store? Why? How often? When will it be changed? By whom?
As of now the rather vague explanation provided make it sound like
it's a configuration flag, and should go into LocalSettings.php as a
$wgYourExtensionYourConfig =
Again. What exactly are you trying to store? How often is it suspected
to change? Who will be allowed to change it? Why not make it
configuration via LocalSettings.php? What is the problem with an extra
table?
___
Wikitech-l mailing list
The English Wikipedia edited the message
https://en.wikipedia.org/wiki/MediaWiki:Cite_references_link_many_format.
By default, this message is:
[[#$1|$2]]
You can edit your wiki's
[[MediaWiki:Cite_references_link_many_format]] (create it if it
doesn't exist) and change the $2 to $3. This
I tracked it down a bit, using the URLs
https://www.semantic-mediawiki.org/wiki/Help:Leaflet_format vs.
https://www.semantic-mediawiki.org/wiki/Help:Leaflet_format?debug=1
These weird "shadow" pointers are indeed shadows. The bug happens on
the "leaflet-shadow-pane" layer. The individual
To be honest I don't fully understand the question. What you wrote
sounds like we have something like this already. Or did I get this
wrong?
On a very high "user experience" level unrelated to MediaWiki I do
have a suggestion: You could do it similar to how "like" features in
social media clients
I'm afraid I have to agree with what AntiCompositeNumber wrote. When
you set up infrastructure to fight abuse – no matter if that
infrastructure is a technical barrier like a captcha, a tool that
"blames" people for being sock puppets, or a law – it will affect
*all* users, not only the abusers.
Two thinks:
1. When following the instructions from
https://www.mediawiki.org/wiki/Gerrit/git-review, I got stuck with
git-review 1.26 being reported as the "latest version". Which isn't
true. I had to use `sudo pip install git-review` to get the current
version 1.28.
2. I would love to apply
I don't think we have the same idea of what the word "unspecific"
means. From my perspective – as a German native speaker who only knows
the abbreviation "SWAT" from bad TV series, and didn't even know what
it means until I looked it up recently – we could have it named
"lemon" as well, and that
> […] I myself have never understood why one would want a browser extension to
> display an Edit button outside the viewport. It seems unappealing from a UX
> perspective and for me personally would likely fade into "banner blindness"
> and notice if it were detected and/or notice it too much
I'm curious. What API is this about? Do you have a project page with
more information?
Kind regards
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
Hm.
* Can we get this the other way around, being able to mark classes
with #[DisallowDynamicProperties]?
* I would expect this to be the standard behavior on "final" classes.
Unfortunately the RFC doesn't mention the word "final" anywhere. What
do you think?
Best
Thiemo
While I very much support the idea of closing old tickets (as well as
Gerrit patches) that don't look like they will ever be tackled – this
tends to be a delicate decision that benefits a lot from being as open
as possible. There is not much to add to what AntiCompositeNumber
already wrote.
1.
Hey!
I actively contributed to
https://www.mediawiki.org/wiki/Best_practices_for_extensions in the
past. I reviewed the most recent changes for my WMDE TechWish team and
can say that I'm pretty happy with how the page turned out. Some minor
suggestions, though:
* MUST: extension.json must name
It does indeed look like we don't have good documentation for the
details you're interested in. Let's see.
> post-parser size […]
As far as I know something like this doesn't exist as a technical
limitation in MediaWiki. A page's final HTML can be much bigger than 2
MiB.
> Post‐expand include
I'm curious. How was this evaluation process originally meant to work?
Which group did it, how often, and based on which criteria? I probably
missed it, but couldn't find this information on the page.
>From all I see at the moment I would say: Go for it and merge the pages.
Best
Thiemo
5000 is a very common limit that's all over MediaWiki (APIs and such)
simply to not crash our servers. Which page is it? Usually pages with
any notable history are turned into redirects and not deleted.
Kind regards
Thiemo
___
Wikitech-l mailing list --
Hello Dušan,
I find this really fascinating. Unfortunately, it looks like the
article doesn't explain the proposed format. Where is the domain in
the new format? What does "DAY_HOUR" mean? What's the difference
between "DAY_HOUR2", "DAY2_HOUR", and "DAY2_HOUR2"? What is the file
naming scheme for
Hello Dušan,
It appears like the article is incomplete. What is the idea you want to propose?
Kind regards
Thiemo
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
100% agree. Comments that do nothing but repeat what the code already
says serve no purpose¹. I regularly remove these but can't when it
means PHPCS starts complaining.
Typical example:
/**
* @param User $user
* @param array $rights
* @return bool
*/
public function isAllowed( User $user,
I absolutely love it when clever engineering makes a piece of tech
spin a 1000 times faster. No, seriously. Congrats!
Almost as good as Matt Parker getting his code improved by
40,832,277,770% by a viewer. ️
https://www.youtube.com/watch?v=c33AZBnRHks
I think the upgrade broke something.
* Gerrit loads very slow. Not on all actions, but on some of them.
* Half of the patches appear empty, as if there are no changes. I
suspect this is some timeout. The list of files never loads.
* Whenever I try to add or edit a comment it fails with an error
The page contains __NOTOC__. That's why the "sections" property is empty.
Best
Thiemo
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
> Can we agree on setting up some standards […]?
I wonder why? What problem are we trying to solve? I mean, it's not
like I can edit the priority of a Phabricator ticket and expect some
other team to act accordingly. This is not how cross-team
collaboration works, neither with nor without an
What are the benefits you are hoping for?
I understand that pages in the proposed namespace will not show up in
search results any more, unless I specifically search in this
namespace. While this can be beneficial, it can also have negative
effects. If old pages are excluded users will often get
https://commons.wikimedia.org/wiki/Help:Translation_tutorial#SVG_files
as well as
https://commons.wikimedia.org/wiki/Commons:Translation_possible/Learn_more
contain a ton of information. Does this help?
___
Wikitech-l mailing list --
I'm in no way an expert in this area. But from what I have seen the
past years I think I can identify two repeating patterns:
1. Minor programming mistakes in unrelated code. This happens often
when we add more strict types to existing code, or make it throw
exceptions when it's called in a way
Yea, that's really confusing. For consumers that read the page as
JavaScript the is in a comment, true. But the wikitext parser
doesn't know what JavaScript comments are. It ignores the // at the
start of the line. You can test this when you copy-paste the source
code from the .js page into a
As said there is no bug. The pages need to be updated.
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
Both pages start with , which is a deprecated alias for
. Replacing it with e.g. will remove the
pages from the category.
Wait, you ask. We are talking about .js pages, don't we? There is not
wikitext. Still, for historical reasons, even .js pages are parsed by
the wikitext parser to populate
While I'm not opposing the idea, I have questions I didn't find
covered in https://www.mediawiki.org/wiki/Topic:Xgg6dvg2athdb1h7.
TL;DR: I think my concerns can all be resolved with careful rewording.
Please bear with me and analyze this idea: Does the proposed amendment
imply that I'm violating
I'm curious what the actual question is. The basic concepts are
studied for about 60 years, and are in use for about 20 to 30 years.
One particular detail the industry apparently needs to re-learn every
time is how easily such vector spaces encode and reproduce any
existing bias, racism, phobia,
I'm curious if your plans are for a Wikimedia wiki, Felipe?
Since people are pointing out learnings from similar experiments, I
would like to add another one:
https://www.mediawiki.org/wiki/Article_feedback/Version_5. There are a
lot of subpages with a lot of information.
ArticleFeedback version
Love it! It's almost a 100% literal translation of the existing
.alias.php format, which makes it very easy to learn, even using old
documentation.
The only difference is that the language is not in the array structure
any more, but in the "en.json" filename, which makes it behave the
same as
60 matches
Mail list logo
