@Samwalton9 , thanks for pinging. :) I think, it's alright now. I also posted a notice on German Wikipedia where the issue came up: https://de.wikipedia.org/wiki/Wikipedia_Diskussion:F%C3%B6rderung/The_Wikipedia_Library#Favoriten-Funktion_defekt? So, if you would like to close the task, please go ahead!

Favouriting works immediately for me (the number increments and the authorization is visible in the Favorites tab). Per @jsn.sherman, however, new favorites are placed at the end of the list and are only alphabetised on a page reload.

@jsn.sherman Thanks for the fix! I've tried it out in Firefox on macOS, and it works.

@jsn.sherman I think we can close the issue. I have not had any problems accessing Springer Link lately. Thanks, again, for your kind assistance!

I sedond your suggestion. I just would like to add that if you should opt for a popup solution in the end could you please make it opt-in only? All such major changes to the user interface should be active opt-in, i.e. they should be switched off by default.

Moving something to popups coudl be a solution. But please note that power users are prone to use Navigation Popups already, so the two should not interfere.

@Jdlrobson we are discussing re-opening this task on dewiki. Could you please have a look into this? Thanks!

@Jdrewniak , your proposed fix to WikidataInfo has been accepted, and the sciript now works as expected:

@Jdrewniak , thank you for looking into this and for contacting @Yair_rand both on this platform and on Wikidata. I would be grateful if you please could fix the issue before the new version of Vector 2022 goes live. Also, I had not realised yet that #contentSub is back again. That's even better.

@Jdlrobson I admit, I had to take a look into my Browser console :) Here it is:

So, I have closed Firefox, renamed my profile, and restarted Firefox again. Logged into Wikipedia and the TWL. Result: SpringerLink worked fine, and so did DeGruyter.

BTW, there is another strange issue with FF 107.0 in MacOS 12 that could be connected to this one:

I'm sorry I did not try another browser before. When I answered your last post about an hour ago I was so much focused on enumerating and re-enabling my add-ons I just forgot about that.

Thanks for your suggestions.

Thanks for checking. No change here, i'm afraid. Same error message as yesterday. The problem only persists with Springer Link.

@jsn.sherman Would you please let me know if there is anything I can do to help find the issue.

I'm afraid I have to correct my former post, as I've just realised that WikidataInfo now appears right below pagetitle. So it seems to work for me. Thx.

Pls cf. also these discussions on German Wikipedia https://de.wikipedia.org/wiki/Wikipedia:Fragen_zur_Wikipedia#Vector_2022_kaputt and on Wikidata for another broken script: https://www.wikidata.org/wiki/User_talk:Yair_rand/WikidataInfo.js#Vector_2022:_Info_not_shown – help would be much appreciated. Thx.

I think this bug report could do with a bit of attention, couldn't it? Thanks.

Thanks. But you might remember the Hitchhiker's Guide to the Galaxy and the part about the planning charts that had been on display somewhere around Alpha Centauri for some fifty earth years without anyone ever realising it? ;)

I strongly agree with my fellow users from German Wikipedia. We are very much used to this feature which is rather useful for reading and writing long articles. Also I have no issues as to website performance etc. Please keep this feature.

Same here. Seems to be working again. Thanks a lot for the quick fix!

I can confirm that the broken main page on dewiki is due to an error in discussion tools. :(

+1. It would make it so much easier to edit Wikipedia, and it would also give back power to the editors who are not content with what the machines do automatically.

Yes, the second scrollbar remains visible when I open the main page of German Wikipedia in Firefox 81.0.1 on macOS 10.13.6.

For the record: I could use drag and drop with a footnote tonight for the first time again. :)

It is the same after updating to Firefox 67.0.

I am sorry to say that the issue has come up again on Geman Wikipedia, so I have reopened the task for re-evaluation. @Cirdan has made a good point in describing the issue and the solution for dewiki above. In the meanwhile @Crazy1880 pointed out to an entry in OCLC that of course does contain the OCLC number, but not an ISBN. In German-speaking countries we rarely refer to OCLC ids. Also, we rarely use WorldCat, we prefer the catalogues maintained by our national libraries that issue ISBN and ISSN for German-language publications. So, I subscribe to Cirdan's description and I would be grateful if you please could change configuration accordingly.

