Jump to content

Module talk:Convert/Archive 1

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
< Module talk:Convert
This is an old revision of this page, as edited by ClueBot III (talk | contribs) at 03:01, 30 October 2013 (Archiving 8 discussions from Module talk:Convert. (BOT)). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.
Archive 1Archive 2

Notes

This module provides an implementation of {{convert}}. See the documentation.

Usage examples:

  • {{convert/sandboxlua|5.2|m|ftin}} → 5.2 metres (17 ft 1 in)
  • {{convert/sandboxlua|5+3/8|in}} → 5+3⁄8 inches (140 mm)
  • {{convert/sandboxlua|1|yd|2|ft|3|in|hand}} → 1 yard 2 feet 3 inches (15.3 hands)
  • {{convert/sandboxlua|60|x|120|m|ft}} → 60 by 120 metres (200 ft × 390 ft)
  • {{convert/sandboxlua|1|e12BTU/cuft|e9kJ/L|lk=on}} → 1 trillion British thermal units per cubic foot (37×10^9 kJ/L)

The testcases show good agreement between the templates and the module. There are some minor rounding and other differences, and the only significant disagreements appear to be problems in the templates. Substantive differences occur at:

  • energy2: different default output for in.lbf
  • energypervolume: template problems
  • exhaustemission: template problem
  • length2: different micro sign (should be "µ" U+00B5, not "μ" GREEK SMALL LETTER MU U+03BC)
  • mole: different micro sign
  • power: calorie disagreements
  • time: module cannot handle unit horse year (unit not used)
  • torque: template problems and minor differences
  • volume: template hectolitre problems
  • misc: module cannot handle units note, spanner, wrench (units not used)
  • options: template problems and minor differences
  • options2: template problems and minor differences
  • spell: minor differences

The module appears to correctly implement the main features of the template. There are some minor disagreements concerning rounding of results, and some units and options have not yet been implemented. More testing is needed. Johnuniq (talk) 10:52, 26 April 2013 (UTC) Updated 09:56, 19 July 2013 (UTC)

Discussion

Some interesting performance challenges exist. The "NewPP limit report" in the html source for this test page says "Lua time usage: 0.295s". Johnuniq (talk) 09:35, 19 February 2013 (UTC)

presuming that a page that requires data conversion might require many of them, and consideing the sheer size of Module:Convert/data, you might want to look at the mw.loadData documentaion and see if you can use this to improve performance. peace - קיפודנחש (aka kipod) (talk) 16:45, 2 March 2013 (UTC)
Mentioned at http://test2.wikipedia.org/wiki/User:Johnuniq -- WOSlinker (talk) 17:13, 2 March 2013 (UTC)
Thanks, but this page is a little out of date, and I will update it with the info that WOSlinker linked to. My comment about "performance challenges" was written when I had not absorbed the fact that some testcase timeouts were due to use of frame:preprocess. It actually looks as if Module:Convert is reasonably fast, although I haven't yet hammered it. In my sandbox, there are 122 calls of {{convert/sandboxlua}}, and the HTML source shows the Lua time usage is 0.348s (2.8 ms per call). That makes me think that Lua is fast enough even with the current bloated modules. Nevertheless, I'm thinking of some ways I could improve performance and will update the "Plans" section above with info, possibly within a few hours. Johnuniq (talk) 04:08, 3 March 2013 (UTC)

I've removed the plans as they were obsolete. Also, while the testcase pages require a significant time to render, the convert module appears to be sufficiently fast, so there is no reason to look for ways to speed it up. I now have 1689 calls in my sandbox, and the Lua time usage is about 1 millisecond per convert. There is a per-page overhead, and it looks like a small number of converts takes around 40 ms total. Johnuniq (talk) 10:52, 26 April 2013 (UTC)

Status?

I'm curious what the status is here, and when you might hope to be ready for deployment, etc.? Dragons flight (talk) 02:13, 6 June 2013 (UTC)

