Help talk:Template

Should administrative templates be translated?

I have coincidentally encountered a stub page (Яндекс Диск (Русский), now deleted) with wrong localized title, which was marked for deletion using a localized template, Template:Deletion (Русский). This was obviously wrong, because the page was not listed under Special:WhatLinksHere/Template:Deletion, which is the list which is systematically checked.

I admit that localized "administrative templates" can be useful for coordinating the effort of a translation team, and having English messages on localized pages might be considered ugly, but there are considerable downsides in splitting the Special:WhatLinksHere by language this way.

Another step deeper, maybe we should put together a list of templates that should not be translated?

-- Lahwaacz (talk) 19:59, 10 September 2014 (UTC)

I think what you're saying makes sense (and a lot) only for Template:Deletion; the admins (like any other user) can't expand, merge or update articles written in languages they don't speak, right? :) What other templates were you thinking about? -- Kynikos (talk) 10:43, 11 September 2014 (UTC)

True, every other article status template could be used in localized form by the maintenance team. Regardless, there will always be fragmentation of the Special:WhatLinksHere: for example when fulfilling the requests, it is common to use English message (and template) on localized pages if the editor does not speak the language. This should be definitely considered by the translation teams.

Personally, I find it strange that outdated or inaccurate content from English pages can be spread by translation (see [1]).

-- Lahwaacz (talk) 11:36, 11 September 2014 (UTC)

About the first point on "fragmentation" of WLH pages, do you mean that it inevitably happens that some localized articles are marked with localized templates and some with English templates? In what cases is it possible that somebody adds a status template to an article without being able to understand its language? And if (s)he does, is that really the right thing to do? And if it is, maybe we could recommend to use the localized version of the template even if the message is then written in English?

About the second point on template "spreading", I don't find it "strange" if it happens when somebody translates from an article that is marked with such status template: he's adding the localized template not only to remind to the team that the article contains outdated content, but also to notify all non-contributing readers about possible inaccuracies. But maybe I haven't understood what you meant exactly?

Just to come back to the original topic, isn't it a good thing that the WLH pages for the English status templates are not (ideally) "polluted" by non-English articles? (Doesn't apply to Template:Deletion, I know)

-- Kynikos (talk) 14:33, 12 September 2014 (UTC)

For example when fulfilling ArchWiki:Requests, there is often some unique keyword or phrase to identify the relevant section, even in localized pages. Google translate can be used to partially understand the surrounding text, even if the translation is grammatically incorrect. This makes it pretty easy to mark the section with English message (translating the message from English would be risky, the grammar mistakes might alter the meaning), which I think is an improvement (any warning should be better than none). Using a localized template in this case would require checking if such template exists, and even if it does, combining localized template and English message is even more weird.

About fragmentation and using localized article status templates generally, its advantage is that it filters out other languages in the WLH lists, but this only partial (the global list will always contain some localized pages, unless we want to create the necessary templates for each language and do some mass cleanup, and the localized lists will not point out localized pages marked with global templates). The disadvantage is that global maintenance, if only marking as outdated as per ArchWiki:Requests, will be harder.

-- Lahwaacz (talk) 21:51, 12 September 2014 (UTC)

Ok, of course each solution has pros and cons (will we need a summary table for this issue too?): honestly I wouldn't find it too weird if a localized template had an English message, which could also be translated afterwards by somebody else. Yes, adding a localized status template requires a bit more typing, sometimes even copy-pasting if there are non-Latin chars in the language name: this could be mitigated in the future by Help talk:i18n#Language namespace(s) in place of suffixes?; I understand this could effectively discourage adding status templates to translations. On the other hand, a bot would be able to convert the templates to the proper localized versions very easily, so that's a task that could be performed periodically (it could be used to check also other templates). And yes, having a translated version for each template would be required if we enforced such a policy. Finally, let's not forget that localized templates would be more useful to casual readers than English templates.

-- Kynikos (talk) 05:03, 14 September 2014 (UTC)

About the template spreading, it is safe to assume that Template:Poor writing will never be translated. Instead, the translator will probably fix the English article prior to translating it, which is happening a lot, even when the style issues are not marked with a template, and this is absolutely great. On the other hand, I have never noticed any other article status template being resolved during translation. Admittedly, sometimes it is best to just translate the inaccurate content along with the template, or the translator might be unable to resolve it, but in terms of statistics I think that I should have noticed at least some effort by now.

