Template talk:As of

lc parameter without a value

The documentation says that the lc parameter gives lower case for any value of the parameter, but what is confusing is that it gives lower case even without a value.

See the following examples:

• {{As of|2019|02|24|lc=y}} as of 24 February 2019

• {{As of|2019|02|24|lc=}} As of 24 February 2019

• {{As of|2019|02|24}} As of 24 February 2019

--David Biddulph (talk) 16:12, 24 February 2019 (UTC)

That is confusing, having two default parameters. Could we have a quicker way to set the case? I'm thinking {{ASOF|2018}} and {{asof|2018}} as aliases. HLHJ (talk) 23:43, 19 September 2021 (UTC)

I would still really like this functionality. I try to put a sentence's core info first, and "as of X" is usually supplementary info the reader doesn't care about, or understand the meaning of, until they know what the main fact is. So I usually put it last, and typing "|lc=y" is a pain. Does anyone have objections?

Separately, "as of mid-March" (late, early) also returns an error. HLHJ (talk) 19:19, 17 March 2023 (UTC)

Template introduces too much space?

The top line of Template:As of should read "18.November.2021" (replace dots with spaces), but looks more like "18..November..2021" to me. Anyone else think the spacing looks wrong? Ghastlyman (talk) 15:41, 18 November 2021 (UTC)

Edit: I meant, not just in that example, but elsewhere where the "as of" template is used, too. Ghastlyman (talk) 15:48, 18 November 2021 (UTC)

Edit 2: This may be what @Ravenpuff is referring to above; I can't tell. For another example, see @David_Biddulph's entry above, which looks like "24..February..2019" to me. Ghastlyman (talk) 16:05, 18 November 2021 (UTC)

It looks fine to me. As far as I can tell, the template places one non-breaking space between the day and the month, and another between the month and the year, like this: as of 24 February 2019. That looks fine to me. – Jonesey95 (talk) 19:28, 18 November 2021 (UTC)

Thanks for the reply. I notice that the same problem occurs when people use just the {{nbsp}} template by itself. Further, I'm using the Firefox browser, and just noticed that Brave browser looks ok. Maybe a CSS thing? I'll ask on the Help Desk to get wider audience. -- Ghastlyman (talk) 14:01, 19 November 2021 (UTC)

@Ghastlyman, Sdkb, Jonesey95, and Ravenpuff: I've just noticed the same problem. For example, the source is given as "21 June 2022" and is rendered as "21 June 2022", without extra spaces in the source, and #160 = #xA0 = nbsp, so the template clearly outputs the expected character string as intended. I suspect that this is an intended feature of firefox rather than a bug. With variable width fonts, there is presumably an expected standard size of a non-breaking space. Though maybe it's a CSS issue?

Proposal: how about we consider the narrow non-breaking space for use in As of instead of the regular one? This would give "21 June 2022" and be rendered as "21 June 2022". To show these together:

"21 June 2022" current 160 = xA0 = nbsp

"21 June 2022" proposed 8239 = x202F = nnbsp.

To me, x202F looks (renders) much better. Boud (talk) 17:35, 21 June 2022 (UTC)

I would not support that, as it's not the intended use case of narrow non-breaking spaces, and I don't think it's advisable to introduce additional complexity to our manual of style, which would have to approve a change like this that would apply to all dates. {{u|Sdkb}} ^talk 18:13, 21 June 2022 (UTC)

In my browser (Firefox for Mac OS), the second example, x202F, looks much too narrow. If people are seeing extra white space when the template appears to be sending a normal nbsp to the browser, that sounds like a browser rendering bug or a computer configuration problem, or possibly a MediaWiki bug, to me. It does not appear to be something we should attempt to work around only in this template, given the number of nbsps that are used throughout Wikipedia. – Jonesey95 (talk) 18:25, 21 June 2022 (UTC)

Boud, if you log out and use a different browser or a different device (e.g. mobile phone), or use your preferred browser in its Safe mode, how do the above spaces look? Ghastlyman noted above that the problem went away with a different browser. – Jonesey95 (talk) 18:26, 21 June 2022 (UTC)

Which one looks better probably depends on the details of your browser/wikipedia configuration. On my phone, they render identically. On my laptop (with my browser, skin, and custom CSS), the NNBSP case is much too tight and the NBSP case looks normal. In default WP settings (incognito mode), both look pretty good for three cases, but with NNBSP, the space between "June" and "2022" is too narrow. In any case, NBSP is supposed to act just like a space except for line breaking (though it is sometimes incorrectly implemented as a fixed-width space) and NNBSP is not intended for Latin text. --Macrakis (talk) 21:01, 21 June 2022 (UTC)

