This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.
What is the purpose of the (({text))} at the start of the document? — Preceding unsigned comment added by Nice44449 (talk • contribs) 16:52, 20 June 2022 (UTC)
That is not the start of the documentation, that is what the code looks like if there is no input values; it defaults to showing something rather than nothing to indicate that the editor is not using the template properly. Primefac (talk) 08:36, 21 June 2022 (UTC)
So is the purpose to show what it looks if the template is used improperly (in which case I think it should be labelled as such)? Nice44449 (talk) 20:40, 21 June 2022 (UTC)
It has no purpose; it's just what the code looks like. Primefac (talk) 08:10, 22 June 2022 (UTC)
Colourblind safe palette
It's been raised in the Vaccination policy article that the colours used in the table are not colourblind safe. The colours used there are from the templates in this family. Indeed, we can see it here some of the colours are indistinguishable from one another to a colourblind reader (put https://en.wikipedia.org/wiki/Vaccination_policy#Table in the input box to jump directly to the table). MOS:COLOUR gives a few links to colourblind safe schemes, including this one, which we could use to realign the colours' lightness. I see this issue has been discussed 12 years ago, and again raised 8 months ago by Nealmcb. — Guarapiranga☎ 08:10, 14 July 2022 (UTC)
Strong support. I came here to propose this. Specifically, I think ((ColorCell|1)), ((ColorCell|2)) etc. should produce sequential colours in a discrete-distinct-colours colourblind-safe palette. I suggest this one: "black"="#000000", "cb_orange"="#E69F00", "cb_darkblue"="#0072B2", "cb_red"="#D55E00", "cb_pale_blue"="#56B4E9", "cb_yellow"="#F0E442", "cb_purple"="#CC79A7", "cb_green"="#009E73" (I used it on this figure, see links for references). This would be useful for colour-coding arbitrary categories. I'm willing to do this; comments welcome. Then we should adjust the other colours, associated with meanings, to be colourblindness-distinct. HLHJ (talk) 19:35, 3 September 2022 (UTC)
Should ((n/a)) render as an em dash (—) by default instead of N/A? — Guarapiranga☎ 21:21, 30 May 2022 (UTC)
Support. I've often piped ((na)) to render an em dash (—) instead of N/A; it looks cleaner, and I've noticed it seems to be the standard outside enwiki (not least bc N/A doesn't translate well). Should it be the default on enwiki too? I think it should, but if that's not the consensus, I'm just as happy to keep on piping it. — Guarapiranga☎ 21:27, 30 May 2022 (UTC)
Support. A whole field of "N/A" is distracting to wade through. It's much easer to parse as em dashes. — SMcCandlish☏¢ 😼 02:45, 31 May 2022 (UTC)
I see no prior discussion, nor any indication that WP:RFCBEFORE has been tried, let alone exhausted; so why have you gone straight to a full-blown thirty-day formal RfC for this? --Redrose64 🌹 (talk) 09:31, 31 May 2022 (UTC)
Apologies if I mistepped Redrose64. I thought it was a change wide and (possibly) contentious enough not to follow the usual WP:BRD cycle, so I decided to be WP:CAUTIOUS, and invite comment from a broader selection of editors than a normal talk page discussion (WP:RFC). I understand RfC can act as a dispute resolution; I didn't know it required a dispute to be used though. As for the 30 days, what WP:RFC#Duration says is that Legobot assumes an RfC has been forgotten and automatically ends it (...) 30 days after it begins, but that editors should not wait for that, and that someone should end it manually, as soon as it is clear the discussion has run its course. Did I misread the policy? — Guarapiranga☎ 11:39, 31 May 2022 (UTC)
The point is that RfC is not an instrument of first resort. We get far too many people reaching straight for RfC as if that were the only way of holding a discussion, and if you look at WP:RFC/A you'll see that there are a great many ongoing RfCs, many of which really don't need to be. First collect your information and demonstrate your case - for instance, how often is the form ((na|text=—)) used instead of the simple ((na))? When people have used the simple form, did they change their mind and alter it to the |text= form? - so have many people asked for this template change in the past? --Redrose64 🌹 (talk) 12:33, 31 May 2022 (UTC)
The point is that RfC is not an instrument of first resort. I see. If that's the case, perhaps this needs to be explicitly spelled out in WP:RFC (just as you wrote it, Redrose64). I'm happy for you to close this RfC, if you see fit. Cheers. — Guarapiranga☎ 02:55, 2 June 2022 (UTC)
Support much easier to read. Happy Editing--IAmChaos 20:57, 1 June 2022 (UTC)
Comment. ((na)) and ((ya)) are meant to be used together in the same tables, to contrast with one another. So, I think this proposal will break that logic. 1745 articles use((na)), and at first glance I think the proposed change will break most of them. It may be that you came across uses of ((na)) that were not following its original intent. Maybe in these cases ((sdash)) would be more appropriate? If so, then these articles need to be fixed to use the appropriate template. --Fernando Trebien (talk) 19:58, 3 June 2022 (UTC)
Apologies, Fernando, you're absolutely right. I meant ((n/a)). Thanks for the correction. — Guarapiranga☎ 06:16, 4 June 2022 (UTC)
Although the documentation of ((n/a)) does not specify what meaning of N/A is implied, we can perhaps assume that it is commonly understood as not applicable based on its redirect ((not applicable)) and the manual of style. Probably should be documented, for clarity. I believe it wouldn't make much sense to change how the template is rendered if this is a commonly understood abbreviation in English-speaking countries. We could change the template to wrap the text using ((abbr)) to help clarify it for readers. Then, articles using it for the other meanings (not available, not assessed and no answer) could use ((sdash)), or ((unknown)), maybe even ((no attempt)) instead. We could also create templates for these three other meanings to ensure clarity. --Fernando Trebien (talk) 12:26, 4 June 2022 (UTC)
Yeah, no, N/A is widely used and widely understood in the anglosphere; it's not an issue of clarity, but of readability. A table in which many cells are marked N/A is just too busy and polluted. The emdash (—) is also widely used and widely understood to mean the same in English RS, as well as in other languages, and conveys the same msg more cleanly, if not more clearly. — Guarapiranga☎ 05:42, 5 June 2022 (UTC)
N/A means that the information is not available and could be replaced with ((sdash)) (a quick way is to use an external text editor and perform a text replacement, then preview and verify the results):
Brazil at the Olympics: used for the columns First and Second medals when no medals were awarded, and also for Best finish when nobody finished the event
N/A means different things and should be adjusted differently in each case:
List of former TV channels in the United Kingdom: ((yes)) is used to represent that the channel was available; some of those cells have an EPG number as described in the lead, but some are empty, meaning that color is the only information there, which goes against the accessibility guidelines; so ((yes)) should be replaced with ((ya)) and then it would make sense to replace ((n/a)) with ((na))
Hillerød Fodbold: I don't know enough to judge everything, but some of the uses of ((n/a)) there could be replaced with ((dunno)) (eg. columns Avg. Home Attendance, Top goalscorers, League for the oldest records), others with ((sdash)) because they mean not avaliable (eg. Refs), while leaving ((n/a)) where it really means not applicable (maybe League in some of the middle entries if the league system had changes in those particular years)
Unicode font: since ((yes)) and ((usually)) are used to aid in judging the degree of support, ((n/a)) could be replaced with ((no|0))
The following is a closed discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review after discussing it on the closer's talk page. No further edits should be made to this discussion.
– The current name of the template is miscapitalized. "Not applicable" can be abbreviated as N/A or n/a, but never N/a. InfiniteNexus (talk) 17:01, 5 September 2022 (UTC)
... this is just because the first letter is case insensitive and coincidentally displays as an upper case N. What a waste of time. Izno (talk) 18:07, 5 September 2022 (UTC)
Well, I would have moved it myself, but it's template-protected. My request at WP:RM/T a while ago was also contested, leaving an RM as the only option. InfiniteNexus (talk) 18:34, 5 September 2022 (UTC)
Comment the current name of this template is ((n/a)). So according to the nominator, it is already located at the correct location. (Note: ((n/a)) and ((N/a)) are the exact same pagename). If you want to fix the displayed title, then just add ((lowercase)) to a noinclude section -- 64.229.88.43 (talk) 04:51, 6 September 2022 (UTC)
Oppose per 64. Just use the lower-case display-title template; clearly "n/a" was intended here. — Ceso femmuin mbolgaig mbung, mellohi! (投稿) 03:33, 8 September 2022 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Semi-protected edit request on 15 November 2022
This edit request to Template:Nonfree has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
Would it be possible to add a class of "notheme" to this template? (In addition to the existing classes "yes table-yes2")
This will improve some presentation issues with Dark themes in our mobile apps, where we explicitly strip away background colors from certain table cells. The "notheme" class prevents the background color from being modified, and will not impact presentation on other platforms. Dmitry Brant (talk) 15:14, 15 December 2022 (UTC)