I think I have to go crazy right now. By saying that wikitext is not allowed to be part of any API any more you are banning APIs like export and action=edit that either return or expect wikitext. It even bans the action=parse API whose entire purpose is to accept wikitext. Neither of these APIs does make any sense any more when we require clients to not have any knowledge about wikitext any more.

I just run into the same problem with https://de.wikipedia.org (= https://w.wiki/49) vs. https://de.wikipedia.org/ (= https://w.wiki/Ga).

you would be able to fix this issue if you were given it as a task by your line manager?

The purpose of the API is to provide or convey a specific piece of information, not a format.

Thanks a lot for bringing this up! This is certainly a very relevant issue with the idea I presented above. Applying the padding only on one character is a neat idea. The one issue with this approach is that it causes a reflow every time the padding appears and disappears. But this might be acceptable.

The bump to 1.27 was fine, thanks a lot for that! But to mark this task here as resolved we would need to bump to 1.31 (assuming my analysis in the task description was correct), and actually start using PHP 7.0 features in the listed codebases.

I believe we run into a very similar issue in the tour we have in the Two-Column-Edit-Conflict-Merge extension, see T195713: Have an intro tour (No. 2) as well as the patch https://gerrit.wikimedia.org/r/456176. The issue was that all the positions have been calculated to early, directly after the page finished loading. The moment the positions became relevant (i.e. the user clicked a button and the next popup was shown), all the other elements on the page could have been moved, i.e. when the user resized the browser window in the meantime, or a lazy-loading gadget made parts of the page reflow. I guess something similar might happen here. I know some quite relevant parts of the Wikibase UI (term box, collapsing references and qualifiers) only show up after the basic page loaded.

• It was the author of this task who closed it.
• The task description was not very specific and actionable to begin with.
• This is something the Wikisource community can better manage on-wiki. I don't think they need this ticket to be able to do what the task asks for.

What situations are those? If something is expected to return wikitext, the API should have an option to parse it and return HTML. That's not hard to achieve.

I, personally, would push for #3. Ideally not just with a bug report, but an actual pull request. In the meantime we can apply #2 as a temporary workaround. @Legoktm, is it possibly to use our almighty Libraryupgrader to update all Doxyfile?

Issues I see in the current text:

• The introduction makes it sound like it would be possible to always comply to all principles the same time, just by trying hard enough. In reality such principles often conflict with each other. Our job is more to find a good balance. I wish the introduction would accept and mention this. I certainly don't want anybody to pick a single principle from the list, run around and make everybodies life hard who needs to balance all of them, and isn't able to fully comply to one because of this.
• "MUST be designed to avoid any need for clients to process wikitext." I find combining a "MUST" with an "avoid" confusing and dangerous. I feel this needs to be a "SHOULD". There are certainly situations where it is not possible to "avoid" wikitext entirely. What happens then? Does the "MUST" still allow users to enforce this rule and block patches?

Asking users to provide "legitimate reasons" to be allowed to use one of the (literally) most basic characters is, … how to put this? It scares me. It's like asking users to provide "legitimate reasons" to use Wikidata with a screenreader software, or asking users to first provide "legitimate reasons" why they want to become a community member before they are allowed to do their first edit.

Sorry for writing so much, but I feel there is an important lesson to learn here, despite this appearing like it would be a minor thing. I feel this highlights a quite fundamental misunderstanding.

Item pages should split alias entries containing | character to be consistent with Special:SetAliases

I'm afraid I have to agree with @Addshore here. Sure, it might be that many of the aliases that currently contain pipe characters are mistakes. It might even be the vast majority. But even if this is the case, …

• There are certainly items that actually have a title or alternative titles that require the use of one or more pipe characters. Why should we ban them from the Wikidata knowledge base? Just because of a bug? Why not fix it instead? I drafted a few alternatives above.
• Disallowing a random low-ASCII (!) character just feels wrong. Again, why? Why not, let's say, disallow comma, semicolon, and more non-alphanumeric characters as well? They all might be from a broken import.
• Wikibase disallows tabs and vertical whitespace (newlines and such) for good reasons. But we never blocked the use of a visible character, as far as I'm aware of.

