Template talk:R from Unicode character

Categorization

If you look at Category:Redirects from Unicode characters you'll see that each character is categorized under its own title. Can a change be made to this template so that it categorizes them all under the same title? It would be easier on the eyes, and for navigation. -- œ^™ 13:34, 29 December 2011 (UTC)

Looks like the tilde (~) sort grabbed all of them except for six symbols at the very end. – PIE ( CLIMAX )  08:08, 16 February 2012 (UTC)

I took care of those six. I also added a table of contents that makes more sense for this category. Gorobay (talk) 03:58, 17 February 2012 (UTC)

Excellent! I added a TOP as in other TOCs. I've also taken the liberty to use that TOC in Unicode's parent: Category:Redirects from symbols. Your code is now in template form at {{Category TOC symbols}}. – PIE ( CLIMAX )  17:59, 18 February 2012 (UTC)

Bad code?

To editor Wbm1058: Where is that error again? I sandboxed the code and tested it at here at %, but I don't see a transcluded error. – Paine  23:46, 3 July 2014 (UTC)

I patrol for errors using these links:

• Pages transcluding {{error}}s
  • in main namespace
  • in talk namespace
  • in file namespace
  • in category namespace

You'll see that % shows up at the top of the main-namespace link. I think the only one that is supposed to be on that list (in the first 50) is Icelandic alphabet. I recall that being there before and have not taken the time to debug it. The others you can make go away by doing null edits (unless they use the sandbox). Wbm1058 (talk) 23:57, 3 July 2014 (UTC)

For some background on this, including some examples of how I fixed other templates with this issue, see Template talk:Requested move#template:error. Wbm1058 (talk) 00:28, 4 July 2014 (UTC)

I found the code in the sandbox that caused the error; however, all the code did was to produce its own error when the rcat tags a redirect in any other namespace besides mainspace and project namespace. This whispers to me that there may be a problem with {{Error}} if it doesn't show any kind of error box or message on the redirect, and it shows it's "mysteriously" transcluded. Something's up – let me make some checks. (Also found several "Unicodes" here in project space.)– Paine  01:01, 4 July 2014 (UTC)

Okay, Wbm1058, how well-versed are you in the Lua module code? The challenge seems to lie in the new, beta version of the {{Category handler}} template. I tested the old template wikimarkup in the Template:Category handler/sandbox (check Template:R from Unicode/sandbox) and the old markup does not produce the errors you found. It's only when the beta version of cat handler, which uses Module:Category handler, is transcluded to the rcat sandbox that the error is generated. Can you fix this? (I am Lua code-poor, myself) or should we seek help? – Paine  08:32, 4 July 2014 (UTC)

Also, there is the possibility that the actual problem lies in the Namespace detect module or its data page, which are called by the cat handler beta module. – Paine  08:59, 4 July 2014 (UTC)

PS. (This may be unlikely, though, since the cat handler sandbox also calls these.)

PPS. It may save some time to mention that I tried a workaround by use of cat handler's 2nd parameter, i.e., I set 2={{IRT|[[WP:Mainspace|main]]|[[WP:Project namespace|Wikipedia]]}} and other=2, but that also generated the error you found. PS & PPS left by – Paine 

Since the category handler template and module have been stable since last October, I doubt that they are the problem here. Looking at this diff the problem would seem to be in the highlighted text that was removed, more specifically I see that template:Incorrect redirect template can transclude {{error}}s, so I think that's probably the template that needs to be fixed, or something is transcluding {{Incorrect redirect template}} when nothing is incorrect. Wbm1058 (talk) 16:03, 4 July 2014 (UTC)

FYI. Someone fixed Icelandic alphabet. Wbm1058 (talk) 16:38, 4 July 2014 (UTC)

Yes, the IRT uses {{Error}}, but it is only called when the rcat is used to tag a redirect in any other namespace than main and project. It is not called if the redirect is in one of those two namespaces. You don't think it's suspicious that the sandbox version of the cat handler, which has the old template wikimarkup code, works just fine and does not return the error, but the new beta version that invokes the module does return the error? – Paine Ellsworth ^CLIMAX! 20:36, 4 July 2014 (UTC)

Oh, I see. I confirmed that. Let's try asking for help. Wbm1058 (talk) 14:53, 5 July 2014 (UTC)

