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.

Extended Date/Time Format (EDTF) Specification as of 2019-02-04. I still think that citoid and other tools that pass dates back and forth should adopt IETF or something similar so that there is a single standard for date representation. Let the templates that present the date information worry about month-name and date format presentation according to the rules of the particular wiki.

The issue is improper returns from the {{#language:}} magic word. Here are others:

Other anomalies: the Sámi or Sami? Pick one spelling with or without the diacritic to be consistent:

• {{#language:se|en}} → Northern Sami
• {{#language:sia|en}} → Akkala Sámi
• {{#language:sjd|en}} → Kildin Sami
• {{#language:sje|en}} → Pite Sami
• {{#language:sjk|en}} → Kemi Sámi
• {{#language:sjt|en}} → Ter Sámi
• {{#language:sju|en}} → Ume Sami
• {{#language:sma|en}} → Southern Sami
• {{#language:smj|en}} → Lule Sami
• {{#language:smn|en}} → Inari Sami
• {{#language:sms|en}} → Skolt Sami

Something else that I notice that you did not mention: theidentifier labels: doi, ISSN, and PMID, all have external link icons; they should not, those labels are wikilinked to their respective articles.

I can't reproduce it; perhaps it is a ve anomaly (I do not use ve)? Does this problem occur because that citation doesn't actually exist in the §Symptoms section?

umm, where did you find that?

Because in the diff, the responsible editor is InternetArchiveBot. Clicking on the responsible editor's talk page link. On the responsible editor's talk page it says:

no. |url-access= has nothing to do with |dead-url=. Perhaps you mean |url-status=?

Functionality that "exists" but isn't at all documented, doesn't exist. Please, those of you who know how this wrapper thing works, document it so that the rest of us can learn to use it correctly.