This thread makes me cry. We are not opening a domain registry or something like this here. We are not going to install a bidding or voting process for the most wanted IDs. These IDs are effectively random. You get the next ID that is free the moment you use the service. And then it's gone. There is no going back. There is no reassigning, no veto, no discussion. That's not the purpose of a URL shortener. If you need a meaningful, self-explaining URL, than for heavens sake use the original URL.

I'm sorry for my rude comment at https://gerrit.wikimedia.org/r/502530. I made that in a hurry.

I was just looking for the page and found it exists: https://it.wikipedia.org/wiki/Discussioni_utente:Barstein

Done.

We are investigating this. But since this is about code none of us here at WMDE wrote, we would love if your team could pick this task up.

Dear PM. My advice here would be to ditch these %…% tags. We should remove them from all config pages as well as help pages to not confuse people. Both the original uploader of a file as well as the user doing the transfer are well tracked when using FileImporter, and clearly visible in the page history, upload and import logs, user contributions, and such. This is an essential feature of the extension, in contrast to CommonsHelper where all uploads are done by the same bot account.

Dear PM. My advice her would be to close this ticket as resolved. The result of the investigation is that we don't need the "Information" section. We should remove it from all config pages to not confuse people.

Isn't this a duplicate of T219153: Change Popups descriptive title to also fit reference previews?

My suggestion is to simply add this to the ForbiddenFunctions sniff. I suggest to not invest time on an auto-fix. Code that calls isset( …, … ) with multiple arguments is so rare, it's probably more effective to just manually fix these few places than to write, review, and maintain an auto-fix.

I did another update:

• Removed all configuration settings that don't exist any more.
• It said the popup would show when a page was edited. This is not true any more. I removed it.
• I moved the description of our Reference Previews configuration down into the configuration section.

As far as I understand this ticket here, it is

1. exclusively about Gerrit links.
2. exclusively about links that are used to clone a repository.

What are the exact steps to see that breakage? […]

May I ask why all the patches uploaded so far actually break URLs that worked before?

Call me oldskool, but I find string|null much more readable. The question mark not only looks like a misplaced character, it can also be very confusing to see all these special characters in the same line:

• @foo
• ?foo
• &$foo

It's like we are trying to come up with a new markup language here where all special characters have a different meaning, and everybody needs to memorize all this noise to be able to read it. Can we avoid this? Less is more. We will always use the | character in documentation, e.g. for stuff like string[]|string. Why not continue to use it?

@Lea_WMDE, with the two patches linked above all messages are now consistently talking about "references" again, not "footnotes".

I agree with the acceptance criteria. But I, personally, would not try to squeeze every code path through the existing createModel() helper method. I suspect this helper method is what is meant when this task talks about a "constructor"?

Oh dear. I would like to point out that it was not really the type hint I added who is creating an issue here. What the type hint did was making an existing issue visible. The actual issue is this code:

$title = Title::newFromText( $request->getVal( 'colltitle', '' ) );
if ( !$title ) {
    return;
}
$collection = $this->loadCollection( $title );
// …
$this->postZip( $collection, $partner );

Along with this code:

private function loadCollection( $title, $append = false ) {
    if ( !$title->exists() ) {
        // …
        return false;
    }

What this means:

• When the user provides a string that is not a valid title, it is silently ignored.
• When the user provides a valid page name that doesn't exist, postZip() is called with $collection set to false, which triggered an inherently broken API request before.

This misbehavior is now blocked by the type hint.

Gerrit is not "down" any more, reopening this was a mistake. Sorry.

I'm in contact with the security team. Long story short: It's not me.

I can't login to Gerrit any more. I created T218507, not knowing what was going on. Given this ticket doesn't explain much, I still don't know.