Yes, I've been wondering that too! I believe there are no significant problems: there are some minor rounding differences between the outputs from the template and the module, and some klunkiness where I'm not happy with the result of some combinations of options, but those same options cause the template to fail, so I do not know of anything significant. However, I've still been doing large refactoring, and I need to wait a week after I decide to stop that before moving towards deployment. The item currently at the top of my todo list is the fact that Unicode minus ('−' U+2212) is accepted with the precision (as in {{convert|123|mi|km|−2}}), and I'm wondering whether to support that. The module accepts Unicode minus and &minus; with the input value, but the function for that does a bunch of other stuff so I would need to replace a simple tonumber(x) with yet another function. I'll also spend a couple of days doing some docs, and see if anything turns up in that process. My guess is that in about a week or two I'll ask for opinions on the next step. Deployment would show other problems, for example, there would probably be quite a few unusual units that I have not implemented. Johnuniq (talk) 03:17, 6 June 2013 (UTC)
Some real-life issues caught up with me, and I haven't done any convert work for the last week and a half. I'm just slowly getting back to it. Johnuniq (talk) 03:36, 21 June 2013 (UTC)
My excuse this week is that I have got into a quagmire trying to adapt the module to work properly on bn: (Bengali Wikipedia; anyone interested may like to follow my links). The unit names and so forth are pretty easy to handle, but lots of the code depends on the numbers using English digits, and it will take some time to work out how best to handle translations. Johnuniq (talk) 03:25, 28 June 2013 (UTC)
It turns out that there is quite a lot of tricky stuff involved. The code should now be ok, but I'm still working with some editors there on getting the unit symbols and names fixed. Johnuniq (talk) 11:16, 5 August 2013 (UTC)

Extra units

Following is a quick test of a new module (Module:Convert/extra) showing how temporary units can be created without significant overhead.

Module:Convert/extra should be transcluded into only those pages which refer to a unit that is not defined in Module:Convert/data. Johnuniq (talk) 11:16, 5 August 2013 (UTC)

I have inserted subst: into the above to freeze the results as they were at the time of this comment. The units were just a temporary experiment (which can be seen in this permalink), and I will remove them soon. Johnuniq (talk) 04:52, 14 August 2013 (UTC)

parameter warnings=true

