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.

The actual reason why it's broken is much simpler: the value of capitalizePageNames is true.

In T212881#5408117, @Ladsgroup wrote:

While in general I agree with this but I want to mention that even our SWAT deployments not automatic, not to mention complex things like train, etc. I would be more than happy to split and break down addWiki.php and automate parts of it but I don't think automating the whole process is going to be doable any time soon.

A couple of related and more overarching proposals are T158730: Automate WMF wiki creation and T228745: Allow creating an independent "incubator wiki" instead of hosting all new wikis in one Incubator wiki with prefixes. They are closely related and overlapping, but T158730 is described from the internal, technical side, whereas T228745 is more functional and user-level, so they should be kept distinct and inform each other (I hope it makes sense).

Perhaps @Catrope, @Krinkle, or @SPQRobin can give a better answer, but my guess is that it was done because of the assumption that the input fields must always follow the direction of the site's content language and not the direction of the user interface language. This usually makes sense on a site like Wikipedia or Wikisource, where most of the content is indeed in one language, but it's problematic on multilingual sites like Meta, Commons, Incubator, or Wikidata. Perhaps it can be improved.

The image and the solution look okay!

Tested with Timeless in English and Hebrew, looks good to me.

Thanks for asking!

I just received a notification comparable to the one that is proposed in this task on Quora, and it felt AWESOME:

In T139010#5394286, @Yejianfei wrote:

Since it has been procrastinated for so long, let me write some code by myself:

• https://github.com/wikimedia/mediawiki/pull/104
• https://github.com/wikimedia/language-data/pull/58

No longer happens.

Closing as outdated. As far as I can, the articles in question were published, and they are CX1 articles, so whatever was the problem, it was probably fixed with CX2.

This was most likely caused by using an old browser or by copying from another word processor. The migration to Visual Editor (CX2) is supposed to fix this. Please reopen if <font> tags appear like this again.

In T229324#5388306, @Elitre wrote:

Ciao @Amire80 , I could use the list for Javanese at least since I'm planning to post there on Monday. TY!

A full list of languages can be seen by clicking the "More" button at the bottom of the list. (Google Translate, which was given as an example in the task description, also shows its whole list only after clicking a button.)

They are definitely valuable, but we can probably move to some other repositories. Let me clean that up.

In T228745#5358477, @Jdforrester-WMF wrote:

Hmm. This is essentially "skip the creation of incubator wikis and instead just start them immediately", with some policy changes about what would be considered "a wiki".

To make the discussion more focused, I split the biggest chunk of this task to a separate task: T228745: Allow creating an independent "incubator wiki" instead of hosting all new wikis in one Incubator wiki with prefixes

In T223664#5192104, @Yupik wrote:

This is not the same as T165585 (Make creating a new Language project easier) or T158730 (Automate WMF wiki creation), because the process should not require a Wikipedia project to be created or the UI of any project to be translated

Whatever works. Translation is a major scenario for worklist / tasklist / campaign / whatever-you-call-it, but certainly not the only one.

Too old. I'll reopen if something like this happens again.

OK, it looks like ais should be moved to szy, and there is no doubt now, according to https://iso639-3.sil.org/code/ais

While we're waiting for a proper solution with Dashiki, I made a simple, public-readable spreadsheet that presents all of this:
https://docs.google.com/spreadsheets/d/1hLQyLq3oQ11BLhU3_EJsb3hNgeUG6TutJcXjZ2g22bk/edit#gid=1343851748

Reported: T228010

Broken with Firefox, too.

In T226981#5318604, @WDoranWMF wrote:

@Amire80 Is the tag for CPT correct for us? Untagging CPT and tagging language team so it doesn't get lost. Let us know if that's incorrect.

I agree that this is problematic. Especially the part of auto-selecting the whole text link. It seems more sensible to me to put the cursor there and let the user change it. Currently, just writing something deletes the whole text.

This was done. Thank you!

There's a bit of an issue with including "User" in the human-readable text. In English it reads well. But what do I do in Russian? There are several issues:

• It will be translated as "Пожалуйста, выберите настройки уведомлений от User:$1." or "... от Участник:$1." In the first case there's an English word in a Russian sentence, which is not great. In the second case, it is grammatically awkward because the word Участник (User) in Russian is supposed to be declined be grammatical case. Участник:Vandal looks OK as a title of a user page, but it was not made to appear in a sentence.
• What will happen if the user interface language is different from the wiki language? This happens quite often, for example on sites like Meta or translatewiki. It it's a link, it will be broken.
• There is also the consideration of gender. In some languages, the User: namespace prefix has gender aliases.

JJMC89 removed a project: Cloud-Services

Looks good to me as a sysop.

There are no more complaints about about "docserver-http: HTTP 400", and I cannot find it recent event logging either, so I'm closing this.

I can reproduce it. It has been happening for a long time, and I somehow was lazy to report a bug properly, even though I really love reporting bugs :)

I'm not sure why was it marked as resolved. Did anyone fix it in the App Store?

I just tested this in production with a navbox.