Sounds quite close to "Unbreak Now" to me.

Oh sorry, forgot it. I'll try to fix it ASAP.

In T432098#12118596, @Nikerabbit wrote:

My take is that this less important that adding the translators, because git already keeps changelogs on who changed what, but for translation updates they show up as L10n-bot. Would welcome thoughts from a wider group whether this would be useful.

This fix adds this message: "Wikitext format pre extension tag expanding templates"

I can easily reproduce it on my device, Galaxy S23:

In T429657#12036443, @stjn wrote:

In T429657#12035957, @DLynch wrote:

Moving articles between namespaces is the same system, and it feels wrong to say "rename your article out of the Drafts namespace".

I think on a conceptual level English Wikipedia could, of course, continue to call it ‘moving’ if they want to, either in all circumstances or in some specific circumstances, but it is undoubtedly a problem for common localisation, since other languages already do not use their equivalent of ‘move’ for this sense, and it leads to situations like https://translatewiki.net/?diff=14077787 where someone is translating ‘move’ literally while entire interface translates it to ‘rename’.

It's not just about Ukrainian-language Wikimedia projects. Other MediaWiki sites in Ukrainian need backwards compatibility, too.

In T228745#11924092, @Bugreporter wrote:

And again, it's OK if it's just languagecode.wikipedia.org right from the start as long as patroling for vandalism works reasonably well.

One of points against "skip the creation of incubator wikis and instead just start them immediately" is such domain may easily be treated as official projects, so if someone that does not fluently speak such language created a such project (or if there are no validation that content is in correct language), such content will pollute LLMs.

In T228745#11915933, @Bugreporter wrote:

Note T397367: Drop unneeded empty tables from wikis indicated Wikimedia is not scalable to have thousands of wikis in production (one cluster can host only several hundred databases). We need a different solution (such as "virtual wikis" - some way to have incubator looks as if they are multiple wikis with separate domains, but sharing one database and one common set of tables).

The current output is correct.

In T425778#11902818, @Bugreporter wrote:

The term in bracket is the label or alias your search term matched, so I think it is the intendes behavior.

Perhaps I should also mention that this has been broken in one way or another for quite a while. In January, I brought it up on Telegram and @DMartin-WMF said that it's tracked in T405461. Maybe it's the same issue, maybe not.

https://he.wiktionary.org/wiki/User:Amire80/sulamit in the Hebrew Wiktionary gives "שגיאת תוכן" ("Content error") with both calls, even though the code is the same. (As far as I know, the Hebrew Wiktionary is connected to Wikifunctions identically to the Croatian Wiktionary, but I might be wrong.)

I don't know about caches or user errors, and maybe I'm misunderstanding how it's supposed to work, but something definitely seems off:

I don't know if it's the same issue, but even though Walnuss works now, some other pages on the Croatian Wiktionary repeatedly show "Pogreška sadržaja" ("Content error"), even though the function appears to run correctly when I test it on wikifunctions.org.

In T421959#11803916, @DSmit-WMF wrote:

I did a bunch of changed and I tested it with the page you mentioned and there it now looks ok I think: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/WikiLambda/+/1269412
I do need to test with a bit more content perhaps.

Some screenshots from local:

In T421959#11801327, @DSmit-WMF wrote:

These are indeed a lot of spans that have a variety of classes which do things like : word-break: break-word and white-space: pre-wrap. where it breaks also depends on the width of the screen

I highly doubt there is a css fix that will fix this for all languages and screensizes and all use cases everywhere. We can also reconsider the entire span'ed approach but that is a bigger task.

I know, but documentation is a separate step. People need to know what keys to press. There's a separate box for it in the checklist, and it's mentioned in the "Adding and removing languages" manual.

No documentation was added for the keyboard.

It's not particularly important, but aw is not an ISO 639 two-letter language code, and highly unlikely to ever become an ISO 639 language code. The ISO 639 document said in 2000 that New codes will no longer be added to ISO 639-1.

It should be just an X button that closes it.

In T418428#11665265, @Soda wrote:

the lack of people complaining about how to turn it off in Help desk, social media, or Teahouse, I feel like, is a strong indicator of the contrary to your characterization here. I agree that the UI could be clearer, but that is hardly a reason enough to override community consensus based on a small-scale experiment in this context (lacking any pushback from readers)

In T418428#11663995, @Soda wrote:

Ideally, it shouldn't appear at all.

Please find consensus for this statement. Current consensus on English Wikipedia is contrary to what you claim and you have been told so. Thanks.

I did some informal user testing of my own and asked several people of different ages and genders who were not logged in to hide the baby globe. 100% of them clicked the "Hide" button, which doesn't hide the baby globe, but does hide the whole sidebar that includes the actual buttons to hide the baby globe. After that, it was hard to find how to reopen this bar. This is informal and perhaps not comprehensive enough, but it does show that hiding it is not as easy for everyone as it should be.

In T410807#11653751, @Michael wrote:

In T410807#11653041, @Amire80 wrote:

The qqq for the new message wikimedia-notificationemail_html_footer says that it's a WMF override of notificationemail_html_footer, but I cannot find such a message.

Ah, that's my bad for merging the WikimediaMessages change early. The actual message notificationemail_html_footer is part of https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1240339 where I still had a small review note. It should be merged real soon, I hope.

Now that I see that it's not on all pages, I guess it's not the most urgent thing.

The qqq for the new message wikimedia-notificationemail_html_footer says that it's a WMF override of notificationemail_html_footer, but I cannot find such a message.

OK, I found that I can disable the "birthday mode" by scrolling deep into the "Appearance" section of the sidebar, but this is not really a solution. I've been writing on Wikipedia for more than twenty years and programming MediaWiki for fifteen, and it took me ten minutes to find it. I suspect that it will take other people more time. This is unacceptable.

Is this stuck on anything? Language committee approval, or whatever? It should be enabled.

In T411834#11599660, @SD0001 wrote:

In T411834#11599489, @Amire80 wrote:

That's exactly what I'm saying: It's possible, but not practical.

This task is exploring how to "allow users to deploy Lua code which is stored in Git to multiple wikis", and I'm saying that it's already possible, but almost no one is actually doing it, and adding a new workflow that involves Git differently is not going to work.

This is a non-sequitur. Because people aren't currently using a non-solution doesn't imply that they will not use an actual solution once one exists.

Being technically possible doesn't mean it's possible. There is no chance that Scribunto repo would accept code for buliding infoboxes or location maps or currency converters, even though they're all fine candidates for global modules.

In T411834#11599208, @SD0001 wrote:

In T411834#11598784, @Amire80 wrote:

The task T209310 is an example of moving the code of an on-wiki Scribunto module to a Git repository. It shows that this is already possible. However, there are almost no other examples of this, so the fact that it's already possible to put Lua code in Git and call it from on-wiki modules didn't cause many module developers to actually use it and move a lot of modules to Git, even common and stable ones.

Is your point really that modules can be shared by putting them in Scribunto git repository? That's like saying we can have global gadgets today by putting gadget code inside the Gadgets extension, or that we can have a repository of fonts by putting them in ULS. None of that is practical since maintainers of Scribunto or Gadgets or ULS aren't responsible for individual modules or gadgets or fonts, respectively. Including Module:No_globals in Scribunto made sense because it's extremely generic.

In T411834#11598406, @MSantos wrote:

In T411834#11561465, @Amire80 wrote:

It has been proposed that we allow users to deploy Lua code which is stored in Git to multiple wikis.

Proposed by whom?

@Amire80 you can find more about the rationale behind in this post.

It has been proposed that we allow users to deploy Lua code which is stored in Git to multiple wikis.

In T41610#11556531, @Bugreporter wrote:

The development of global modules can still happen in a (and even any) local wiki (in addition to GitLab and LuaRocks), we just allow pushing them to a common repo so that they can be used in another wiki.

It can be linked to both.

In T414825#11529854, @Raymond wrote:

@Amire80 "I'd do it myself, but I've never tried doing it for this kind of data, so I may need assistance.": Add to LocalNamesHe.php a section with an array $timeUnits = [...] and add the fix there.

And I suspect that the keyboard is not quite right. What is H²? Is it a letter used in this language?

The keyboard wasn't properly installed.

In T86910#11397002, @Samoasambia wrote:

@Pppery I noted that there are two spaces between "[[:$1]]" and "by" in the new message.

In T86910#11396424, @Pppery wrote:

A "dummy revision" is https://www.mediawiki.org/wiki/Manual:Dummy_revision

The new message says: because {{GENDER:$2|he|she|they}} made only dummy revisions.

In T402297#11384630, @Amire80 wrote:

This adds the message diff-usergroups. Currently, its English text is "$1 user groups" and its qqq is "The text for displaying user groups on diff view."

$1 is not documented in qqq. As far as I can see in the code, it's a number of user groups.

Is this number always more than 1? If it can be 1 or 0, the English message text should probably be something like "$1 user {{PLURAL:$1|group|groups}}". Even if it is always more than one, it should use {{PLURAL}} because many languages use different forms for 2, 4, 6, etc.

In T407653#11391416, @Niharika wrote:

In T407653#11352487, @Niharika wrote:

My proposal is to simplify the message language to avoid the "last" terminology -

Account creation is temporarily restricted because visitors from this IP address have exceeded the number of account creations currently allowed. Please try again later.
Kindly note that there is a limit of one account creation allowed every 10 minutes with a maximum of 6 account creations permitted every 24 hours.

This informs them about the limits but doesn't tell them which of the two limits have been tripped. I think it's OK to do this assuming good faith editors will likely try again later and vandals will just move on.

@Amire80 thoughts on this proposal?

This adds the message diff-usergroups. Currently, its English text is "$1 user groups" and its qqq is "The text for displaying user groups on diff view."

In T407580#11341770, @Michael wrote:

Thank you! Useful to know about {{experimental}}! Are these templates documented somewhere? I glanced at https://www.mediawiki.org/wiki/Help:System_message#Message_documentation but did not find guidance about that, but maybe I missed it.

Thanks for asking for my opinion :)

I think that when a message is marked as ignored, translations are supposed to be deleted from the JSON files automatically, but @Raymond should confirm.

In T396889#11304182, @Tacsipacsi wrote:

English Wikipedia does this: https://en.wikipedia.org/wiki/MediaWiki_talk:Accesskey-pt-watchlist (Template:Interface explanation). I vaguely recall having seen this elsewhere as well, but I’m not sure where (if at all).

In T396889#11223823, @Tacsipacsi wrote:

Sorry for being a bit late for the party, but there is one problem with this change, which should be solved one way or the other: wikis often link to translatewiki.net for message documentation, and now these documentation pages are abandoned and won’t be updated anymore. Ideas:

• Obvious: revert the change. This isn’t necessarily the best idea, though.
• Create a new message group called “MediaWiki – ignored”, which behaves much like a regular message group, but all its messages are automatically ignored, still saving the maintenance burden.
• Display the message documentation in a different way. Note that message documentation often contains translatewiki.net-specific templates, so it needs to be parsed on translatewiki.net, no matter where and how it’s shown. (And preferably stored in a way that backlinks show up on translatewiki.net.)

Hi. Some people expressed objections to this idea. It's my fault—I should have written more details earlier. I've updated the task description now. I'll reply in detail here:

In T407507#11287961, @Bugreporter2 wrote:

In T407507#11283866, @Amire80 wrote:

The current spelling came from a community discussion here: https://ig.wikipedia.org/w/index.php?title=Wikipedia:Nz%E1%BB%8Dr_ogbako&oldid=171993#Namespace_names

If you read that discussion, you'll see that they wanted Ńkàtá, but something went wrong in the copying process and what should have been N-acute (U+0143) got replaced with N-dot (U+1E44).

It's probably not related to Growth, but to the Edit check feature of Visual editor. Adding those tags. Revert if I'm wrong.