@Mr. Stradivarius: Paine has found a difference in behavior between the old template:category handler and your new module. See this diff. Can you check how the module is processing the other parameter when a template transclusion (Paine's new template:Incorrect redirect template) is part of the parameter? Thanks, Wbm1058 (talk) 14:53, 5 July 2014 (UTC)

@Wbm1058 and Paine Ellsworth: Sorry, what? I'm afraid I don't quite understand what the issue here is. All parameters are expanded before they are passed to Lua, so it doesn't matter if a template transclusion is part of a parameter. All Lua sees is the expanded wikitext. I gather that something is happening with Module:Category handler that didn't happen with the old Template:Category handler, but I'm not sure exactly what that is. Can you point me to an example, or construct a minimal test case for me if you have managed to pin down the issue far enough? — Mr. Stradivarius ^{♪ talk ♪} 15:18, 5 July 2014 (UTC)

@Mr. Stradivarius: Use % for the test case. It is currently using {{R from Unicode/sandbox}}. Just do null edits to that, and see whether it appears at the top of this list. When template:R from Unicode/sandbox uses template:Category handler/sandbox (the old pre-module version) it does not show up at the top of the list, but when it uses template:Category handler (with the module), it does. Why is that? Wbm1058 (talk) 15:31, 5 July 2014 (UTC)

Hi, Mr. S. – I found that the {{R from Unicode}} rcat, which uses the cat handler to cat in the main and Wikipedia namespaces, was not showing an error box in the other namespaces to let editors know not to tag redirects in those namespaces. I tested the {{Incorrect redirect template}} in the "other=" param to generate the error box and to sort those redirects to Category:Pages with templates in the wrong namespace. After tests, I applied the change to the live template. Wbm1058 caught an error while monitoring this page. Scratched my head several times and found that somehow the cat handler module allows those errors to occur in both the main and Wikipedia namespaces, but with no other error indication on the redirects themselves. I put the cat handler's previously used template code in the cat handler sandbox and found that the template code works as it should. I used the % redirect to test this. When the cat handler's sandbox is used in the Unicode rcat, the % redirect disappears from the Error template's transclusion-list page. If I go back to the cat handler module (erase /sandbox from the Unicode rcat), then the % redirect reappears on the Error template's transclusion-list page. Something does seem amiss with the way the cat handler module's "other" param is behaving. Since I am still Lua-poor, I am unable to pinpoint the error in the module code, which might actually be generated elsewhere from an associated source. In any case, we are unable to use the Incorrect redirect template in the live Unicode rcat, because that would just fill up the Error template's transclusion-list page – again. The Unicode symbols that are now on that list can be erased by null edits. Help! – Paine Ellsworth ^CLIMAX! 16:07, 5 July 2014 (UTC)

(edit conflict) Ok, I've found the cause. So basically, we are calling category handler with code like this: {{Category handler|1=Some category|main=1|other={{Error|Error we don't want to be transcluded.}}}} Following the logic through in the old Template:Category handler, the "other" parameter never gets expanded. This is thanks to User:David Göthberg's elegant and economical template design, which only uses parameters if they have to be used. Unfortunately, my module isn't so clever, and all the parameters get expanded right at the start with the code starting on line 274:

    for k, v in pairs(origArgs) do
        -- ...
    end

This means that parameters are expanded in the Lua whether or not they are actually used to generate the template output. And it is the act of expanding the "other" parameter, not the act of showing it in the module output, that makes it labled as a transclusion. This can be fixed, but it will require re-engineering of the module, so don't expect it to start working overnight. I'll try and look at it when I next have a chance. — Mr. Stradivarius ^{♪ talk ♪} 16:33, 5 July 2014 (UTC)

Wha? It's not re-engineered yet? – Paine 

Okay, I'm sure you're aware of this – I see two instances of that code:

    for k, v in pairs(origArgs) do
            origArgs = frame.args
            break
    end

and a bit further down:

    for k, v in pairs(origArgs) do
        if type(v) == 'string' then
            v = mw.text.trim(v) -- Trim whitespace.
    end

Since I don't have line numbers, I don't know to which of these you refer. I had wondered if it might be just a matter of the inclusion of one more line, as in:

        if type(k) == 'number'
            or k == cfg.nocat
            or k == cfg.categories
            or k == cfg.subpage
            or k == cfg.page
            or k == cfg.other

But I really don't have a clue, do I! Might mean that you have a fairly teejus job of configgin' ahead?– Paine  18:08, 5 July 2014 (UTC)

