Template talk:CheckElement

This template is supported by WikiProject Elements, which gives a central approach to the chemical elements and their isotopes on Wikipedia. Please participate by editing this template, or visit the project page for more details.ElementsWikipedia:WikiProject ElementsTemplate:WikiProject Elementschemical elements

Chemistry

This template is within the scope of WikiProject Chemistry, a collaborative effort to improve the coverage of chemistry on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ChemistryWikipedia:WikiProject ChemistryTemplate:WikiProject ChemistryChemistry

Physics

This template is within the scope of WikiProject Physics, a collaborative effort to improve the coverage of Physics on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.PhysicsWikipedia:WikiProject PhysicsTemplate:WikiProject Physicsphysics

Removal of old symbols

I notice that the older symbols have been removed. Have all pages using the element and nuclide templates that reference these been changed over? Gah4 (talk) 02:37, 2 March 2017 (UTC)[reply]

The family of five templates check for unknown id (symbol, name). If unknown, the article is categorised: Category:Chemical element unknown (0). The former symbols like Uus are also 'Unknown' today, they are removed from the internal templates' list. This category is empty, so there are no errors in articles (mainspace). Good.

But not in other namespaces: Category:Pages with incorrect nuclide templates use (4) (including your sandbox). This category is not complete (does not check all five templates this way), so there could be more non-mainspace pages. I happen to know that all these pages listed are about those new element symbols (because yesterday, the category was empty).

Does this help? Should we check all non-articles listed? -DePiep (talk) 07:36, 2 March 2017 (UTC)[reply]

It seems that there are examples on how not to use some templates, which causes them to appear. Looks close enough for me. Gah4 (talk) 16:34, 2 March 2017 (UTC)[reply]

You're right, the examples now are listed too (and even the template themselves for having no input). That is because yesterday I opened up that error-categorisation as wide as possible to catch any errors. So we know article space is OK. Do you want me to refine those other hits? (reduce number of trivial reportings?) Or is 'close enough' meaning 'OK as it is'? -DePiep (talk) 18:06, 2 March 2017 (UTC)[reply]

How often does Category:Pages with incorrect nuclide templates use (4) get updated? I suspect some have been fixed, but are still there. But yes, 'close enough' means OK as it is. I don't remember now which page(s) caused me to add those back, but it didn't seem worth ruining all the pages without giving people time to fix them. I got started on this working on tables for fission products and activation products. (Which don't have these high atomic number elements.) I then found a bug in some of the templates that had Mr where Mn should have been, and wrote the test in my sandbox to be sure that there weren't others. Looks pretty good to me! Gah4 (talk) 18:18, 2 March 2017 (UTC)[reply]

A day, maybe two (article categories hours). Is my inpression; we cannot enforce speed and patience is a friend. Priorities: 1. articles should be perfect. 2. you should be able to work useful in sandbox & testpages. Can you? From what I saw (glanced), your sandbox does messages & tests OK. Dunno about the fission checks. 3. Visual cleanups, empty a category to show super control. -DePiep (talk) 18:59, 2 March 2017 (UTC)[reply]

I learned about ?action=purge working on this, as changing a template doesn't immediately affect pages that it is used on. But I don't think that works for this one. I will check again in a few days. Gah4 (talk) 21:55, 2 March 2017 (UTC)[reply]

You need something tricky (?action=purge&forcelinkupdate=1) to purge and update categories. I have done that, but the problems remain. Johnuniq (talk) 01:38, 4 March 2017 (UTC)[reply]

Do I understand, Johnuniq, that this would speed up new categorising (after a template change)? Or is it just upodating the category page, listing pages are they are processed (JQ) at the moment? -DePiep (talk) 09:29, 4 March 2017 (UTC)[reply]

The following example generates the error category, despite nocategory=true.

{{Nuclide |Blabla |nocategory=true}} → The element Blabla does not exist.

Previewing the above in an otherwise blank sandbox shows the hidden error category at the bottom. This talk page was not in the category before I posted the above, but it will be when I save. If that can be fixed, I think Category:Pages with incorrect nuclide templates use will clear (after the tricky purging which I can do later). Johnuniq (talk) 01:38, 4 March 2017 (UTC)[reply]

OK I'll look into this. Nothing broken so far, just incorrect. -DePiep (talk) 09:29, 4 March 2017 (UTC)[reply]

One of the problems was that {{CheckElement}} did not report an error when you provided an invalid element name. I fix this, so now you get only one error message instead of a bunch of them. The root cause of the original problem appears to be that not all of the helper templates properly pass "nocategory" along, which they did not need to because {{CheckElement}} should prevent them from ever being called with invalid arguments. But just to be safe, I've tried to make sure all the helper templates handle "nocategory" correctly. Furthermore, the doc suggest you could use {{#expr:{{CheckElement...}}|OK|ERROR}}, where it should be {{#if:{{CheckElement...}}|ERROR|OK}}.

Some examples:

{{CheckElement|Neon}} →

{{CheckElement|blabla}} → The element blabla does not exist.

{{#expr:{{CheckElement|Neon}}|OK|ERROR}} →

{{#expr:{{CheckElement|blabla}}|OK|ERROR}} → Expression error: Unexpected < operator

{{#if:{{CheckElement|Neon}}|ERROR|OK}} → OK

{{#if:{{CheckElement|blabla}}|ERROR|OK}} → ERROR

I'll fix the doc now. — SkyLined (talk) 14:00, 15 February 2018 (UTC)[reply]