don't know if this is the same issue or not but, at en.wiki, this search for "deprecate_|citeseerx=_?" correctly finds the section but produces a red link to the section in the search results. At this writing, that section is #65 in Archive 102's ToC. The link from the ToC works correctly.

In T424914#11969844, @Bhsd wrote:

The vertical rule is on by default like CodeEditor, but users can disable or customize it (position/color/thickness) in their personal CSS.

Whatever happened with this?

For the sake of clarity, en:List of XML and HTML character entity references shows that the HTML entities for the pipe character (U+007C) are:

• |
• |
• |

Doh! Pointing the template to the live module and everything appears to be working as it should. Thank you.

I don't think that the suggestion list ever displayed mw.loadData. Not sure what you mean by "Template:Current_leader/testcases isn’t on that page anywhere" where I interpret "that page" as Module:Current_leader/data. Of course, the testcases page isn't on the module page but rather, its the other way round: Module:Current_leader/data is on (transcluded into) ~/testcases.

In the previous editor, the rule was (so far as I know) on by default, not toggleable, and fixed at the right side of the 80th character position. I can't see any harm in making it: on by default, toggleable, movable, and perhaps configurable (color, width, what have you).

Because the insert key is not available on all keyboards? That does not seem to me to be a valid reason to prevent those of us who do have the insert key from using it.

A problem that may be related to this issue is discussed at en.wiki (permalink). An editor there has implicated the aforementioned security patch.

This link:

• https://commons.wikimedia.org/w/index.php?title=Data:CS1/Identifier_limits.tab&action=edit

works to get access to the json structure whereas this link:

• https://commons.wikimedia.org/wiki/Data:CS1/Identifier_limits.tab

fails with the Service Temporarily Unavailable error page.
Using the working link, I attempted to update the PMC data value (11900000 → 12100000) and then save that. At first I thought that the edit did not save because I got this 'server timed out' error message:

• [1af4da7b-b27c-42ec-a0bc-d68d813c7c54] 2025-03-21 00:12:10: Fatal exception of type "Wikimedia\RequestTimeout\RequestTimeoutException"

Interestingly, the edit was saved. Using =mw.dumpObject (mw.ext.data.get ('CS1/Identifier limits.tab').data) from a module debug console after the 'edit' shows that, in fact, the updated value was saved.

How is anyone to know that? Your https://en.wikipedia.org/wiki/Template:Welcome and https://en.wikipedia.org/wiki/Template:Welcome/doc do not have __EXPECTUNUSEDTEMPLATE__ so no help there.

"Adding the new magic word EXPECTUNUSEDTEMPLATE to a template page will hide it from the listing." 'to a template page'. Which? The template wikisource itself? The ~/doc page? The talkpage? Which?

apparently it has now been fixed (thank you) so reclosing

And broken once again... Please stop fixing stuff that ain't broke.

At en:Wikipedia:Village pump (technical)#Tech News: 2024-03, the first bullet point says that tab characters are now used for indentation for JSON content model. Apparently not for tabular data at commons (Page content model: Tabular.JsonConfig). I recently created c:Data:Sandbox/CS1/Identifier limits.tab using an external text editor that uses tab characters for indenting. When I saved that page at commons, all of the tab characters were replaced with space characters.

The obvious difference between my settings and Editor Novem_Linguae's settings is that I have checked 'Use non-JavaScript interface' and Novem_Linguae has not.

Apparently not fully fixed. Configuration same as stated in the OP. Here are some images

At en.wiki, arrows appear to point in the correct directions now. Thanks.

This from my watchlist at en.wiki. All of those arrows should be right-pointing. Apparently the alignment issue noted at de.wiki is somewhat mimicked at en.wiki.

it is broken on en.wiki as I noted in the OP.

I added that css to my common.css and now I have correctly colored and functioning watchlist markers. Please update the gadget css or if you cannot, add an interface-protected edit request to the gadget css talk page.

No. In this image, the watchlist item for Wikipedia:Village pump (technical)‎‎ should be a green right-pointing arrow, not a green dot. The marker should be distinguishable from the green dot attached to watchlist item HMCS Bras d'Or (FHE 400)‎

This is only partially resolved. Before today's update, the collapsed and uncollapsed 'arrow-like' markers were always gray in color whether they had been visited or not. After today's update, unvisited collapsed watchlist items now have a green dot marker (should be a green right-pointing-arrow-like marker). Clicking the dot of an expandable watchlist item, expands the list but the marker does not change to a down-pointing-arrow-like marker. Once all of the unvisited entries in an expanded watchlist item have been visited and the watchlist refreshed (F5), the marker changes to a gray-arrow-like marker.

Not clear what you are talking about. Sometime between the time that I wrote T256649#7246452 and today, someone has fixed something so that at en.wiki the language names now render in English as they should:

• {{#language:sty|en}} returns: Siberian Tatar
• {{#language:es-formal|en}} returns: Spanish (formal address)
• {{#language:hu-formal|en}} returns: Hungarian (formal address)
• {{#language:nl-informal|en}} returns: Dutch (informal address)

That is what I wanted to see fixed and now that it has been, thank you to whomever it was who did the fixing. I don't think that I have ever written about wikidata in this discussion because that is a place that I prefer to avoid.

the editor reports that they "typed the title of the book in the automatic citation field and then picked the book which came up as an option"

The editor who added the {{cite book}} template is a relatively new editor (as I write this, 19 edits; all done with ve). The formatting is uniform which suggests that a tool made the template. These things suggest that some something created the citation which the editor accepted as written without carefully inspecting it. I suspect ve because the edit is tagged with 'Tag: Visual edit' so, without a more obvious culprit, ve seems the likely suspect.

I find it hard to believe the editor who added the citation would have intentionally written: |last=1945-. That suggests that some something created the citation which the editor accepted as written without carefully inspecting it. I suspect ve because the edit is tagged with 'Tag: Visual edit' so, without a more obvious culprit, ve seems the likely suspect.

• Does this still happen with safemode on? Yes
  • • What skin are you using? Vector legacy
    • Does this happen with other skins, for example
  • Vector 2022: Yes
  • Vector legacy: Yes
  • Timeless: Yes
  • Modern: Yes
  • Monobook: Yes
  • Minerva: Yes

Despite what Editor Reedy apparently believes, T297568 is not about the length of the edit summary output from awb but rather, it is about the number of characters that the 'default summary' text box on the start tab will accept as input. I think that T297568 and T199347 are separate issues; related, yes, but still separate. T199347 is an old (relatively) issue opened 2018-07-11. I know that edit summaries created with a c# module can be longer than the 155ish characters that the 'default summary' text box allows. By merging T297568 into this task, that distinction gets lost.

I have no doubt that images can be attached at phabricator. I would still have to learn how to do that.

Because it has been so long since I've captured and posted a screenshot that I first have to relearn out how to do the capture and then relearn how and where to post it. I don't have to relearn anything about typing a description.

not for me

I don't know the answer to that question; the text 'errorhandler' (spaced or unspaced) isn't obviously present in the displayed window.

In the week or so since my post (T256649#7246452), the four codes mentioned have been fixed at en.wiki.

In T256649#7246285, @Esc3300 wrote:

It works for the four above. Shall we close this as done?

Thanks. The redlinked ISBNs are not the fault of the cs1|2 templates but are the fault of malformed wikilinks to Special:BookSources in this sort of construct; not clear what the purpose of this is:
<bdi><cite class="citation book cs1" data-ve-ignore="true" id="CITEREFChamplin2005">[[Speciale: BookSources / 978-0-674-01822-8|978-0-674-01822-8]]</cite></bdi>
particularly the whitespace ahead of the /

The error messages that are shown in the screen cap are the result of discussion that took place on my en.wiki talk page.

In T132308#6983334, @Mvolz wrote:

@Trappist_the_monk any chance of unearthing the old CS1 code to make these more human readable? Here's an example DOI for testing: 10.1016/S0305-0491(98)00022-4

Already done in cs1|2 sandbox; module suite update is scheduled for this weekend. See https://en.wikipedia.org/wiki/Help_talk:Citation_Style_1#edtf_date_formats_as_cs1|2_date_parameter_values_(2)

For providing a url to link the static text 'Lay summary'. The lay summary is not the cited source so does not have the same 'privileges' as |title= and |url=. An archaic hold-over from the olden days. Were it up to me, I would get rid of all of the lay parameters in favor of having editors write separate, complete citation templates (with author, date, work, and all of the rest) ...

As far as it goes, that seems sensible. What you have omitted is to say what happens when the language tags are not known language tags. What then?

Related perhaps but certainly not a duplicate of T244787 (which problem still exists)

Another oddity that we have come across is {{#language:he|am}} which is terminated with U+FEFF zero width no-break space.

I came here because of the LRM mark. I once authored T244787 which addressed some of the same issues are are addressed here. That, as you can see was declined.

I love it when something fixes itself. I didn't fix (though I have tweaked that citation some just now).

In T132308#6856766, @Mvolz wrote:

(I was just confused by the IETF statement because I couldn't find anything like that in IETF, i.e. https://tools.ietf.org/html/rfc3339 )

Yeah, my error; I type IETF much more often than I type EDTF...

In T132308#6856766, @Mvolz wrote:

I'm happy to do EDTF level 1 abridged dates instead if that's preferable to the level 0 format.

Let us stick to a single term: 'unspecified digits'; 'abridged' implies a truncation or shortening which isn't the case. The date 2021-02-XX is just as long as 2021-02-24.

In T132308#6856035, @Mvolz wrote:

I'd be happy to consider switching to a different way of representing partial dates that doesn't require the use of English, but unfortunately no one has suggested a standard that doesn't that I've noticed @Trappist_the_monk you suggested IETF but I had a look and couldn't find a partial date representation there - did I miss it maybe?

Isn't that what most of the whole long discussion has been about? The current IETF at Level 1 §Unspecified digit(s) from the right at item 3 reads:

Year and month specified, day unspecified in a year-month-day expression (day precision)
Example 4 ‘1985-04-XX’

Does that not provide a way to do month year dates that don't require English?

In T132308#6856035, @Mvolz wrote:

The relevant discussion page is here: https://en.wikipedia.org/wiki/Help_talk:Citation_Style_1#edtf_date_formats_as_cs1.7C2_date_parameter_values

That discussion has been archived.
The discussion where edtf was removed is also archived

For the YYYY-MM date format to be accepted at en.wiki, you will have to get it accepted at MOS:NUM. Were I you, I would not hold my breath.

I suspect that the %2 is a corruption of %22 the double quote character; support for that is shown in this edit where the %22 became %2.