I might be wrong, but I thought the idea was migrating existing functionality from jQuery UI and OOUI to Codex. If that's true, wouldn't be better adding this new functionality directly in Codex instead of making it with OOUI and having to update later to Codex?

I think that we are building the things upside down. While this is interesting, the most experiences users know which templates to choose, because they are experienced. The problem in T55590 is the opposite: how do new contributors know what are the most obvious or used templates?

As a contributor, when I don't have any favorite templates, I should see an empty state to add favorite templates

If I don't have any favorite template, instead of an empty state, why not suggesting some? This could be defined by hand with some kind of page (as Citoid works). This way, some Wikipedias could propose some ideas instead of having an empty state.

@Theklan - we've explored the newcomer use case as well on a few different paths.

• Showing the most used templates on a wiki: problem, lots of templates are "shadow templates" such as citation needed, which isn't relevant to a newcomer
• Creating an ML-suggested template list based on the user, their editing patterns, the page they're on, etc: this is something we want to continue exploring, but need support from the research team
• Allowing communities to offer suggested templates. This would require some interface for admins/editors to populate a list of suggested templates. There's a risk these templates would be irrelevant to newcomers (speaking to older editors), that the lists wouldn't be populated, or the suggested templates would be irrelevant to the content (such as a map coordinates template on a chemistry article)

TLDR - supporting newcomers in an empty state is still under consideration, though we prioritized favorite templates in part because of the demand in the previous wishlist, and we also see behavior from editors to view templates on Page A, see inspiration, and then leverage that template on Page B. We think favoriting could be leveraged as a discovery/bookmarking mechanism.

If you have other ideas on how we populate the empty state with something that could scale, we'd love to hear about it!

There's no perfect solution, nor one-size-fits-all solution here. That's right. We should have two very different approaches, in my opinion:

• For newbies: a ML-suggested template list may be a good idea, but it seems hard for languages other than English (and a handful of other languages) and it takes too long to implement. Imagine you are new and you somehow know that you should add a template. You click on Insert > Template and what you see is this:

What if instead of this, we could have like 6-8 very evident templated choosen by the community. I know that some Wikipedias, especially English Wikipedia have tons of templates for nearly every use, but other wikipedias have a very practical approach and the amount of templates that could be suggested are less. For Basque Wikipedia I would guess that a new user will make an article about a person, a place or an event. That would reduce everything to just 3/4 templates*. We could choose another 3-4 templates to suggest, and so the screen is not empty and you can choose from something that could be. If you are not writing about a person, event or place, then you can choose another one from the search bar, like you would need to do if the state is empty.

• For experienced editors. Just under the suggested templates you have a link to customize this page, so you can choose the most relevant for you. This would be exactly the plan you are proposing, but with a different approach for the empty state. If you don't customize it, you will have the same proposals there are for the newbies.

Look at: T55590#5191330

• About security: We have a citoid definitions for references, where we can choose what "templates" to fill. The same approach could be used here, a page restricted to admins or even those with js/css rights, where this definition can be made.

• The four templates in this example are: https://eu.wikipedia.org/wiki/Txantiloi:Biografia_infotaula_automatikoa, https://eu.wikipedia.org/wiki/Txantiloi:Geografia_fisiko_infotaula, https://eu.wikipedia.org/wiki/Txantiloi:Hiri_infotaula, https://eu.wikipedia.org/wiki/Txantiloi:Gertakari_infotaula.

I might be wrong, but I thought the idea was migrating existing functionality from jQuery UI and OOUI to Codex. If that's true, wouldn't be better adding this new functionality directly in Codex instead of making it with OOUI and having to update later to Codex?

That's true in general, but both VisualEditor and TemplateWizard are still using OOUI and have not started migrating from it yet, so as this is a feature being added to those we've decided to keep the scope smaller and stick with OOUI. It will one day have to be moved (but personally I'm hoping we do that after we finish migrating WikiEditor off jQuery UI! :-P).

What if instead of this, we could have like 6-8 very evident templated choosen by the community.

I think other ways of finding templates is going to be great, and can come after we've done the favouriting part. We're going to make sure we build it with future expansion in mind, e.g. provision of a new tab-bar under the search box that can be used to navigate to favourites and possibly in the future things like suggested, recently-used, or statistically likely templates. We chose the favouriting to do first because it's easier than those.