-- Lahwaacz (talk) 21:51, 12 September 2014 (UTC)

Well, Template:Poor writing does have a translation already with some backtransclusions, I'm not sure if you'd delete it (I wouldn't). -- Kynikos (talk) 05:03, 14 September 2014 (UTC)

As the discussion about other article status templates is getting slightly off-topic, let's take a list of one item for now, Template:Deletion. How do we mark it as non-translatable? The translated versions could then be redirected to the English template and deleted when there are no backlinks. -- Lahwaacz (talk) 22:01, 12 September 2014 (UTC)

I think the EAFP approach is better in this case, I can think of 2 implementations:

1. Create a redirect for each Template:Deletion_(Language) title and protect them from editing with an exhaustive justification in the summary (this solution would A) be more consistent with the usage of the other status templates and B) allow us grouping the backtransclusions of Template:Deletion by language in its WLH page).
2. Redirect the existing translations temporarily, convert them all with a bot, then delete them and finally protect all the Template:Deletion_(Language) titles from creation with an exhaustive justification in the summary.

I prefer 1), do you agree/disagree or have additional options?

-- Kynikos (talk) 05:08, 14 September 2014 (UTC)

Template "nowrap"

I would like to ask for opinions about adding a wiki template like Wikipedia's "nowrap".

Although there are already some alternative solutions available for specific cases (e.g.   for non-breaking space, ‑ for non-breaking hyphen), the "nowrap" template (and/or other similar templates) covers additional cases.

For example, you might find one line of text presented as ending with the word package and the same sentence continues in the next line, presented as starting with (s). By using the "nowrap" template on this expression, you get package(s) all together, either at the end of one line or at the beginning of the next one, but never separated in 2 lines.

This is just an example. Other cases can be (more) relevant (too). Obviously, the "nowrap" template can also be used instead of (multiple) non-breaking spaces and non-breaking hyphens.

Without a "nowrap" (or similar) template, the alternatives are either to not care about these things, or to use one of the following (please note that some alternatives might be more appropriate than others):

<span class="nowrap">This text will not wrap.</span>
Some sentence... <span class="nowrap">package(s)</span> and the sentence continues.

<span style="white-space:nowrap">This text will not wrap.</span>
Some sentence... <span style="white-space:nowrap">package(s)</span> and the sentence continues.

The "nowrap" template also has some "alias" (or redirection) names in Wikipedia, or we could use a new different name for this same template.

Is this kind of situation worth a template for the ArchLinux wiki? Any thoughts? Ady (talk) 15:39, 27 March 2016 (UTC)

I don't know, it seems a bit overcomplicated to me... What browser are you using that wraps "package(s)" at the parenthesis? At least Firefox correctly interprets it as a single word, since I do believe that these cases should be handled by the browser. The same goes for e.g. "package-s". Can you give more examples where this template would be needed (and would be a clearly better solution than using non-breaking spaces etc.)? — Kynikos (talk) 06:57, 30 March 2016 (UTC)

Hmm, perhaps I have not used the best example - I know I have seen this "package(s)" example somewhere, but currently I cannot recall where / when exactly.