It's the second one, although there is a chance that the first one will expand the "other" argument depending on which one is listed first in the template invocation, so I'll rewrite that as well. The basic fix for this is to switch the module to use Module:Arguments, which allows the arguments to only be expanded when necessary. The main algorithms shouldn't need to be changed, although I will have to go through and check them. The thing is that I've also had a request that the title blacklist matching should be cached per page rather than generated for every #invoke, and the test cases need rewriting too. It's best to do all of these at once, but it isn't a small job. — Mr. Stradivarius ^{♪ talk ♪} 02:15, 6 July 2014 (UTC)

@Wbm1058 and Paine Ellsworth: I've rewritten Module:Category handler to fix this error and to make it more efficient - have a look at Template talk:Category handler#Update to the module. Testing the % redirect, the issue now seems to have disappeared. — Mr. Stradivarius ^{♪ talk ♪} 02:32, 8 July 2014 (UTC)

Can't thank you enough, Mr. S! Regarding the tests at Module talk:Category handler/testcases, can we assume that the green check marks to the left indicate a pass, and that the only time the two right columns might have entries are when one or more tests fail? Thank you for all your work on this! For me, it's like watching an astronaut perform an EVA with the Earth's curvature in the background. I have no idea what he or she is doing, but I'm thoroughly impressed with the procedure and outcome. I'll be happy to re-introduce the error code to the Unicorn rcat as soon as you enliven the module with the sandbox code you wrote. Again, thank you for all this; I believe I'm beginning to get a very fundamental and basic inkling of Lua. – Paine  09:07, 8 July 2014 (UTC)

You're welcome. :) And you're right about the test cases; the second and third columns only display anything if there is an error. That's so that if there is an error, it's easy to tell at a glance what and where it is. — Mr. Stradivarius ^{♪ talk ♪} 11:19, 8 July 2014 (UTC)

Related?

To Mr. Stradivarius – I just noticed this anomaly and wonder if it's related to the above? I checked this rcat on several types (namespaces) of redirects and it works just fine on redirects, but for some reason that large red-print "error"(?) appears in the alphabetical index. – Paine  07:08, 18 June 2015 (UTC)

@Paine Ellsworth: This is what happens when you have more than one DISPLAYTITLE parser function on the same page, and they don't have any noerror parameters. See here for the MediaWiki docs. — Mr. Stradivarius ^{♪ talk ♪} 07:11, 18 June 2015 (UTC)

Got it! Thank you very much and Best of Everything to You and Yours! – Paine  07:38, 18 June 2015 (UTC)

RFD

Many redirects of this kind are recently discussed at RFD. 2602:306:B8E0:82C0:C57C:A2C7:42EA:556A (talk) 02:34, 13 July 2015 (UTC)

What is this template for?

@Paine Ellsworth: This template says it is for “a single Unicode character to an article or Wikipedia project page that names the character and describes its usage”. Category:Redirects from Unicode characters says it is for “redirects from single Unicode characters”, without further qualification. So which is this template for? This came up at Talk:비. Gorobay (talk) 00:48, 10 August 2016 (UTC)

Sometimes the categories give only "skeletal" explanations and other times they give more information than the rcats. I have added the |to= information to the category's page. The correct answer is now given by both the rcat and the category page. Thank you, Gorobay, for catching and questioning this!  Temporal Sunshine Paine  01:08, 10 August 2016 (UTC)

I had thought the point was to list all code points that were redirects. Since it is not, I have another question. Why is it useful to maintain a list of redirects to articles about characters that excludes single-character redirects like הּ and 🇨🇳 just because they use multiple code points? Gorobay (talk) 02:23, 10 August 2016 (UTC)

Well, I'm not sure I know the answer to that Gorobay. Your first question remains up in the air, though, because while making a perhaps feeble attempt to improve this rcat, I added the "to" statement back on 2 July 2014 with this edit. You know far more than I do about Unicode and this type of rcat, so if you think that the "to" statement is wrong or needs improvement, then by all means please make it right. Or let me know here what it should say and I'll change it, so it won't appear to others as if you molded it to your own suiting. In the mean time, I shall try to make it a more general statement.  Temporal Sunshine Paine  17:39, 10 August 2016 (UTC)

