If it is of any help, when I try to open the file with Adobe's acroread, it reports "stat buffer overflow" error, while evince opens it nicely (if slowly).

I don't know who, how and when, but this is fixed, in fact.

In T117845#4008101, @gerritbot wrote:

Change 415161 had a related patch set uploaded (by Fomafix; owner: Fomafix):
[mediawiki/core@master] [WIP] Rename language codes sr-e[cl] to sr-(cyrl|latn)-ekavsk

https://gerrit.wikimedia.org/r/415161

In T117845#3478610, @Fomafix wrote:

In T117845#2450381, @Nikola_Smolenski wrote:

• How will srwiki URLs look like? Will https://sr.wikipedia.org/sr-el/Beograd still work? If not, will there be provided a redirection?

The current variant URL https://sr.wikipedia.org/sr-el/Beograd will still work because https://sr.wikipedia.org/w/index.php?title=Beograd&variant=sr-el will be still supported and deliver the same result as https://sr.wikipedia.org/w/index.php?title=Beograd&variant=sr-latn. To support a new variant URL https://sr.wikipedia.org/sr-latn/Beograd a new additional alias definition can added.

I shall note, there were plans to use the codes sr-jc and sr-jl for sr-cyrl-ijekavsk and sr-latn-ijekavsk but I don't know that they were ever used in practice, though perhaps they maybe still dwell somewhere in MediaWiki code.

I do not understand how could this task possibly be low priority. This potentially affects every language that has variants.

Are you even supposed to get Serbian when searching on sr.wikipedia.org? Either way, yes, I am facing the same issue on Serbian Wikipedia and German Wikipedia.

In T132021#3842110, @Etonkovidova wrote:

Typing "српски" or "srpski" will work until the very last letter- "и" or "i" is typed. Strangely that "Serbian" does not work too.

Thank you, everything seems to work well :)

BTW, me and @Nikerabbit found a satisfactory solution for this at Wikimania 2016: in a certain regular expression, simply, instead of searching for the substring at the beginning of a language name, search for it at a word boundary. Not sure why is it not implemented.

This task is still open, but the codes have already been introduced on Wikidata, creating some problems, see T121747.

In T7309#2451374, @Nemo_bis wrote:

They may not have a keyboard to enter things in English, for that matter, no?

OK, now Serbian appears, but with Serbian Cyrillic and Serbian Latin as separate languages. This means that all the Serbian content entered so far, which was entered under the code 'sr', will not be available. Has there ever been a discussion to use two separate codes for Serbian language? Was there a final decision? If yes, what could be done about old content?

In T7309#99747, @zeljkofilipin wrote:

Serbian (sr) is strange too. I think both Latin and Cyrillic are official there, but isn't it strange to ask for people to change input method (from Latin to Cyrillic, and vice versa) in the middle of captcha, like here?

https://www.dropbox.com/sh/i2af7xvn4y593gc/ocKv1yBPuf/captchas/sr#lh:null-image_e373536e_2ecbd37b76d67185.png

The above is not the only example.

If this change is internal only, I have no objections. I'd just have two questions:

As I see it, the actual code change that is needed is that compact interwiki lists should have the feature to "force" some languages into the list - either by having a configuration parameter for that, and/or by recognizing Wikibase's sortPrepend.

In T138973#2420849, @daniel wrote:

Wikibase does apply sorting to language links, governed by the interwikiSortOrders and sort options in $wgWBClientSettings, and implemented by the InterwikiSorter class.

I believe this problem is independent of the search backend, so I returned it, hope that's OK.

I tested this for some other languages with multi-word names, with article https://en.wikipedia.org/wiki/Indonesia

I guess this could be solved if all the languages with names that have multiple words would have the words as aliases, so that they are matched by prefix. I guess Bahasa Melay is already this way.

So perhaps the bug is that sr_Latn and sr_Cyrl codes are not reduced to just sr?

Similarly, when I go to https://en.wikipedia.org/wiki/Main_Page and click on the gear icon next to "Languages", I get the "Language settings" window; now when I click on "Input" and "Enable input tools", the list of languages I get under "Language used for writing" is "English, shqip, magyar". This is probably the same underlying issue.

Well that workaround is not at all obvious, since while entering "sr", "srp", "srps" etc. only "srpskohrvatski" would appear, leading users to think there is no Serbian. It's not just that the search by language code fails, it's that the search by prefix fails too.

I agree to release my initial version and all my contributions to Poem Extension under CC-0.

It works now on srwiki too, thanks to everyone involved for the quick resolution! :)

By the way, if this problem can't be fixed soon, there is a workaround in TWA:

I believe this would probably be fixed if params 'tour' and 'step' would be added inside RedirectSpecialArticle::__construct()

This initiative is led by Sanja Pavlović, I only wrote the request because she is not familiar with the Phabricator. I told her that she needs to start the discussion of the new feature, so I will report the outcome when she does.

Thank you @hoo for the quick upload :)

I was going by T91053 where it was recommended that all the files are in a single archive, and that maximal upload size is 250MB.

A new(?) development: while canonical URLs were apparently never really canonical, AFAICT so far Google was smart enough to offer them in the nice https://en.wikipedia.org/wiki/Page format. However, recently I noticed that it is often starting to offer them in https://en.wikipedia.org/?title=Page format.

This reminds me of T50804 and is possibly the same underlying issue.