Just to make sure: This worked before, and it only happens in JSTOR, no other resource is affected. I did not change anything about the local configuration.

Am 18.05.18 um 00:05 Uhr schrieb Denny:

Copyright has to be about some concrete expression.

Am 14.05.18 um 22:36 Uhr schrieb Nemo_bis:

But law is a matter of quality rather than size.

But quantitative indicators can be a proxy for quality. A dataset with
just 200 statements has most likely been produced by dozens or hundreds
of entities none of which can claim any meaningful exclusive right.

Am 14.05.18 um 17:23 Uhr schrieb Nemo_bis:

But I'd argue that nobody would see such a dataset as problematic,
especially because it's so small (few hundreds data points).

Am 14.05.18 um 11:37 Uhr schrieb TomT0m:

The more I personnaly dig into this questions, the more issues are
opened and the less clear it becomes that there is an actual issue, and
if there is an actual issue if there is a legal risk. Or even if there
is a moral or ethical issue: I think we will all agree here that pure
facts can be used by anyone (beyond private life one).

Am 13.05.18 um 13:43 Uhr schrieb Simon_Villeneuve:

Please note that there is not one copyright law. There are as many copyright laws as there are legal systems Wikipedia and Wikidata content can be retrieved from.

@Esanders I have restarted Firefox on El Capitan with a fresh profile, and I have switched off auto hypenation on Meta Wiki. No changes, I'm afraid. :( Strange that it seems to work for you... Again, thanks for looking into this!

Thanks for testing, @TBolliger ! Meanwhile I have upgraded to Firefox 59.0.2, still on El Capitan, and it still looks as bad as it was before on my machine:

Yes, I run FF ESR 52.7.3 on El Capitan, and given that the release is already there tonight (is it?), I'm sorry to say that nothing has changed. :(

Here is an example of what it looks like with me.

I'm afraid it is even worse than it was before. Text now looks blurred etc. even immediately after switching on syntax highlighting on my system (same as above, now FF 52.7.2 ESR). When we started out the effect appeared only when you began to enter some text in the editor...

Because of the recent renaming of this task by @TBolliger I'd like to point out once again that this is not only an issue concerning Chinese text, but also latin scripts and fonts.

I second the suggestion to introduce a switch for the template an author deems fit for a citation.

I can confirm the issue with Firefox ESR 52.5.3 under El Capitan on German Wikipedia, i.e. no Chinese fonts, but monospace, viz. Courier. It first showed up right after T175223 was implemented. I am sorry that I didn't have the time since then to open another task. As was mentioned before, I have also found it helpful to toggle syntax highlighting, or to undo an edit in order to get rid of the blurry fonts. Also, it seems to make a difference whether you start typing underneath some text, e.g. on a talk page (more apt to show the fault), or whether you start editing in the middle of a text.

I forgot I also have to change the status of this task in order to have it reviewed again.

Shortly before I pass into the weekend I would like to thank you for applying the fix I requested.

In T95702#3805603, @ManosHacker wrote:

In fact this has already been secretly implemented on July 2017 and it worked then (I checked Greek and English Wikipedias) but now is withdrawn.

The more I work with VE and the new wikitext editor the more I get used to tools like citoid. For the time being, I switch from VE for creating a citation to wikitext for removing the ref tags in the Further Reading section.
I think the suggestion by @ManosHacker would be a good idea to start with.
I suggest to raise the priority of the task because it is really important to expert authors, as @Sadads has already pointed out.
I have opened a discussion on German Wikipedia.

This is just to let you know that I can confirm that—for the time being, at least—I have been able to use OTRS with IPv6 disabled in Firefox, or in OS X Mavericks, for that matter.

Today, I have got the advice to set network.dns.disableIPv6 in Firefox about:config to "true".

Please note that the case of dual IPv4/IPv6 addresses is indeed one main problem we reproduced some weeks ago in issue T88224 which was soon closed and marked as a duplicate to this ticket. Such broadband connections are provided per default in this country.

Please note that we have tried this out in

I just would like to say that some of us have not been able to work in OTRS at all, including myself. I keep being logged out after some minutes, on some occasions after a few clicks, while the scenarios you are discussing are rather hypothetical, if I may say so.