In T234661#5570947, @Aklapper wrote:

In T234661#5553373, @Amire80 wrote:

As a pet project, I wrote a fairly detailed functional product-level plan for making modules and templates global

@Amire80: That sounds like material for T121470 where I cannot find this link?

As a pet project I wrote something like a requirements doc for this from a user perspective (less PHP classes, storage and caching; more user experience description).

Yes, but fifty bis quite a lot. For some people it will be easy to make fifty Wikidata edits, but not for everyone.

I didn't say that they don't have to care about Wikidata and only work autonomously on Wikipedia. Some of the people I talk about do care about Wikidata, but that's not the point.

I went bold and added https://www.mediawiki.org/wiki/User:Amire80/Global_templates_draft_spec/TLDR to pre-reading. It's a very personal and unofficial proposal, and it explicitly excludes gadgets (even though it's totally find to discuss gadgets, too; I just want to discuss them separately in order to focus better). However, a bunch of editors from several wikis told me they liked this plan and its (much) longer version, so perhaps it can be a useful starting point. If I'm wrong about anything, please revert me :)

I already commented about it in relevant tasks, but if I can volunteer to lead a session in Atlanta, should I be bold, edit the task description and add myself? Or will the organizers decide who's the leader?

Yes. Methods and technologies can always be improved, but in the meantime let's not block stuff.

Just a tiny contribution from me: T233192: Consider splitting rest- messages to a separate file

I'd be very, very happy to discuss it any time, both about desktop and mobile. How will it be done? Video meeting? Document? Something else?

In T234661#5556881, @WMDE-leszek wrote:

I've suggested splitting out some aspect of Gadget related stuff to: T234957. Please feel free to comment there, disagree with separating, etc!

I stopped counting the number of times I ran into problems of this kind as the product manager for Content Translation and Compact Language Links. I fixed them in Indonesian, Russian, English, Georgian, Portuguese, and lots of other wikis.

Modules and templates must be all global, at least optionally. It's not just a necessary change for the MediaWiki platform as it is used by Wikimedia; it's the most necessary change.

Although I am really not an expert in the internals of how these things work, I am very interested in the following closely-related tasks from the point of view of end users who want to write in new languages:

• T212881: addWiki.php broken creating ES tables
• T228745: Allow creating an independent "incubator wiki" instead of hosting all new wikis in one Incubator wiki with prefixes
• T158730: Automate WMF wiki creation

What's the problem? Looks valid to me.

In T234030#5534418, @Izno wrote:

In T234030#5534080, @DCDuring wrote:

The 'example rendering' above shows each reference taking up a line of screen space, though containing just a few characters. Can't we make better use of vertical screen space by lining up the page references horizontally?

Most wikis are using or have been using multi-column referencing, which limits the real estate more than otherwise. We also do not know what other information may end up in the refined references e.g. quotations or chapter information. This is why the syntax is intended to be "refines" or similar rather than parameters like "page" (as a separate proposal had it).

TLDR: This is a good thing, but this feature real worth will be in deploying it everywhere and actually using it as similarly as possible across all wikis.

In T233974#5527611, @Ladsgroup wrote:

In T233974#5527541, @Amire80 wrote:

In T233974#5527507, @Ladsgroup wrote:

N'Ko is added to restbase and not yet parsoid: T233833: Add nqowiki to restbase Fixing it should be easy.

Is this the Parsoid section in https://wikitech.wikimedia.org/wiki/Add_a_wiki#Parsoid ?
Is this a manual step at the moment? Can it be done before the wiki is created?
cxserver, for example, is OK to do a bit later (although the earlier it is, the better). AFAIK it was already done for N'Ko. But VisualEditor should be working from the very start. New editors in new Wikipedias tend to use it more.

I understand but Parsoid is being merged to mediawiki and in a couple of months (fingers crossed), you will get the parsoid support for free.

In T233974#5527507, @Ladsgroup wrote:

N'Ko is added to restbase and not yet parsoid: T233833: Add nqowiki to restbase Fixing it should be easy.

I also never liked the "Media" label very much!

Not totally done. Some day.

It's the hoc incubator, I know where to find it.

The domain appears to be created, but I see this on the main page:

In T222867#5497011, @Volker_E wrote:

I'm not sure what outcome is really better in a mixed language interface. If I were in an English first interface, I'd still not assume to have Hebrew necessarily aligned with English just to make it look better.

In T230559#5496981, @Amire80 wrote:

I've just tested in production in the Georgian Wikipedia, and it appears to be fixed, but I asked person who knows the language and told me about the bug at Wikimania to test more thoroughly.

I've just tested in production in the Georgian Wikipedia, and it appears to be fixed, but I asked person who knows the language and told me about the bug at Wikimania to test more thoroughly.

I'm having a bit of a deja vu here because I think it was discussed already on some other task. But I don't mind repeating ;)

Another example:

In T229324#5423709, @Pginer-WMF wrote:

@Amire80 can you indicate which is the criteria you finally used for the selection in terms of X number of translations in Y number of months?
Thanks!

There is a complaint about it also in the Hebrew Wikipedia, which is my home wiki, but I still cannot reproduce it. I am testing in Chrome 76 on a Mac. I also tried on Windows, with the RC filters enabled and disabled, with admin account and non-admin account, and nothing helped—I just cannot reproduce it anywhere.

Thanks for the report.

Another page where this will be very useful is MostTranscludedPages. The templates that are used on articles, user pages, talk pages, and category pages are quite different, and it would be useful to know what are the most used templates in each namespace.

So! We hit a milestone here \ס/ All the Extensions used by Wikimedia are converted.

I have no objection in principle. Perhaps it could be better done in Wikidata with properties, but if people who work with Japanese think that it's better with language codes, it's fine with me.

In language-data we usually use the 2- or 3-letter code alone for the script that is more common and default, and a code with a tag for other scripts. For example, we have this for Manipuri, where the Meitei script is the default:

mni: [Mtei, [AS], ꯃꯤꯇꯩ ꯂꯣꯟ]
mni-beng: [Beng, [AS], মেইতেই লোন্]

OK, can you please make a screenshot while logged-out? I want to rule out every possible difference that your account may have.

Have you tried it while logged out, or only in other wikis?

I cannot reproduce it in Chrome.

Can you please post a screenshot of this? I more or less imagine what can cause problems of this kind, but I don't actually see an example on Recent Changes in fawiki.

Thanks for creating the task.

It may be an issue caused by a browser extension or a toolbar or something like this. Can you try it Ina different browser or on a different computer, please?

This is quite... unusual.

In T230020#5416655, @CDanis wrote:

In T230020#5416604, @Amire80 wrote:

In T230020#5415067, @CDanis wrote:

@abi_ Can you clarify if you need access to private (user webrequest logs) data?

Statistics about interlanguage links clicks and popular articles by country. The Language team needs this for being informed about the development of UniversalLanguageSelector and other products.

Is that a yes, then? :)
Sorry, I have no objection to granting such access; I'm simply trying to determine which groups are the appropriate ones.

In T230020#5415067, @CDanis wrote:

@abi_ Can you clarify if you need access to private (user webrequest logs) data?

Well... people want to write encyclopedic articles without having to use prefixes in titles, and to use Content Translation and Wikidata :)

Reported a related issue in VE: T230559.

In T208139#5416194, @Amire80 wrote:

The actual reason why it's broken is much simpler: the value of capitalizePageNames is true.
Fixing it also required changing something in the master HotCat code.