Please state what the name of the namespace and its talk namespace should be in Malayalam.

In T362441#9711103, @Snaevar wrote:

The largest thing here would be having the current namespaces as aliases, especially in the Template and Module namespaces. This will create a massive mess otherwise, although it will only be for a while.

Hi @Stefan-Orvar-Sigmundsson, and thanks for this very thorough task!

To test, go to https://www.wikidata.org/wiki/Q42?useskin=timeless&uselang=he

I believe this (and T361137) is https://github.com/notofonts/noto-fonts/issues/736

In T359101#9700796, @Reedy wrote:

Timeless is showing:
[…]

In T362125#9700720, @Nikerabbit wrote:

As @jhsoby pointed out https://www.mediawiki.org/wiki/Extension:VisualEditor#Changing_active_namespaces says we should use namespace names instead of ids (why? everything else uses ids). Maybe we didn't test this change properly.

I found that information via this topic on mw:Extension talk:VisualEditor, which is the top Google hit for "wgVisualEditorAvailableNamespaces". The last comment by kghbln linked to a thread on the now-defunct discourse-mediawiki.wmflabs.org, and I just edited the link to point to an archived version. In there, kghbln points out something interesting: You can add namespaces to wgVisualEditorAvailableNamespaces using the ID (or constant), but to remove them you have to use the English canonical name.

I don't see this on my system. Looks like a font issue. Could you compare the fonts used for that page in Timeless vs. Vector in the console and remove some of them to see if a font is the culprit?

Aye, thanks!

This bug is very similar to T344596, where @thiemowmde has mentioned T346252. Possibly/probably related?

If we had this, it could help prevent bugs like T360066 and T361695. The former bug happened because an illegal title character made it into a message that forms a page name, and the latter happened because log titles need to be unique within a language. So if we could tag page name messages and log title messages as such, we could add validators that prevent bugs like that from happening again.

With the closing of T63007: Allow specifying when a gadget should load (action, namespace, content model), especially the patch rEGADe2cb01ddcd66: Add support for categories in definitions, I think the premise for this task is also fulfilled. This task has been about using a magic word to add gadgets only to certain pages, but you can achieve the same by adding the pages you want to a (probably hidden) category that is only added to the pages the gadget is needed on.

Thank you very much for fixing this! All looks good now. :-)

Lucas said in Telegram that he couldn't reproduce it either. Really weird.

The change in a9a9b1976f (and my follow-up in 9cb1af627a) is working as intended now (for reasons unknown to me, it can take a while between merging a validation exclusion change and it actually working), so I think this can be closed. You'll still have to manually go through each message in https://translatewiki.net/wiki/Special:Translate?filter=%21translated&action=page&language=he&group=ext-wikimediacreativecommonslicensetexts and hit "save" though, because the messages have changes (but Raymond's automatic text replacement should have already fixed updating the links).

Wouldn't parsing be better if it's possible? I can imagine some languages may have a convention of putting "foreign terms" like JavaScript in italics, for instance.

Patch for review:

At least on Wikidata, this has an extremely high impact on users' workflow, so setting to UBN!

@Esanders Thanks for the quick response and action! 🎉

@Esanders @DLynch Adding you since you seem to be involved in this new feature, so maybe you have an idea how to solve this too. :-)

Since the main task was declined, it doesn't make sense to keep this open.

Yes, it's much faster for me now. On Special:Translate, a box opens immediately when I click it (preloaded with the last 9 languages I've used), but I can't interact with that box until all languages have loaded, and that took ~5 seconds when I tried just now. So there's still a noticeable delay, but it's much better than it was when this bug was first opened.

This was probably fixed a long time ago; the task selector is now visible in all circumstances.

I can't reproduce this any more after Nikki's fix from last year was merged. Please reopen if I'm mistaken.

I can't reproduce this; it sounds and feels like the same bug as T200329, which had a fix merged last year, so I'm boldly closing this. Feel free to re-open if I'm mistaken.

@EBernhardson Is/will this extension be used on Wikimedia wikis?

Thanks for all the help! :-)

Thanks! :)

Interwiki links have been cleaned up from this wiki. Even for Wiktionaries, there will usually be some interwiki links that should be connected to Wikidata, on non-mainspace pages (categories, templates etc.).

Couldn't we make Alt+0 the shortcut for this? That way, it would be stable, and it wouldn't affect or be affected by the number of other suggestions.

Mhm. We could make it highlight the search result, at least in the key name and possibly the source message (though that might interfere with the terminology gadget), though the key is only visible for the selected message. Doing so for the target message would be more difficult, since it's just a plain textarea.

I see that all the scripts in MediaWiki core's maintenance directory use CamelCase: https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/refs/heads/master/maintenance/
Wouldn't it be better for Translate to stay consistent with that?

In T354607#9535356, @Mstyles wrote:

@jhsoby @Ladsgroup we still need the NDA signed in T353393 to move forward.

Wikimedia doesn't host random wikis. Look up how to host MediaWiki on your own server (documentation is on MediaWiki.org), or look into third-party hosting on a site like Miraheze or Fandom.

I uploaded a patch quite similar to this for T115894 on January 18, but for the <references /> tag only, see 991614. The approach I used there was to not add it as a class (because group names can basically be anything, so you'd have to escape it), but as a data attribute, which are much more lenient in what you can put in them. Would be nice to possibly merge the two patches and use the same approach (doesn't matter to me which one that is).