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.

Oh, oops, should have been more careful. I'll revert to quotation marks.

• If available, URL to get the prior revision segment
• If available, URL to get the following revision segment

In T407507#11287868, @KingChristLike wrote:

In T407507#11284629, @Amire80 wrote:

In T407507#11283989, @KingChristLike wrote:

Hi @Amire80, I confirm that the new proposed spellings are correct.

Can you please link to a new discussion about it in an Igbo wiki? The discussion itself can (and should) be in Igbo.

Here’s a new discussion about it.

In T407246#11286012, @kostajh wrote:

The acct_creation_throttle_hit message has existed in core with the $2 parameter for a long time, so there are many translations that make use of this parameter already.

Can you please clarify more about parameter $2? What kind of values can it have?

In T407507#11283989, @KingChristLike wrote:

Hi @Amire80, I confirm that the new proposed spellings are correct.

Another link that may be useful: Here's the change from the older namespace names to the current ones: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1049639

In T407507#11283805, @Bugreporter2 wrote:

It would be helpful to have input from someone familiar with the process of renaming namespaces due to spelling mistakes.

1. Should the incorrect name be retained as a namespace alias for backwards-compatibility, or should it be scrubbed for simplicity?

I've already fixed "cope" in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/ContentTranslation/+/1196419, and it should appear in translatewiki some time soon.

As I wrote in https://github.com/wikimedia/jquery.i18n/pull/307 , French probably shouldn't be defined as fallback, unless there's a strong and specific reason for it.

I think it's mostly moot because the localization statistics of Galician are usually 100% or close to it, so fallback is rarely seen in practice :)

In T392749#11196158, @Winston_Sung wrote:

In T392749#11193458, @Amire80 wrote:

Can you please link to more community discussions about it, in any language?

Other than the English Wikipedia and this Phabricator task, is there an external source for the "Cou" autonym? For example, a dictionary or another website?

In T400578#11215972, @Agabi10 wrote:

I might be misunderstanding because I lack context, but if this is to make modules translatable wouldn't a slot on the Module page be better for that? Instead of having to add magic to the title to set the content model it would be tied to a specific slot of the current module page. It's more feasible avoiding conflicts with other things that way too.

I have some questions because this adds an unusually high number of new codes, and this is very often a recipe for mess.

In T404534#11190324, @Jdforrester-WMF wrote:

i18n clean-up is not a bug. :-)

In T404671#11190148, @Jdforrester-WMF wrote:

In T404671#11185458, @GrounderUK wrote:

To me, it looks more like the first “calls to” would be the preferable omission.

Yes — we changed the wording during development and clearly failed to remove the old bit!

What about “Pages with errors in function evaluations” and “Pages where system availability issues caused function evaluations to fail”?

For consistency, we're using Wikifunctions calls as much as possible, as most users won't know what a "function evaluation" is, but they might recognise "Wikifunctions" and go to the project chat for help/complaints.

This is not exactly what we call "lego". "Lego" is more like concatenating different parts of sentences under the assumption that the order of the words is the same in all languages. This is very bad and must never be done.

Can anyone please say more about the message codemirror-wikilint-unclosed? What can $1 be? Is it shown as characters or as words? If these are words, where do these words come from?

The text-transform: uppercase; rule on ::first-letter is not just unnecessary, but actively harmful, and not just in languages written in the Arabic script, but in all languages. Some languages may require a small letter according to their grammar, and forcing a capital letter would be wrong (such things sometimes happen in Irish and in some languages of South Africa and Taiwan, for example).

In T402697#11121285, @Bokareis wrote:

Does a new community discussion have to be put up for this task?

In T381577#11142147, @Bhsd wrote:

@Amire80 Thanks for your comments!

• $1 parameters are not documented. Please add explicit documentation for every $1 parameter in every new message.

What documentation do you mean here? qqq?

In T381577#11142973, @Bhsd wrote:

r1184397 cannot be automatically merged. Maybe I need to avoid XML-like tags?

Some comments about the translatable messages:

A comment about the "n quick" message (cx-sx-translation-suggestion-easy-sections): It appears to be shown in hard-coded parentheses. This is wrong for some languages, which use different parentheses characters. It's better to use the parentheses message from core, or to simply include the parentheses in the message itself.

About parsermigration-reportbug-feedback-title: how will it work in practice on Wikimedia sites? Will the reporting be on local wikis or on a central wiki?

In T401916#11087043, @DLynch wrote:

There's presumably languages where the most-natural translation would include switching the order of the reference and the message, thus the suggestion for $1, though it doesn't really work out to do that in this situation since it's a full block-level display of it.

In T401916#11086988, @Esanders wrote:

I think the issue is that the message looks like it is followed by another word, and in many languages that next word would affect the grammar of the translation.