I should point out that users could see an unwanted (word) wrapping, depending on the width of the wiki text area (e.g. screen resolution, web browser's zoom, fonts...).

As for "better" (or common) examples, please see [2] for brevity.

BTW, using space characters and hyphens are the (most) common word-separators in certain languages, but not in all of them (e.g. CJK languages), so a "nowrap" template might be even more helpful in some translated wiki pages than in the English ones.

I want to be clear. I am also not completely sure this type of template is "essential" for the ArchLinux wiki. It is potentially helpful; the question would be whether it is worth it. Ady (talk) 02:51, 31 March 2016 (UTC)

I see, I should have been more specific, but what I meant with "more examples" is existing samples of the ArchWiki (in any language) where such template would improve the page rendering and/or the source text. To put it in other words: after creating the template, where exactly is it going to be used?

In general I'm against creating templates (or Categories, etc.) "just in case they come in handy one day", although in this case I admit the idea can make somewhat sense, so if you really feel you want to create the template, I won't object further, maybe somebody else will find good uses for it and we'll start appreciating its existence ^^

— Kynikos (talk) 03:23, 31 March 2016 (UTC)

I am a contributor to other wiki sites (in addition to the ArchLinux wiki). As editor(s) of wiki text, it is usually recommended to be aware that readers might use very different setups. While I/we might not see a certain behavior in the presentation of the wiki text / page, others might.

Although the ArchLinux wiki would not (need to) consider older versions of web browsers (or web browsers being used in non-Linux OSes), I am used to test the results of my editions with at least a couple of different setups.

I found a web page about word wrapping in HTML that might be of interest to (some) wiki editors. Some notes about it:

• Most of its content mentions Internet Explorer, but it also mentions Firefox, Opera and others.
• In theory, it is somewhat outdated (at the time of this writing, its last update was during 2013).
• In spite of its date, I am convinced that at least some of the issues are still relevant (with potential improvements and regressions in each new version / variant of web browser).
• The part of that web page that is relevant to our discussion here is that there are several alternative methods so to achieve the desired wrapping result, whether it is about preventing word-wrapping, imposing word-wrapping, or allowing optional wrapping at certain specific positions within an expression / word.

Some of the simpler alternatives, (probably with a varying degree of effective results):  , ‑, , ⁠, wbc, and for generic wiki text, a "nowrap" (or, one of its alias names, "nobr") templates.

The advantage of a "nowrap" template over its non-template alternatives is that it is more generic; editors can avoid having to use different tricks according to the specific character (space, hyphen, minus sign, em/en dash...) and it covers potential cases that have no alternative or that would make the source of the wiki text less-readable.

So, without a "nowrap" template, I guess that most of the relevant cases in Latin-like languages would be covered by some non-template alternative, or by using the full "span style expression". Although perhaps there might be some cases in which a "nowrap" template would not have an alternative in Latin-like languages, I am also guessing that such (few?) cases would probably not be worth a template in the ArchLinux wiki.

But then there are the CJK languages, in which wrapping styles / rules might be more important / complex than some form of "hyphen" and/or space characters.

Maybe User:Fengchao and/or other members that are fluent in CJK languages might have a different / relevant perspective?

— Ady (talk) 13:40, 1 April 2016 (UTC)

Forum link

Moved from Talk:Bash/Functions -- Alad (talk) 11:13, 23 October 2015 (UTC)

The article has two types of forum links:

• BBS#30155 (intro, as in Template:Bug) and
• https://bbs.archlinux.org/viewtopic.php?id=101010 (section #Kingbash)

Which one is right again? --Det^talk 11:44, 24 July 2015 (UTC)

Full URLs should be avoided, see Help:Style#Hypertext_metaphor, otherwise I know of no recommended wording for forum links. -- Alad (talk) 12:13, 24 July 2015 (UTC)

That section doesn't actually even talk about external links, while Help:Editing#External links says "just type the full URL", but also that "it is often more useful to make the link display something other than the URL". --Det^talk 16:04, 24 July 2015 (UTC)

This was already mentioned somewhere some time ago, I don't remember where nor when, anyway [3] would seem to justify the creation of a Template:BBS, just like we have Template:Bug. — Kynikos (talk) 15:18, 25 July 2015 (UTC)

The problem with a BBS template is that links to the full thread have simple query string ?id=number, whereas links to posts have ?pid=number#number. There would have to be two different templates, which would get confusing very quickly.

There are more problems with existing links to the BBS: from looking at the list you posted, there are many links specifying the page number in the query string (p=num), but FluxBB has variable/configurable number of posts per page. The links should point to either the full thread (first page), or a specific post.

-- Lahwaacz (talk) 15:31, 25 July 2015 (UTC)

Like with links to bugs, a bbs url has to be pasted and manually modified anyway, but most of the times the conversion to Template:Bug ends up being done by a bot, which would be able to use two different BBS templates appropriately.

I see 5 types of viewtopic.php links:

1. ?id=number: these could be changed to Template:BBSid instances.
2. ?id=number&p=number: when number is 1, they could drop it and use Template:BBSid; otherwise they should point to a post as you say and use a Template:BBSpid template (we could publish a list of such links for manual fixing, since the correct post has to be found by a human, a bot can't do it).
3. ?pid=number: these could be changed to Template:BBSpid instances, the link fragment is the same as number with a prefixed p, so it's easy to add using the same template argument.
4. ?pid=number#pnumber: these could be changed to Template:BBSpid instances, number needs to be specified only once.
5. ?t=number: these seem to be all broken, so they should be marked as dead, or fixed.

I've chosen Template:BBSid and Template:BBSpid instead of e.g. Template:BBSthread and Template:BBSpost thinking that it would be easier to get their relation to the url when used manually, but I'm still quite undecided (provided that we actually decide to introduce the new templates).

— Kynikos (talk) 04:27, 26 July 2015 (UTC)

3. and 4. are identical (btw. haven't you confused their descriptions a little?), except that 3. only opens the page with the given post (based on the user's posts-per-page setting), but stays at the top of the page, whereas 4. points directly to the post (the #pnumber is the trick to do it). So 3. should also never be used, but it's trivial to transform it to 4. -- Lahwaacz (talk) 09:50, 26 July 2015 (UTC)

Of course, I was reasoning from a bot's point of view, which would indeed see 3. and 4. as different cases. My description of 3. was assuming that the need for a fragment was obvious (hence the mention of how easy it is to add it even if it's not in the original link), but what's important is that you seem to have understood anyhow :P — Kynikos (talk) 10:44, 26 July 2015 (UTC)

I agree on using only PID and ID. If you're linking to a page, you most likely should link to a PID. To distinguish between both, you could use ## for PID and # for ID.

I don't have suggestions on automating the implementation. -- Alad (talk) 11:18, 23 October 2015 (UTC)

New Template Application

I was thinking a new template could be added for application pages that would give quick info on a package. It would be right floated like "related articles". I made a quick example here: User:Meskarune/package but it could use more work on the format/syntax. Meskarune (talk) 20:17, 23 January 2017 (UTC)

I don't see the point of this. You want to know the package name? Look in Installation. The website and description? Should be linked in the intro. systemd service, user & group and man pages should be under Usage. Config paths & examples under Configuration. –Larivact (talk) 05:43, 2 January 2018 (UTC)

The point of the sidebar table is that people will not have to go searching through lots of text for important information. If you only want to quickly know the service file and config file on Arch without reading through all the text on the wiki it would be in an easy to find place. Obviously its just some extra "eye candy" if you will that people could choose to use.

The larger issue I was trying to address was the lack of strict standardization for pages on packages.

The idea is that the content, and specific order of sections for package pages should be standardized with certain sections being required. For example, install and configuration. This will increase the quality of package pages on the wiki and enable scripts to be able to automatically mark issues such as lacking an install section. This isn't just about a template for a table, it is about having more specific standards for package pages as well in order to help people write them easier and increase over all quality and decrease maintenance time.

My proposal is that the example page I wrote should be the standard format for all pages on packages on the wiki.Meskarune (talk) 19:39, 9 August 2018 (UTC)

If you want to find out services / configuration files / man pages of a package without reading an article, you can just grep pacman -Ql for /system/, /etc/ and /man/. Your sidebar duplicates information and would thus increase the cost of maintenance (unnecessarily so). We already have standard sections. I don't think that we need to require some sections / have a strict order for all standard sections. We don't need a dedicated example article, we got enough actual articles to serve as an example. --Larivact (talk) 05:06, 10 August 2018 (UTC)

I put together code for the info box: https://wiki.archlinux.org/index.php/User:Meskarune/Template:application first time writing a template, it was a good learning experience if anything else. I originally got the idea from wikipedia info boxes.

Anyways, I don't propose that the info box be required for every package page, but on certain ones it would be very useful, for things like web servers, email servers, etc it is very common for people to go to the wiki page first, then go to upstream docs/bug trackers after, so having a small list would be helpful, and I think if people want to add them to such pages, the maintenance is not much since upstream doesn't often change. As for man page links, I often have the arch wiki on my phone while doing things on a computer without a GUI, and it is honestly useful to have man page links so its easier to read something on a phone while doing something in a TTY. I don't know how common that use case is, but I can't be the only one. It would also be useful for people who are visually impaired because finding links in text is difficult with a screen reader, and voice commands on phones are better than they are on linux.

And as for the "standard sections" in the style guide, "installation" wasn't even on there until you added it after this discussion started. (and I am grateful you took the time to do that) Part of the reason for my original suggestion of having more standard sections was because there was a lack. I also still believe that having certain sections required for packages will increase quality and consistency of the pages over time and lower maintenance because scripts can automatically tag any page under category:package if it is lacking installation or configuration. But that is of course up to y'all to decide about that. I really don't have the time/energy to argue about this if no one else thinks more standardization is a good idea.Meskarune (talk) 23:39, 11 August 2018 (UTC)

[Moved from ArchWiki talk:Administrators#Package page style guide/template. --Larivact (talk) 13:07, 9 August 2018 (UTC)]

I wrote a style guide/example template for package wiki pages. I wanted to get some feedback on it and possibly see if this couldn't be adopted as a standard on the wiki. This is the page: User:Meskarune/package

Maybe a wiki template could be created for the application info table sidebar thingy, this way it is faster/easier to add.

I think this would help improve the quality of package pages and help users get useful information faster. --Meskarune (talk) 20:37, 8 August 2018 (UTC)

Creation of package search templates

We have got Template:Pkg, Template:AUR and Template:man but package searches are still linked using external links, e.g.:

[https://www.archlinux.org/packages/?q=thunderbird-i18n language pack]
[https://aur.archlinux.org/packages/?K=android-platform- older versions]

I am therefore pondering whether we should create {{Pkg?|foo}} → PKG?foo and {{AUR?|foo}} → AUR?foo.

Pros:

• readers can identify package search links just by looking at them
• dedicated templates make the markup more readable and semantic

Cons:

• it further complicates Help:Reading#Formatting

While Template:AUR? already exists it's deprecated and produced "Template:AUR?", so there should be no problem in changing it.

The question is if it's worth it to create two templates for ~35 pages. What do you guys think?

--Larivact (talk) 08:15, 20 May 2018 (UTC)

It can be worth it, but how easy would it be to use the template, compared to the current link-like usage? You've taken your examples out of their context, Thunderbird and Android, but there they are naturally inserted with an alternative link label, and as far as I remember this happens pretty much everywhere a package-search link is used.

Perhaps this hypothetical template should still allow - if not even force - an alternative label (I don't like the PKG?foo rendering too much anyway), but then in that case why not create dedicated interwiki links instead? We can do it easily from Special:Interwiki.

-- Kynikos (talk) 15:49, 22 May 2018 (UTC)

If the links require an alternative label, wrapping it with a template does not make much sense. Also, there are so few of such links and still there are similar cases that would require a manual link - e.g. the language pack links in Firefox#Installing which link to the pkgbase listings. -- Lahwaacz (talk) 16:50, 22 May 2018 (UTC)

What about the following interwiki prefixes?

aur → https://aur.archlinux.org/packages/$1
pkg → https://www.archlinux.org/packages/$1

--Larivact (talk) 08:03, 24 May 2018 (UTC)

So now you want to replace the Template:Pkg and Template:AUR templates with interwiki links? That does not address the package search problem, unless you're about to write [[aur:?q=foo]]. It would also remove the special formatting of the package links, so that's no from me. -- Lahwaacz (talk) 09:30, 26 May 2018 (UTC)

I obviously don't want to replace Template:Pkg and Template:AUR. I left out the query parameters to make it flexible.--Larivact (talk) 09:47, 26 May 2018 (UTC)

In that case the purpose of the interwiki links would not be well defined, the ?q= string (which is an implementation detail) would have to be written manually on every page, and the alternative label would have to be used to make the link less ugly. Anyway, templates are much more flexible than interwiki links so let's either use templates or interwiki links which are as simple as possible. But before discussing the implementation details, we should agree on whether the use case is worth the effort or not. -- Lahwaacz (talk) 10:52, 26 May 2018 (UTC)

Given the relatively limited number of applications, I wouldn't go as far as adding another template to our toolbox, but an interwiki link is such a simple thing that as I said I'd be in favor of setting up.

I wouldn't like "flexible" interwiki links either, however, I'd rather go for:

aur → https://aur.archlinux.org/packages/?K=$1
pkg → https://www.archlinux.org/packages/?q=$1

So the examples in the OP would become:

[[aur:android-platform-|older versions]]
[[pkg:thunderbird-i18n|language pack]]

I'm not 100% sure about the prefixes though, I wish we could use aur? and pkg? or similar...

-- Kynikos (talk) 17:09, 26 May 2018 (UTC)

I meant the question is if it's worth doing it some other way instead of using the external links. External and interwiki links look the same and with the alternative label interwiki links don't save as much typing (one could even say that the URL, which is not very long in this case, can be copy-pasted completely which makes it easier to use). There are also other similar cases (like the pkgbase links above) which would require external links anyway. -- Lahwaacz (talk) 22:08, 26 May 2018 (UTC)

Well, of course I don't have a mathematical answer to that question, I can only say that interwiki links look neater to me in the source text, and since those search URLs are resources directly provided by Arch Linux, it makes sense to me to give them a shortcut, but yeah, more than a typing advantage it's a personal aesthetic preference over which I won't argue much more than this :)

Just to complete my reply, the full links could still be copy-pasted from the rendered pages; copy-pasting when editing the source text shouldn't be affected, because if you want to create a similar type of link, it doesn't matter if it's in the interwiki or the external-link form, although interwiki links are easier to just type than copy-paste. Interwiki links for split packages would be less useful and easy to use indeed.

Also, about the rendered looks, I want to remind that if we want we can specifically style (standard) package-search links however we like, whether they are created with external or interwiki links, but in the latter case we can target them specifically thanks to the extiw class.

-- Kynikos (talk) 15:23, 27 May 2018 (UTC)

Creation of Template:Info

I think we have got enough articles about GNU software to warrant a template for Info manuals, analogous to Template:man.

gnu.org hosts HTML Info manuals for apparently most GNU packages, generally in the form of https://www.gnu.org/software/package/manual/html_node/node.html.

I created User:Larivact/drafts/Template:Info as a draft, only to realize that gnu.org replaces spaces with dashes, meaning, like Template talk:Hc#hc breaks in lists, this template would require mw:Extension:StringFunctions.

--Larivact (talk) 11:21, 15 August 2018 (UTC)

Not only that, it also encodes characters like dashes: [4] -- Lahwaacz (talk) 11:47, 15 August 2018 (UTC)

Well spotted, so:

' ' -> '_'
'-' -> '_002d'
'/' -> '_002f'

should cover most cases. --Larivact (talk) 12:13, 15 August 2018 (UTC)

And I guess every other "blacklisted" character has to be encoded as _ + 4-digit hex code... So what's the full blacklist?

As for StringFunctions, that's a dead-end solution.

-- Lahwaacz (talk) 12:47, 15 August 2018 (UTC)

It's not a blacklist it's a whitelist, anything not [A-Za-z0-9 ] is encoded, see [5].

Yeah Lua/mw:Extension:Scribunto would allow for more readable code and correct templates. --Larivact (talk) 13:06, 15 August 2018 (UTC)

I opened ArchWiki talk:Administrators#Scribunto. --Larivact (talk) 17:34, 18 August 2018 (UTC)

Creation of Template:Big change

We do not have any templates to indicate that articles are discussed to be restructured / rewritten. I think that a general big change template would help raise awareness of discussed changes and potentially get more readers to participate in the discussion.

Template draft

Examples of big changes up for discussion where the template could be used:

• Talk:Network configuration#Moving Ethernet-specific sections to Wired subpage
• Talk:Security#Scope
• Talk:List of applications#Scope of the page

--Larivact (talk) 19:17, 4 January 2019 (UTC)

We've been using other argicle status templates, especially Move/Merge/Remove/Style/Expansion, for these purposes. They raise awareness just as well and also have a semantic meaning. I don't think we need a "Big change" template. — Lahwaacz (talk) 19:22, 9 September 2023 (UTC)

More inline-style templates

I would like to create more templates for inline-flagging of some style problems, similarly to Template:Dead link or Template:Broken section link:

• Template:Avoid implicit link (for [[...|here]], [[...|above]], [[...|below]] etc.)
• Template:Avoid external link (for external links to Wikipedia, AUR packages etc.)
• Template:Citation needed or Template:Reference needed
• Template:Language register (could be used with arguments, e.g. {{Language register|too informal}}, {{Language register|avoid acronyms}}, etc.)

Some of them could be applied (semi)automatically with a bot. Maybe you can also think of more problems that could be marked similarly.

-- Lahwaacz (talk) 10:25, 23 February 2020 (UTC)

I don't see much need for Template:Language register since it would usually apply to whole paragraphs or the entire article instead of some phrase/word as Template:Dead link. I think Template:Style fully covers that case. I'm also somewhat skeptical of a bot's ability to apply it accurately, but maybe I'm mistaken about that.

I do like the other proposed templates. I think Template:Citation needed/Template:Reference needed in particular would be very useful. It could ease the burden when flagging questionable claims, unlike Template:Expansion or Template:Accuracy which require a detailed "reason".

-- nl6720 (talk) 14:27, 23 February 2020 (UTC)

I think Template:Language register would be useful for phrases explicitly mentioned in Help:Style#Language register, e.g. "at the time of writing". They occur frequently and using Template:Style is usually an overkill, especially if the phrase appears inside a note or a list. -- Lahwaacz (talk) 15:33, 23 February 2020 (UTC)

Simpler alternative (possibly too simplistic): make only one new generic inline Style template, and clarify the reason with its argument case by case. Of course it will mix all cases together in its WhatLinksHere page, but so does Template:Style. -- Kynikos (talk) 15:47, 16 March 2020 (UTC)

I wouldn't like to add too much text to inline templates, because the wikicode would become too chaotic. Even {{avoid implicit link}} is shorter than {{inline style|avoid implicit link}}, and the former can even include a link to the relevant section in Help:Style. -- Lahwaacz (talk) 09:59, 21 March 2020 (UTC)

No worries, I'm fine either way, maybe you can only start with the templates that can be applied with a bot, since for a human it might be just equally easy to directly fix links, acronyms, abbreviations etc. than flag them with a template. -- Kynikos (talk) 11:31, 21 March 2020 (UTC)

Suggest using user page sandbox

Everyone using Template:Sandbox has following disadvantages:

• Only one user can edit it at a time.
• Breaks previous drafts and talks.

Instead of everyone using Template:Sandbox I propose suggesting to copy whole template to User:Exampleuser/Template and testing there. Also you can test template without saving the page, which you can't do on already created template page.

Template:Template and Help:Template#Creation would need to be updated, possibly first should link to latter instead of Template:Sandbox. Instead of creating template in main namespace instructions should suggest creating it in user page, then start new discussion on Help:Template to introduce it to the wiki.

-- Svito (talk) 00:12, 13 May 2020 (UTC)

If people move or archive or delete their personal sandbox page, the drafts and talks will break anyway. And there were not many cases in the past where multiple users wanted to edit the template sandbox at the same time. Using just one template sandbox is good in at least one way: it helps to push things forward faster, because otherwise it would block other things. -- Lahwaacz (talk) 08:39, 13 May 2020 (UTC)

Only admins can delete pages. And only users that were breaking our draft templates were User:Larivact which quit wiki and myself which I stopped doing because its pointless and because it breaks old talks. I don't see how Template:Sandbox helps push things faster. Obviously you would only save new version of template if you wanted to discuss it with other editors (which by default is slow because you have to wait for other people), and for previewing any non-existent page on wiki is faster, because you can preview without saving. Also if you want to draft many templates you should create Template:Sandbox2 and the like, which User:Kynikos did and bloats our template space (why not name it Template:Command if we decided we allow creating draft templates in main template namespace), which we use to figure out optimal amount of templates we wish to maintain and update. -- Svito (talk) 16:41, 13 May 2020 (UTC)

My main point as long as you need at least 2 different version of same or different templates, Template:Sandbox is not good enough. Other option would be just have resulting html directly inside draft pages, which is even uglier and harder to update without using extra tools like sed. -- Svito (talk) 16:45, 13 May 2020 (UTC)

I've thought about this a little, it may make sense to me, how would you patch Template:Template and Help:Template#Creation? I've moved Template:Sandbox2. -- Kynikos (talk) 16:41, 19 May 2020 (UTC)

Introduce partial and optional table cell templates

Usages of {{Y|Partial}} and {{Y|Optional}} are common on the wiki, would be handy to have optional link to be specified inside template in same way as Template:Yes and Template:No: {{Partial|url}} instead of {{Y|[url Partial]}}. -- Svito (talk) 19:24, 13 May 2020 (UTC)

I don't know, Yes and No have become kind of historical templates, but I'm not sure how beneficial it can be to create even more specializations of the color templates, after all tables like Arch boot process#Feature comparison would then end up mixing Partial with Y, which could be argued to further confuse the source text, for only a minimal reuction in typed characters. -- Kynikos (talk) 16:47, 19 May 2020 (UTC)