firefox-esr 91 logged out: same effect as when logged in - 160 is too wide; x202F looks OK. So it's not an effect of my particular choice of Wikipedia/mediawiki preferences. I checked that firefox has the "default" font selected, and allows pages to choose their own fonts.

* firefox-esr 91, View - Page style - No style - 160 is too wide; x202F looks OK. My guess is that this rules out css as the culprit(?)

* Midori 7: 160 looks OK, and x202F looks OK too; there is a difference, but it's extremely tiny - probably just a few pixels

* Lynx 2.9 - identical rendering of the two options, both look OK (monospace font in terminal)

* Links 2.21 - again, identical rendering (monospace font in terminal)

* PinePhone/Mobian/firefox, mobile view, i.e. en.m.wikipedia.org: both look OK, no noticeable difference

* non-mobile view on the physical PinePhone running Mobian GNU/Linux and using firefox is similar to firefox on my desktop - 160 is too wide, and x202F looks OK.

* physical desktop device, firefox 91, en.m.wikipedia.org: both look OK, no noticeable difference

Chrome/chromium is really bad for privacy violations (though chromium on Debian presumably has some security fixes), so I'd prefer not to test it. I'm glad that the US secret services have cracked Russian army communications to great depth, but Wikipedians don't need to voluntarily offer our computers up as easy cracking targets.

I'm not eager to play around with fonts, because for the past few years, I've had a lot less problems with web page fonts than before, which I assume is due to more clever firefox defaults and font-related parameters that handle most real-world cases. So I guess either a firefox or mediawiki or font bug (nbsp implemented as a fixed-width space?) would appear to be the best current hypotheses. Boud (talk) 21:06, 21 June 2022 (UTC)

I don't see how this is a mediawiki bug, since the problem occurs in a trivial html file that I wrote by hand and tests both nbsp and nnbsp, except indirectly in the sense that mediawiki (and Wikipedia) do actually use nbsp, so the problem may be more obvious with Wikipedia's as of template than on web pages that don't bother with nbsp at all. In other words, as of helped to discover the bug. If someone finds where this has been posted as a bug (I searched but failed to find it), or posts a bug report, a brief comment and pasting of the URL here would help people who are interested, so that people who get to this page at least know how to find out if the bug has been reported, and if so, how to check what's being done with it. Boud (talk) 21:52, 21 June 2022 (UTC)

I'm using Firefox (on a desktop with "Vector legacy (2010)" skin and Javascript disabled) and it looks 100% okay for me. The template issues the proper   character just as it should - this should not be changed to the narrow nbsp, which would be too narrow. If this does not render okay in some configurations the problem is elsewhere. I would suspect some skin- or CSS-related issue. --Matthiaspaul (talk) 22:47, 21 June 2022 (UTC)

It sounds like this might be a bug in Firefox ESR for your platform, Boud. Nice troubleshooting. If you can create a simple test case, you could submit it via https://bugzilla.mozilla.org. – Jonesey95 (talk) 23:54, 21 June 2022 (UTC)

I eventually solved the spacing problem, in my case, by just fiddling with Firefox fonts. I don't recall the exact fix. - Ghastlyman (talk) 06:02, 22 June 2022 (UTC)

@Boud: You may have good reasons for avoiding Chrome/Chromium, but since it is by far the most common browser platform, any survey that omits it is not terribly useful. --Macrakis (talk) 17:52, 22 June 2022 (UTC)

date formatting

I ask without judgment because I know next-to-nothing about template programming, but why doesn't {{as of}} check for a time and date maintenance template (e.g. {{use mdy dates}}) for automatic formatting of the date (similar to citation templates)? — Fourthords | =Λ= | 15:55, 9 April 2023 (UTC)

I just came here to ask the same thing.

{{Use mdy dates}} tags pages with a maintenance category, and templates can modify behavior depending on page categories (see e.g. {{if in category}}), so it should be possible. The categories are parameterized by month (Category:Use mdy dates from October 2024 instead of just Category:Use mdy dates), so it'd probably require some custom Lua, or additions to Module:If in category to optionally walk the category tree. DefaultFree (talk) 21:55, 18 October 2024 (UTC)

Template-protected edit request on 5 November 2024

139.135.241.38 (talk) 18:25, 5 November 2024 (UTC)

--139.135.241.38 (talk) 18:25, 5 November 2024 (UTC)

 Not done: it's not clear what changes you want to be made. Please mention the specific changes in a "change X to Y" format and provide a reliable source if appropriate. DigitalChutney (talk) 22:55, 5 November 2024 (UTC)