Fri, Sep 17
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).
Fri, Sep 10
Mar 26 2020
Feb 28 2018
I don't know who, how and when, but this is fixed, in fact.
Feb 27 2018
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.
Jan 31 2018
I do not understand how could this task possibly be low priority. This potentially affects every language that has variants.
Dec 16 2017
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.
Dec 15 2017
Thank you, everything seems to work well :)
Oct 31 2017
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.
Jan 23 2017
Aug 15 2016
Jul 14 2016
This task is still open, but the codes have already been introduced on Wikidata, creating some problems, see T121747.
Jul 12 2016
Jul 11 2016
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?
If this change is internal only, I have no objections. I'd just have two questions:
Jul 10 2016
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.
Jul 2 2016
Jul 1 2016
Jun 28 2016
I believe this problem is independent of the search backend, so I returned it, hope that's OK.
May 5 2016
I tested this for some other languages with multi-word names, with article https://en.wikipedia.org/wiki/Indonesia
Apr 8 2016
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.
Apr 7 2016
Dec 17 2015
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.
Dec 7 2015
Nov 25 2015
I agree to release my initial version and all my contributions to Poem Extension under CC-0.
Nov 20 2015
It works now on srwiki too, thanks to everyone involved for the quick resolution! :)
Nov 19 2015
By the way, if this problem can't be fixed soon, there is a workaround in TWA:
Nov 17 2015
I believe this would probably be fixed if params 'tour' and 'step' would be added inside RedirectSpecialArticle::__construct()
Aug 20 2015
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.
Aug 4 2015
Jun 21 2015
Thank you @hoo for the quick upload :)
Jun 20 2015
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.
Jun 19 2015
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.
May 22 2015
This reminds me of T50804 and is possibly the same underlying issue.