If I am correct, there is a parameter |warnings= that can be set to |warnings=true (see User:Johnuniq/Using the convert module#Module problems). If set, it should fill Category:Convert invalid option (when an errors occurs).


I cannot check the category filling, because I do not know how to force an "invalid option" error. A hint anyone?

Some tests:

  • {{Convert/sandboxlua|5|km|mi}} → 5 kilometres (3.1 mi)
  • {{Convert/sandboxlua|5|km|mi|warnings=true}} → 5 kilometres (3.1 mi)*
  • {{Convert/sandboxlua|5|km|mi|warnings=false}} → 5 kilometres (3.1 mi)*
  • {{Convert/sandboxlua|5|km|mi|warnings=foo}} → 5 kilometres (3.1 mi)*
  • {{Convert/sandboxlua|5|km|mi|warnings=}} → 5 kilometres (3.1 mi)*
  • {{Convert/sandboxlua|5|km|mi|foo=true}} → 5 kilometres (3.1 mi)*

I find this code confusing, because the parameter name "warnings" is used (checked) twice for apparently opposing values. The logic may be right, but clear it is not. 

local function add_warning(parms, mcode, text)
    if warnings then
        if parms.warnings == nil then
            parms.warnings = message({ mcode, text })
        end
    end
end

-DePiep (talk) 15:49, 19 September 2013 (UTC)

I hoped that the comments that are in the code would help:
-- If enabled, add a warning that will be displayed after the convert result.
-- To reduce output noise, only the first warning is displayed.
The warnings variable is set from the configuration:
warnings = boolean(args.warnings) -- true if want warnings for invalid options
The line "if warnings then" tests if warnings are enabled.
The line "if parms.warnings == nil then" means only the first warning is displayed (if there already is a warning, parms.warnings will be set, not nil). That is to reduce clutter that would appear in an article if malformed input was given. As I just commented above, a new list of messages is here, and it includes some warnings. Johnuniq (talk) 03:14, 20 September 2013 (UTC)

I've had time to investigate the above interesting bug where using "warnings=true" causes "true" to be appended to the result. Module:Convert includes the following code: 

    -- The wikitext with the final result is set (not shown here).
    wikitext = ...
    -- If any warnings have been generated, they are appended.
    if parms.warnings then
        wikitext = wikitext .. parms.warnings
    end

The problem is that the parms table contains what the user entered, and because the convert contains "warnings=true", the module sets parms.warnings = true. That is then appended, and Lua helpfully converts the Boolean "true" to the string "true". I'll think about making that more robust. Johnuniq (talk) 06:29, 20 September 2013 (UTC)

Don't explain it, code should be self-explaining. Just don't use the same name twice. It is bad programming practice. -DePiep (talk) 14:07, 20 September 2013 (UTC)
That's an interesting issue which has been widely debated. At one time I used to make all my variables unique (check my user name!), mainly because I hated searches that gave false hits, although I was inclined to also agree with the "bad programming practice" sentiment. But then namespaces became fashionable and I had to adapt, and now can't see a problem with similar things having the same name. Johnuniq (talk) 00:24, 21 September 2013 (UTC)
The problem is confusion, as I said. For the reader, it is an extra mental step to keep them apart. That is, if the reader realizes a difference. They are not always mentioned in each others vicinity. (About mental steps: after studying (not reading) I discovered that 'mcode' means message code. I do not see why it would not be like msgcode to be clear a day earlier). -DePiep (talk) 09:17, 21 September 2013 (UTC)
(And prefix 'cvt' as in 'cvt_bad_sigfig' probably means message too). -DePiep (talk) 09:22, 21 September 2013 (UTC)
I hear you, but I will offer a suggestion that applies to most code that I write: search the module to see if "mcode" is used somewhere else where there might be an explanation. I know that's not answering you, but it is a practical suggestion that will help in my code perhaps a quarter of the time. Re "cvt_": I wanted a unique prefix so that all the message codes could be found with a search, and while "msg_" would have fitted that description, I picked "cvt_" because it is very easy to find reasons to use "msg" in a program, and conceivably also "msg_". The "cvt_" is to indicate a convert code (perhaps later I would have found reason for other kinds of codes, and used a different prefix for them). The first usage of "cvt_" in the module explains that it is a string used as a key to get message information. I remember your advice about "don't explain", and am mentioning all this to show my reasoning, not in the hope that you will agree.
I fixed the bug that used to be shown above when "warnings=xxx" is used in a convert. Johnuniq (talk) 10:09, 21 September 2013 (UTC)
Thanks for replying. -DePiep (talk) 12:29, 21 September 2013 (UTC)

boolean

The function boolean is wrong. It should return either "false" or "true", never nil. nil is not a boolean value. The input parameter called "text" can be a numerical value too, so is named wrong. No need to bend meanings. -DePiep (talk) 14:10, 20 September 2013 (UTC)

Option value should be "on" just as other such params have. No need to introduce "yes", "y", "1" as option value. -DePiep (talk) 14:24, 20 September 2013 (UTC)
It's true that my boolean function is self-indulgent as I have had to implement similar stuff on different systems where all the possible "true" values are required, however, it's perfectly valid Lua. The parameter is called "text" because it can only be a string, not numeric (it's not intended to be used from other modules where arbitrary parameters could be passed). Also, it's conventional Lua to not return anything for false, although I do feel unclean after doing that, and my more recent functions have tended to always return a value. I'll try to look around some other templates/modules to gauge what boolean option values are generally used, but we're talking about a pretty minor issue that isn't even used currently. One issue about only regarding "on" as true is error reporting—should the module report an error if the invoking template contains "warnings = yes"? Johnuniq (talk) 00:16, 21 September 2013 (UTC)
I trimmed the boolean function so it accepts only "on" and "yes". Johnuniq (talk) 10:11, 21 September 2013 (UTC)
OK then. Saves testing all these variants. -DePiep (talk) 10:59, 21 September 2013 (UTC)

Range with a negative

About writing a range of values that contain a negative value. Consider

  • {{convert|-8|-|-3|F|C}} → −8 – −3 °F (−22 – −19 °C)
  • {{convert/sandboxlua|-8|-|-3|F|C}} → −8 – −3 °F (−22 – −19 °C)

The minuses and dashes are formally correct in lua, but make awkward writing/reading. WP:MOSNUM gives this option:
If negative values are involved, an en dash might be confusing. Use words instead: −10 to 10, not −10 – 10.
The example would then look like: −8 to −3 °F (−22 to −19 °C). For ease of reading, 'to' should be used in both ranges, even when only one would have a negative. Ideas anyone? -DePiep (talk) 00:17, 21 September 2013 (UTC)

I agree that the en-dash-minus is ugly and should not be used, however I wanted to emulate the current templates as closely as possible (although there is a slight spacing bug in the current template, as shown above). If "to" is wanted, that parameter can be used:
  • {{convert/sandboxlua|-8|to|-3|F|C}} → −8 to −3 °F (−22 to −19 °C)
Johnuniq (talk) 00:29, 21 September 2013 (UTC)
Fair enough. Feature request, maybe later on. -DePiep (talk) 08:20, 21 September 2013 (UTC)

Testing process

Maybe Sure it looks like the code works great, but we cannot test it. This content is missing:

see → Template:Convert/sandboxlua/parameter options for improvement & completion
Started.
  • Template:Convert/doc/sandbox new documentation
  • exceptions, error & warning message overview
  • delta with old {{convert}} (deviant definitions, especially wrt old documentation; I do not point to the many clear & clean undisputed improvements)
What is the status of old documentation Template:Convert/doc#Parameters_still_under_construction?
  • Also I miss a sense of completeness & overview.

must say, some parts of the testing process are set up great, like template:convert/testcases and the (undocumented) module:ConvertTestcase. I am a bit frustrated now because I cannot even write a test! -DePiep (talk) 19:05, 21 September 2013 (UTC) Improved my wording. -DePiep (talk) 22:31, 21 September 2013 (UTC)

Here's an example test for {{convert|100|in|cm|disp=sqbr}}. You take the "100|in|cm|abbr=out|disp=sqbr" and change the | to ! and then pass it over to ConvertTestcaseGiven as below. -- WOSlinker (talk) 19:25, 21 September 2013 (UTC)

Script error: No such module "ConvertTestcase". Script error: No such module "ConvertTestcase". Script error: No such module "ConvertTestcase".

Thanks and used. Would it help if I build a status template/table with all involved files? Usually it helps me to get a grip. -DePiep (talk) 22:33, 21 September 2013 (UTC)

Test options

I'd like to build an overview here of the available test switches in the module. The actual situation in testing is not fully clear. I'll be bold, for clarity. And I have an opinion on them. This is what I found (as of 00:23, 22 September 2013 (UTC)):

  • warnings= 'on', 'yes'
Does: when set to true, the warning message is reported in line, and maintenance Category:Convert invalid option is added. The other categories contain errors, not warnings.
demo: todo
(trick to show: use {{convert/sandboxlua2}}; template #2 has set warnings=true)
The param must be set in {{convert}} (in the invoking template).
– No reason to have this set in the invoking template ({{convert}}). Set it in the module, as all tracking&message settings.
+ Proposed name: test_warnings
  • debug= 'yes'
Does: when set to yes, and |tablesort=on, it shows the sort key (usually hidden) for a table cell.
demo: todo
– Name too generic to describe its working.
– Should accept 'on' as other params
– (at least it should use procedure 'boolean')
+ Proposed name: test_show_sortkey
  • is_test_run=
Does:
data_module = "convertdata-" .. langcode
else ...
data_module = "Module:Convert/data" .. sandbox
code cmt: "-- A testing program can set the global variable 'is_test_run'."
– Note that langcode is part if the test)
– Not to warn the servers, but this global test variable is called each time.
– The code cmyt says nigh nothing
+ Proposed name: test_xxx, but only when fulfilling a proven need
  • sandbox= 'on', 'yes' (unchecked)
Does: when set true, and is_test_run=false (not set), subfiles Module:Convert/data, /text /extra get name addition into Module:Convert//data/sandbox &tc.
– "is test run" versus "sandbox" interaction - ouch.
+ Proposed name: test_use_sandbox (better: this way, get rid of it)
  • langcode=
Does: as show above with is_test_run=, langcode is involved with testcode. Only.
– I am lost here. What is this parameter doing here? Where does it come from?
+ Delete
+ Rethink the module for i18n (would 'on' be in module code really?). Before or after going live on enwiki?
For all test options

To proceed:
1. First delete and eliminate all test variables from test code (= code that should go live!). All of them. Clean start.
2. When all is re-thought, one can propose to re-introduce a test-switch.
3. There are no interacting test settings from start. Simple prescriptions. Preferably also not interacting with template parameters.
4. A new one will be named with prefix "test_".
5. Document all options of that one -- beforehand.
6. Then others will test and use that test switch.

Note

To be clear. Six settings, and interacting at that? I don't know what I am testing! All code in testcases should be fit for going live. No workarounds or shortcuts allowed (really, if we allow those, exactly what are we testing then?). Sure, in development time & space, everything is OK. That must be why the module is almost ready for going live. But in test space & time, only live code is allowed. There can be one switch only to be sure -- and that one is already called {{convert/sandboxlua}}. -DePiep (talk) 00:23, 22 September 2013 (UTC)

The sandbox param is useful. Once the module has gone live, {{convert}} would contain {{{{{|safesubst:}}}#invoke:convert|convert}} and {{convert/sandbox}} would contain {{{{{|safesubst:}}}#invoke:convert|convert/sandbox|sandbox=yes}}.
When updates are then needed to the module, it would then be possible to to copy the complete code from Module:Convert/sandbox to Module:Convert without needing to adjust any sandbox references each time. -- WOSlinker (talk) 00:46, 22 September 2013 (UTC)
Before discussing the above, I have to mention that what is visible here is the tip of an iceberg—I have a lot of data files and scripts that I have needed during development. To make it easier for me to do bulk changes, I'm still maintaining the units data in a tab-separated-values text file, and I run a script which generates the wikitext seen at User:Johnuniq/Conversion data. Once things have stabilized, my tsv file will be discarded, and the conversion data page will be the master. Before uploading code, I run a script which simulates the Scribunto environment, and which invokes my local copy of Module:Convert with over 13,000 converts. The test files contain expected results copied from Special:ExpandTemplates, and my test script compares those expected results with outputs from convert.lua. It does certain cleaning because exactly matching the expected output is pointless and impossible because there is too much variation between the outputs produced by the existing templates (stuff like whether a value and unit should be separated by a space or "&#32;" or "&nbsp;").
I want to make Module:Convert available for other wikis where severe problems using the templates have been seen. The module is live at the Bengali Wikipedia, and is installed at the Gujarati and Hindi Wikipedias—someone from gu asked for help porting the templates last February, so I put the module there, but it's a very quiet wiki and there is no interest, despite the fact that they have articles with broken converts (the user from last February has not been active). The module is very likely to be used at hi but translations will take time. I have four sets of files on a local computer—convert.lua is the same for all wikis, but convert/data and convert/text are different at en, bn, gu, hi (and convert/extra would be different if it were used). That's why set_config in Module:Convert tests is_test_run and uses it to specify the module names. Global variables is_test_run and mw are set by my test environment, and langcode is one of 'en', 'bn', 'gu', 'hi'. Results of running Module:Convert at bn can be seen at bn:User:Johnuniq/Translation—inputs can be in en or bn, and outputs are in bn, including the numbers (although we haven't got around to translating the input parameters like "abbr=on" yet).
The item at the top of my todo is to finish setting up the sandbox arrangement. WOSlinker has described my exact plan—there has to be a way to run sandbox testcases on the wiki, and a sandbox template would cause the sandbox modules to be used. I'm planning a system to run tests against a list of converts, each with fixed-text expected output. That is, the sandbox testcases would check the results against constant text (by contrast, the current testscases compare the results with live output from the existing template).
Specific answers to the points above are:
warnings: I'm happy to remove that and make the module always show warnings if local variable test_warnings tests true. But why "test"? I would be inclined to use "show_warnings". Also, I'm not confident about whether warnings really would be wanted, and so I made it a parameter of the template to allow an easy off/on switch. If others want warnings shown, that's fine by me.
debug: That's for compatibility with the existing templates and is just an optional parameter to a convert. Perhaps it's no longer needed, but it seems harmless. As a matter of interest, you could edit Module:Convert/text and change the line shown in the first of the following, to the second:
["debug"] = "debug",
["test_show_sortkey"] = "debug",
That would allow {{convert|123|mm|in|sortable=on|test_show_sortkey=yes}} to work. That feature is to allow translation of parameters at other wikis.
On reflection, I can't see debug at Template:Convert/doc, so perhaps I took it from {{ntsh}}? If the parameter is not needed, we can omit it, although I'll keep the code in the ntsh() function.
is_test_run: That's for my test system and I recommend ignoring it, despite its unusual nature. It's easy to see that it is totally benign.
sandbox: Needed for {{convert/sandbox}} per WOSlinker's explanation. The name could be anything, but the simple "sandbox" seems good.
langcode: It's a local variable with a scope of four lines, and is part of my test system so I can test expected results for various wikis in addition to en.
Johnuniq (talk) 04:22, 22 September 2013 (UTC)

New unit list needed

For the new module, we need a new list of units. It should accurately represent the units that the module handles, and their propoerties, so it better be derived from the same source: User:Johnuniq/Conversion data, possibly by an script adapted from Module:Convert/makeunits. The old list is Template:Convert/list of units, but we cannot trust that one for the module documentation. More features could be added. -DePiep (talk) 01:06, 22 September 2013 (UTC)

I know that the current conversion data page is far too complex for casual users of convert, but my intention was that it would be the master list for those with an understanding of the system. The overriding advantage of that page is that it is the actual data used for converts, and the complexity is just an unfortunate side effect of the mind-numbing complexity of the convert system (both existing and new). In many cases there are several unit codes for essentially the same unit, and that's for compatibility with the existing system, and the existing system is the way it is because editors have asked for various exceptions. What would help would be to draft a new "simplified" units doc page with just a few samples, similar to that used for the existing templates. How much detail should be included? If the format is reasonably consistent, I could write a script to extract the data wanted, using a list of wanted units as input. Another thing that would help would be a proposed index page with links to everything that users may want (possibly in two sections—one for those just wanting to use the template, and one with details).
BTW another todo item is to add an expression evaluator to makeunits so it can calculate the scale values from the expressions that appear in the unit definitions. Currently, makeunits uses a Lua command to evaluate expressions, and that command is not permitted in Scribunto, so makeunits cannot be run on the wiki. Johnuniq (talk) 06:29, 22 September 2013 (UTC)

Sandbox testing

I have created a new testing module so future changes to the convert modules can be checked against fixed expected results in the sandbox. The format of the data required by Module:UnitTests is too difficult when doing many tests, and it was fairly easy to adapt WOSlinker's Module:ConvertTestcase to read data in a simple format, and to compare the output of expanding templates against fixed expected text. See:

The new tester has not had much testing, but I'm fairly sure it would be useful for testing other templates unrelated to convert. The difficulty is that you have to provide the expected results, which must exactly match the output provided by the template under test. Because the new system does not have to expand the existing templates (which are very slow), it is possible to have a lot more tests. Using Module:ConvertTestcase, it is only possible to test about 110 results, whereas the new system is currently showing the results from 2,458 tests. The results all say "Pass" because the expected results are the outputs from the current module. However, some of those results are obviously wrong because they say "unknown unit", and there are many differences from the outputs produced by the existing templates (see the "bytype" tests at Template:Convert/testcases for a comparison between the module and the templates).

Now we need to make a master list of tests (and decide what the outputs should be), and keep that list as the standard which determines whether or not the module is working. Johnuniq (talk) 07:03, 24 September 2013 (UTC)

Category names

This is paraphrased from above in the hope that we can make a decision about suitable names for the tracking categories.

Module:Convert currently uses four categories:

Parent: Category:Convert error categories (not used by module, for category grouping only)

DePiep proposes that the following names be used instead, so that the names are plural to comply with WP:CATNAME, and are more descriptive.

Parent: Category:Pages with conversion messages

My opinion: A category is a list of pages so it's pointless putting "Pages with" in the name. For articles, we say Category:Living people or Category:1961 births. It's not Category:Articles about living people or Category:Articles about people born in 1961. I was also thinking that there was no logic in having "Pages with" at the start of all tracking categories, but on reviewing Special:PrefixIndex, perhaps there is a convention that "Pages with" means "tracking category", and using "Pages with" keeps the category names isolated from those used for articles? I will ask for opinions at WP:VPT about what names should be used. Johnuniq (talk) 11:56, 26 September 2013 (UTC)

  • I'm not sure if you are expecting responses here or at WP:VPT since you posted there pointing here, but I think that the category name needs to have something to define it as a tracking category. Whether that be
Parent: Category:Pages with conversion messages
or
Parent: Category:Conversion module messages
I really don't care. Technical 13 (talk) 16:40, 26 September 2013 (UTC)
If you do not care, Technical 13, then better stay away. -DePiep (talk) 23:15, 26 September 2013 (UTC)
I'm happy with the original names, but not that bothered if we end up with different ones. I do think that we don't need to include the word pages or articles in the names though. I've also added a reply over at WP:VPT to the general question of tracking category naming. -- WOSlinker (talk) 06:19, 27 September 2013 (UTC)
Well, at least the cat names should be plural, as cat names go. Next step would be to link errortype with cat with helppage (-link), the triangular fact. -DePiep (talk)
Adding: clearly the prefix "Pages with" is not needed (as the VPT talk shows). OK with this. -DePiep (talk)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Module_talk:Convert/Archive_1&oldid=579395960"