The problem is that there are single-character redirects that do not link to an article that names the character and describes its usage. So they do not fit into the category, nor is the template correct for them. As Gorobay mentioned above, 비 is a case in point. So are many, many of the "emoji" characters. 🍽 redirects to table setting, and 🌎 redirects to Earth. Those articles don't even mention symbols, much less Unicode. — Gorthian (talk) 03:08, 11 August 2016 (UTC)

I've removed the "that names the character" part that I had inserted without knowing the extent of the need to categorize other symbols. While the symbols might not actually be mentioned in the target article, they should at least be described or inferred by the target, as is the case with 🍽 and 🌎. Therefore those two redirects should be sorted to Category:Redirects from Unicode characters. The 비 redirect is perhaps more iffy? Is it just one symbol? Is it two symbols used together? I would have to leave that up to others more knowledgable than I am.  Temporal Sunshine Paine  03:32, 11 August 2016 (UTC)

It's just one symbol, Korean for "rain", I believe. It's listed as his stage name in the target article. — Gorthian (talk) 04:51, 11 August 2016 (UTC)

That being the case, I believe that it is correct to tag it with this rcat template in addition to {{R from alternative language|ko|en}}.  Temporal Sunshine Paine  07:10, 11 August 2016 (UTC)

Further explanations?

Why is the last statement even there?! "Not to be confused with {{R from Unicode}}"... But this is {{R from Unicode}}, isn't it?! o.O -- 5.12.215.243 (talk) 10:10, 13 November 2018 (UTC)

Collation and categorization

This template gives redirects sort keys of “~” for Category:Redirects from Unicode characters, and {{Category TOC Unicode}} uses that convention to provide table of contents entries for each Unicode block. However, the block links no longer always work: it appears that, since 2012, categories have become sorted using Unicode collation, instead of sorting in Unicode code point order. This is good for most purposes, but it is more useful for the category of Unicode characters to be sorted by code point. Is there any magic word to change a category’s collation system? If not, I propose that this template sort by the following.

{{padleft:
  {{#ifeq: {{ASCII code|{{PAGENAME}}}} | 32
  | {{anchorencode:{{PAGENAME}}}}
  | .{{#invoke:Hex|d2h|{{ASCII code|{{PAGENAME}}}}}}}}
|12|.00}}

That sorts a single character by its percent-encoded UTF-8 bytes (except using dots instead of percent signs) padded to the maximum encoded length of any character. Gorobay (talk) 18:24, 20 October 2017 (UTC)

Template-protected edit request on 3 January 2019

Replace

[[Category:Redirects from Unicode characters|~]]

with

[[Category:Redirects from Unicode characters|{{padleft:
  {{#ifeq: {{ASCII code|{{PAGENAME}}}} | 32
  | {{replace|{{urlencode:{{PAGENAME}}}}|%|.}}
  | .{{#invoke:Hex|d2h|{{ASCII code|{{PAGENAME}}}}}}}}
|12|.00}}]]

per the previous section. Gorobay (talk) 19:58, 3 January 2019 (UTC)

 Not done: please make your requested changes to the template's sandbox first; see WP:TESTCASES. Cabayi (talk) 11:02, 4 January 2019 (UTC)

I’ve made the change in the sandbox and tested it in ,, ¢, and 🌐. index.php?action=raw&templates=expand shows that each gets the expected sort key. Once the sandbox has been copied and pasted over the template, I will fix those three test redirects. Gorobay (talk) 17:08, 5 January 2019 (UTC)

 Done Please update the documentation as necessary. Cabayi (talk) 11:22, 6 January 2019 (UTC)

Suggested categorization change

{{#invoke:BaseConvert|convert|n={{#invoke:ustring|codepoint|\{{PAGENAME}}}}|base=16|width=6}} would work better than the current system for finding the hexadecimal representation. The current system yields strings like .00.00.C3.85 (å) normally but .00.00..0025 (%) for printable ASCII. This is inconsistent and breaks sorting; the suggestion above yields 000025 for %, 0000C5 for å, and 01F373 for 🍳. Six digits are the maximum needed; Unicode extends up to 10FFFFF. User:GKFX^talk 18:03, 26 March 2021 (UTC)

Template-protected edit request on 1 April 2021

As described in the section above with no complaints, please make the following change: [1]. It ensures that all items in the category sort consistently. User:GKFX^talk 15:55, 1 April 2021 (UTC)

To User:GKFX:  done, and thank you for your input! P.I. Ellsworth  ed. ^put'r there 17:19, 1 April 2021 (UTC)