Jump to content

Module talk:Convert/Archive 1

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
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 − 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 " " or " ").
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)

Preserve unknown input unit

Per WOSlinker's above suggestion, I have made the module generate a fake input unit if the input is invalid (cannot be used as an input, or is unknown). Examples (two of these are valid to show what should happen):

It does not always give the optimum result, but it's close enough. (I added some more after fixing bug that occurred when no input is specified; my testing system is now fubar because it shows hundreds of bad results because I haven't yet updated my tests to account for the new message format.) Johnuniq (talk) 04:27, 30 September 2013 (UTC)

So "invalid unit" is distinguished from "unknown unit". From my readers pov I do not see the difference, but I can assume there is a sound background for it. -DePiep (talk) 21:47, 30 September 2013 (UTC)
It's not an unknown unit, it's just that you can do the conversion in that direction. e.g
  • {{convert/sandboxlua2|123|mi km|m}} → 123 mi km[convert: unknown unit]
  • {{convert/sandboxlua2|123|m|mi km}} → 123 m (0.076 mi; 0.123 km)
And that's because mi km doesn't make sense in the from unit but is ok in the to unit. -- WOSlinker (talk) 22:20, 30 September 2013 (UTC)

Before going live

Before going live we need more testing. All options, and all extremes (for example). Also we better test the border issues (like input '0'). -DePiep (talk) 22:35, 19 September 2013 (UTC)

The module code is chaotic. -DePiep (talk) 22:42, 19 September 2013 (UTC)
Yes please. More brutal testing would be good, and please let me know any good or bad findings. I guess you've seen User:Johnuniq/Using the convert module which has links to various tests, as well as a "roadblocks" section. I'll plead guilty to "complex", but I can't agree with "chaotic"! Johnuniq (talk) 10:36, 20 September 2013 (UTC)
I withdraw the 'chaotic' wording here because it is not helpful in any way. Whenever I would claim it, I'll have be more specific. On the need for testing we agree. -DePiep (talk) 06:55, 2 October 2013 (UTC)

Individual testcases

Will be ok then. But pleaze don't time press yourself. Don't promise. We are wiki, we have time. -DePiep (talk) 19:36, 22 September 2013 (UTC)
Resolved
 – In newly produced data file today. -DePiep (talk) 07:04, 2 October 2013 (UTC)
How nice your explanation. Next time you could reply like "got it, resolved" here to save some time (well spend elsewhere on wiki!). -DePiep (talk) 19:36, 22 September 2013 (UTC)

Simplifying the categories

Following is a summary of the problems caught by the existing categories. This ignores some "won't happen" errors (such as units with invalid definitions), and is slightly over-simplified (it ignores some rare but conceivable problems).

  • Category:Convert error
    Input number is missing or invalid.
    Ambiguous unit (X should be Y).
    Calculation error (very rare).
  • Category:Convert invalid option
    Invalid precision or sigfig.
    Empty or invalid option.
  • Category:Convert unknown unit
    Unit code is missing or is not known.
    Unit code is not valid as an input unit.
  • Category:Convert dimension mismatch
    Input and output units have different types.

As mentioned, I do not see any reason for having many categories, and I'm thinking the above should be simplified, and just two categories would be all that is useful.

Proposed new system (with exact category names to be determined):

  • Category:Convert error
    Input number is missing or invalid.
    Calculation error (very rare).
    Invalid precision or sigfig.
    Empty or invalid option.
  • Category:Convert invalid unit
    Unit code is missing or is not known.
    Unit code is not valid as an input unit.
    Ambiguous unit (X should be Y).
    Input and output units have different types.

With the new system, an editor would check "Category:Convert invalid unit" to fix unit problems, and would check "Category:Convert error" for problems with the input number or options. Thoughts? Johnuniq (talk) 12:18, 30 September 2013 (UTC)

Yes, seems sensible with just two. -- WOSlinker (talk) 12:29, 30 September 2013 (UTC)
Any ideas on the names? Johnuniq (talk) 12:42, 30 September 2013 (UTC)
I'm fine with those names, although some people prefer the pluralised versions; Category:Convert errors & Category:Convert invalid units. -- WOSlinker (talk) 13:18, 30 September 2013 (UTC)
I might change Category:Convert error to Category:Convert numerical errors. That last item listed under Category:Convert error, Empty or invalid option, should be moved to the other category and renamed to Invalid option – options are, after all, optional so an empty option should just be ignored. I am one of those who believe that an empty named parameter should have no meaning (same as if it isn't present).
I might change Category:Convert invalid unit to Category:Convert parameter errors as a catchall for any error that isn't numerical in nature.
—Trappist the monk (talk) 13:24, 30 September 2013 (UTC)
Thanks, I appreciate all the feedback on this page. However, I'm not sure about that last idea as I think the logical separation is syntax problems vs. unit problems. Editors with knowledge of the syntax can work on the first group, while the second group needs different attention. How about Category:Convert invalid options and Category:Convert invalid units? Each is plural and understandable, and reasonably accurate concerning what it covers, and there is no need to worry about the fact that the names do not really apply to some uncommon errors. Johnuniq (talk) 23:26, 30 September 2013 (UTC)
If I read the code well, there are also messages like: "Bug, ask for help.". If they are code & data issues (within the module pages), they could be in a separate category (#3) because a regular editor cannot solve that.
I prefer plural names.
Stretching the topic: did you consider giving each message an separate on/off switch? That would include categorizing the page, of course. Related, earlier talk: |warnings=on would be redundant. In testing time (like today) all can be on; when going live a smarter setting could be chosen for starters. -DePiep (talk) 10:37, 1 October 2013 (UTC)
Adding: Two (or three) cats is fine with me. -DePiep (talk) 10:40, 1 October 2013 (UTC)
I'd like to see the five "Bug, ask for help." messages in action (being triggered). They have no helppage section yet. -DePiep (talk) 12:37, 1 October 2013 (UTC)
I don't think the concept of switching messages on/off applies to convert. In CS1, and particularly when the messages were first switched on, it may make sense to decide to ignore a particular issue (that is, the code deals with it, but does not insert a message into the article). However, for convert, most errors are very significant and require attention. If an editor adds a broken convert, it is essential to show clearly (hopefully during preview) that something needs to be fixed. Some problems can safely be ignored, for example if the module finds "abbr=junk", it adds a warning and uses the default for the "abbr" option. Those messages (warnings) can be switched on/off, mainly because I'm not sure how many warning problems exist in articles. We'll need the experience of live usage to gauge how warnings should be handled.
Bug messages link to "Asking questions" which is the best that can be done. While a separate category might be used, I'm hoping the error categories will mostly be empty, so a separate category would have no useful function—indeed, it might be missed because only a couple of specialist editors would monitor a "bugs" category, and that category would be empty almost all the time. The first two examples at User:Johnuniq/Convert messages#New message format use a special option to force a bug message. I plan to remove that option in due course, although it's harmless as it only operates on the two units shown in the examples. Johnuniq (talk) 22:56, 1 October 2013 (UTC)
I can agree on the switch reasoning. No switch needed, cs1 differs. A single "show warnings" switch can stay, though since they do not spoil the page any more it could be 'on' from day one. anyway I am not afraid of 50k pages to check.
then there is this... As it is projected, all error templates are reported too -- at my suggestion as we know. This also means that all our testcase pages are reported. This way the categories likely never are empty. What to do?.
A separate bug category I'd still promote. Yes it will be empty mostly, but an interested editor is likely to check that one first: it's the alarm box! That editor should not spend time trawling through errors any editor can solve. I myself click two such alarming categories once a day. -DePiep (talk) 08:57, 2 October 2013 (UTC)

Message wikitext

It appears that we all like the appearance of the messages. Now I'm wondering what wikitext should be used to generate the message. Based on DePiep's idea, I took the wikitext from {{fix}}. Following is the wikitext for a sample sentence, followed by how that appears now, and its wikitext. Some alternatives are after that.

The box is {{convert|1|ft|junk}} wide.

#1 The box is 1 foot ([convert: unknown unit]) wide.
The box is 1 foot (<sup class="noprint Inline-Template" style="white-space:nowrap;">&#91;<i>[[Help:Convert#unit_not_known|<span title="Unit &quot;junk&quot; is not known">convert: unknown unit</span>]]</i>&#93;</sup>[[Category:Convert invalid units]]) wide.

#2 The box is 1 foot ([convert: unknown unit]) wide.
The box is 1 foot (<sup>[''[[Help:Convert#unit_not_known|<span title="Unit &quot;junk&quot; is not known">convert: unknown unit</span>]]'']</sup>[[Category:Convert invalid units]]) wide.

#3 The box is 1 foot ([convert: unknown unit]) wide.
The box is 1 foot (<sup>[''[[Help:Convert#unit_not_known|<abbr title="Unit &quot;junk&quot; is not known">convert: unknown unit</abbr>]]'']</sup>[[Category:Convert invalid units]]) wide.

Here is how the three alternatives look using sentence case (with some padding to experiment with line wrapping):

  1. xxxxxxxxxxxxxxxxxxxxxx yyyyyyyyyyyyyyyyyyyyyyyyyy zzzzzzzzzzzzzzzzzzzzzzz The box is 1 foot ([Convert: Unknown unit.]) wide.
  2. xxxxxxxxxxxxxxxxxxxxxx yyyyyyyyyyyyyyyyyyyyyyyyyy zzzzzzzzzzzzzzzzzzzzzzz The box is 1 foot ([Convert: Unknown unit.]) wide.
  3. xxxxxxxxxxxxxxxxxxxxxx yyyyyyyyyyyyyyyyyyyyyyyyyy zzzzzzzzzzzzzzzzzzzzzzz The box is 1 foot ([Convert: Unknown unit.]) wide.

The advantage of #3 is that the dotted underline provides a hint that a mouseover will show something useful. What wikitext should be used? Should the message be lowercase or sentence case? Johnuniq (talk) 23:24, 30 September 2013 (UTC)

I decided to try new link text and anchors and help page headings. I decided also to try sentence case, and just the two categories I mentioned in the previous section. I like the results at Help:Convert. I have stayed with style #1 above for now. Any thoughts on that? Should we try #3? Is it worth adding nowrap? Exactly what wikitext should be used? Johnuniq (talk) 08:03, 1 October 2013 (UTC)

I think that this use of the <abbr> tag is inappropriate. The tag has specific meaning in html other than for how it decorates text. Decoration is the province of css. You can get the same effect this way (I also changed the cursor):
The box is 1 foot ([Convert: Unknown unit.]) wide.
The box is 1 foot (<sup>[''[[Help:Convert#unit_not_known|<span title="Unit "junk" is not known" style="border-bottom:1px dotted;cursor:help">Convert: Unknown unit.</span>]]'']</sup>) wide.
I wonder about the no-wrap. Shouldn't the conversion and the error message both be no-wrapped? A new line shouldn't begin with the superscripted error message. So something like:
xxxxxxxxxxxxxxxxxxxxxx yyyyyyyyyyyyyyyyyyyyyyyyyy zzzzzzzzzzzzzzzzzzzzzzz The box is 1 foot ([Convert: Unknown unit.]) wide.
The box is 1&nbsp;foot&nbsp;(<sup class="noprint Inline-Template" style="white-space:nowrap;">[<i>[[Help:Convert#unit_not_known|<span title="Unit "junk" is not known">Convert: Unknown unit.</span>]]</i>]</sup>) wide.
—Trappist the monk (talk) 10:05, 1 October 2013 (UTC)
(edit conflict)
fix templates overview
a. I understand your desire to be more clear and descriptive, but the general page view says we better not distract too much from content. There is no need to point extra to the title (mousehover) text - in an uncommon way. The visible text should be clear enough (which it generally is now, especially with the prefix "convert:"). It should not depend on extra actions like hovering or clicking (see WP:ACCESS). Almost nowhere in content space we do that, not even in the fix superscripts. Now even the changing mouse (a ? mark appears) is puzzling me because I'm not used to that.
Idea: would it help if the title text corresponds with helppage sectiontitle? They both can be sentence-like, there is space. Must say, adding prefix "Convert: " to the title text could be an improvement, the supertext may be hidden behind it.
b. Adding nowrap: {{fix}} spans with style="white-space:nowrap; for the superscripted text. So even a longer text is nowrapped (for example, {{Failed verification}} produces [not in citation given], as used in ASCII_art). OTOH I find it reasonable & looking good that longer texts allow a break somewhere in the second half.
c1. wikitext: is it a good idea (and easy to encode) to leave out the () brackets? As for content, they are empty which looks strange (e.g., in printing=for the reader).
c2. I've read someone asking for "needs ..." not "need ..."; I support.
c3. Removing the final period looks good to me.

-DePiep (talk) 10:24, 1 October 2013 (UTC)

I thought a bit about the error message inside the brackets and decided that I liked it. It shows the editor that the error is in the convert-from or the convert-to side of the template call – in this case convert-to. Subtle, but will be obvious to editors once they notice it.
—Trappist the monk (talk) 10:41, 1 October 2013 (UTC)
(edit conflict)I like the new section headings better than the old.
Is there a reason why the error messages are terminated with a full stop? It does keep the last word of the italic error message from encroaching on the right-side bracket but the same can happen if the full stop is replaced wit a space:
The box is 1 foot ([Convert: Unknown unit ]) wide.
The box is 1 foot (<sup class="noprint Inline-Template" style="white-space:nowrap;">[<i>[[Help:Convert#unit_not_known|<span title="Unit "junk" is not known">Convert: Unknown unit </span>]]</i>]</sup>) wide.
—Trappist the monk (talk) 10:32, 1 October 2013 (UTC)
Thanks for the html info ... I'd better stick to Lua. Let's omit the dot and not have a space either: [Convert: Unknown unit].
OK, no underline decoration. BTW I just edited Help:Convert to insert a note at the start of each section telling the reader about mouseover, but I'm not sure about the reflist. Would someone please check it. It looks a bit strange with [a] and [b] in each section, and a blizzard of links in the Notes section. Is there a better way?
Yes, I think inserting "Convert:" before each popup title (in addition to its appearance in the superscripted text) would be good. Currently, the link text matches the help section headings, so the popup title need not also match, and if it matched too closely, it would be redundant.
I don't think there is any reason to omit the normal syntax like "( )" that a convert would display—we hope the converts will be fixed and the messages will not be a long-term fixture.
So the "Need" should be "Needs" in "Need a number" and "Need another number" and "Need unit name"?
Re wrapping of the convert: There is a long story behind that, and the current convert templates are largely designed (but are not always consistent) so that a plain space is used between a number and a unit name, but &nbsp; is used between a number and a unit symbol. In fact, there is a fairly new option (I think added by Wikid77 to at least some converts) called adj=j which "joins" the number and unit name with &nbsp; instead of the normal space. I don't think the module should change wrapping of the convert without a lot of thought and discussion. Johnuniq (talk) 12:02, 1 October 2013 (UTC)
Yes, these three "Need" into "Needs".
I was talking about wrapping the superscript message only, not about the regular convert output.
I mean both the title (mousehover) and help section title can be longer, more sentence like and the same (still m.hover has "Convert: " prefix); superscript text would stay short. But no big deal. The rest is fine. -DePiep (talk) 12:22, 1 October 2013 (UTC)

New message format

Initial suggestions

Following suggestions from Wikid77 at Template talk:Convert and from DePiep above, I have done a major refactor of how messages are displayed. While I'm pinging people, would WOSlinker and Trappist the monk like to comment? (The format of Help:Convert is based on Trappist's Help:CS1 errors.)

Key points:

  • If the input is valid, it is shown. An error with the output is shown where the output would normally appear. There are some rare errors which can occur deep inside complex code, and such errors do not follow this procedure (that is, nothing but an error message is shown).
  • There is now no difference between errors and warnings, but the module still uses add_warning to record those errors which do not prevent a valid conversion (for example, an invalid precision or sigfig is ignored, but a warning is created).
  • Warnings are not displayed unless warnings=on (currently, that means if {{convert/sandboxlua2}} is used). I have remembered why warnings default to off—if convert is used in a template, it is quite possible that empty options would be passed to convert because templates often have constructions like "|abbr={{{abbr|}}}" which could result in "|abbr=" being passed to convert. My intention was to start with warnings off, then after important problems are fixed, enable warnings and see what happens.
  • The new messages appear as a superscripted link. No scary colors are used, and the message causes little disruption to the page. The link text is very brief; a longer message appears in a popup when the mouse is held over the link. Each link goes to a section at Help:Convert.
  • Each visible message starts with "convert:". That is to make it easier to find such messages in an article.

See message examples at:

I started to think about the category names but there was too much other work to do, and I decided to just use the current names for now. I'll think about that soon.

I do not want to try auto-correction of invalid parameters because I suspect the results would be very mixed—some guesses would be correct, but others would be wildly wrong. I think we would need evidence from an analysis of existing templates with errors before deciding whether auto-correction would be worthwhile.

If anyone has any thoughts on how messages should appear, please comment because I want to make a final decision soon. Johnuniq (talk) 12:40, 29 September 2013 (UTC)

Just wondering when the unknown unit message shows with {{convert/sandboxlua2|1|kkm|mi}}, wether instead of just 1 kkm[convert: unknown unit] it could show as 1 kkm[convert: unknown unit] -- WOSlinker (talk) 13:15, 29 September 2013 (UTC)
In no particular order of importance, some things I've noticed about Help:Convert:
  • Help:Convert is a very broad title. Might it be better if error messages were moved to Help:Convert errors to prevent the addition of other stuff like Units, Options, and Limitations, which probably belong elsewhere? The page does need an introduction to state its purpose and to perhaps give a little history. The section Differences from templates previously used might form part of that introduction or might be moved to a page Help:Convert history or somesuch.
  • Moving error message help-text to Help:Convert errors makes the Error and warning messages heading unnecessary (I think it's pretty much superfluous now).
  • Be consistent when error message names are used. If I click on a link that says Convert: invalid sigfig but land at a section heading that reads Sigfig must be a positive integer, it's not immediately obvious that I've gotten to the right place. I think that this means that section headings in Help:Convert errors should be the same as the text that is used in the link. Use sentence case for error message text that follows Convert: in the link because the heading title will want to be in sentence case.
  • When there are limitations to something, state what that limit is. Precision is too large doesn't say what the limit is (experimentation shows it to be 99, but I shouldn't have to experiment to find that out).
  • Value and number appear to be used interchangeably. Better to pick one term and stick with it.
  • Number is too large or too small but the error message is Number is too large. By experimentation, I tried to find what too small meant. What I got was this which seems like a bug:
    {{convert/sandboxlua|1e-99|m|ft}} → [convert: precision too large]
  • The image inside {{ombox}} should not be linked to a larger version of itself. Instead it should link to Asking questions or should be unlinked (empty |link= in the image wikilink).
  • Shouldn't the messages need value, need another value, need unit read Needs value, Needs another value, Needs unit?
  • Is there a case to be made that all unit abbreviations should be case-insensitive? For example USpt and uspt both work but Ft does not.
Reviewing Help:Convert makes me wonder if anchors are at all necessary both in Help:Convert and in Help:CS1 errors. When a link exists to help text, that link contains an anchor (often rather cryptic) when it could simply link to the appropriate section header. That would simplify Help:Convert and Help:CS1 errors. I'll have to think on that.
—Trappist the monk (talk) 15:59, 29 September 2013 (UTC)
Note, if you change the image link then you'll also need to change the image to a cc0 licensed image since the current one needs attribution. -- WOSlinker (talk) 16:19, 29 September 2013 (UTC)

And for a separate note, no it cannot be case-insensitive. For example:

re Trappist the monk, list.
  • I understand (as I read it) that Trappist in general lines supports this message structure. So the superscript message writing is OK (for Trappist and for me). Unlike in the exemplary CS1 error system, we have article inline messages here (beat that, CS1 encoders ;-) ;-) ).
  • Yes, there could be Help:Convert errors (and Help:Convert warnings; together Help:Convert messages). The primary help sections like "units" and "[parameter] options" are huge and complicated by themselves. Just look at old template:convert/doc. Units there are thousands (while only say a ~hundred are commonly used) and parameter options look simple, but they also interact. So they are huge in numbers and they are complicated for interacting & their level of relevance.
  • I suggest keeping the anchors. Yes the simple wording you mention looks & sounds intuitive, but I'd prefer to keep the section-titleing independent of the message-id. Iow, the help page section names should be independent of the linked error/warning message (think: that anchor could even be a code number).
Also note that this structure (message & categorisation by id not by text) is helpful when going interwiki with this convert script.
  • In general, and for going interwiki/i18n, I support the messaging triangle that does: "warning or error (=message) detection in lua code" == "message target (help page anchor)" == "categorize page by message". This also invites for one cat per each message type (as does CS1). There are 14 message types now 14.
It would require the lua code to work by the 14 message-types basically. Which sounds good to me (no in-code message grouping).
-DePiep (talk) 19:30, 29 September 2013 (UTC)
For example, a message by coding (in psuedo code, for enwiki):
general helppage name:"Help:Convert messages"
message-id:10
anchor:"message-id=10"
category:Convert: X should be Y
level:warning (not error then)
other stuff:not fatal (input can be reproduced)
This way the help page, and a module doc too btw, should handle the anchor, but is not prescribed what text or even section title to use. -DePiep (talk) 19:41, 29 September 2013 (UTC)
There is no competition between those who work on CS1 and those who work on Convert. Don't introduce competition where it doesn't exist and where it doesn't belong.
When I wondered about the necessity for anchors it was because it is just as easy to link directly to the section heading (Sigfig must be a positive integer) as it is to link to an anchor at the same section heading (#sigfig_must_be). Adding anchors, does tend to clutter up the edit window. I was not suggesting that the link between the error message and the help text should be removed. I experimented with this at CS1 and it can be done. Another editor pointed out that there are editors out there who will change section headings for whatever reason which would break the link between the error message and the help text. Because of this reason I have struckout that comment above.
Just because anchors could be a code number doesn't mean they should be. There is no reason to obfuscate the meaning of the anchor. Anchors should be understandable by the humans who will occasionally read them. Anchors like message-id=10 are meaningless to humans because the don't carry their context with them. The anchors don't have to be grammatically correct, they just need to convey their purpose to any and all interested readers whether that is in the Lua code or in the wikitext.
When I said that message text and help text should be consistent, I was thinking about this kind of case where the error message [convert: dimension mismatch] links to a section heading that reads Cannot convert X to Y. To the uninitiated, it does't necessarily follow that dimension mismatch is the same thing as Cannot convert X to Y. To make it easier for the reader, error messages and associated help text section headings should be as close to the same as possible. That way editors know that they have landed on the right spot when they click the error message link. For example, the error message [convert: need value] links to a section heading that reads Need value. It is immediatly obvious that the two are the same.
As an aside, is dimension the right word in the convert: dimension mismatch error message? This is like the numbers and values issue I described above. Pick a term and use it consistently in all places that apply.
—Trappist the monk (talk) 00:04, 30 September 2013 (UTC)

Message types

now there are 14 message types. I propose the core code (module:convert) uses these, and uses a sideset to link & anchor them. Below are the fourteen types, I coded. my point is, that we use the coded ("X10") messages to produce an enwiki helplink+cat+more. -DePiep (talk) 23:05, 29 September 2013 (UTC)

Another good princiople is, that the core corde (using X10 like messages) does not need tpo hardcode effects of "warning/error/nonfatal" status, nor category names. Also the turning on/off of an error message over 500k pages is a switch. -DePiep (talk) 23:10, 29 September 2013 (UTC) See:
Overview of messages (error, warning) As of 29 September 2013.
As of 29 September 2013.

Under development.

id on id (en) text example
in / → out

(using {{convert/sandboxlua}})

helptext cat Error/
Warning/
or ...
X01 yes "need_value" Need value {{convert/sandboxlua|123|m|ft}}

→ [convert: needs a number]

An input value is required. Category:Convert error E
X02 yes "need_another_value" Need another value {{convert/sandboxlua|10|x|20|x| |m|ft}}

→ [convert: needs another number]

The first input value was specified, but the range used requires another value. Category:Convert error E
X03 yes "must_be_number" Value must be a number {{convert/sandboxlua|km|ft}}

→ [convert: invalid number]

Each value to be converted must be a number like 1.23 or 1,234 or -0.9.
... 		Category:Convert error E
X04 yes "too_large" Number is too large or too small {{convert/sandboxlua|1e310|m|ft}}

→ [convert: number overflow]

This error occurs if a value is too large or too small to be used in calculations. The number 1e290 ... Category:Convert error E
X05 yes "precision_must_be" Precision must be an integer {{convert/sandboxlua2|21455|acre|ha|2.5}}

→ 21,455 acres (8,683 ha)[convert: invalid precision]

A precision value is entered after the conversion information. For example, |2 gives ... Category:Convert invalid option E
X06 yes "precision_too_large" Precision is too large {{convert/sandboxlua|123|m|ft|200}}

→ [convert: precision too large]
{{convert/sandboxlua|1.234e-200|m|ft}}
→ [convert: precision too large]

Generally there is no reason to use a precision of more than a few decimal places, however, ... Category:Convert error E
X07 yes "sigfig_must_be" Sigfig must be a positive integer {{convert/sandboxlua2|123|m|ft|sigfig=0}}

→ 123 m (404 ft)[convert: invalid sigfig]
{{convert/sandboxlua2|123|m|ft|sigfig=3.5}}
→ 123 m (404 ft)[convert: invalid sigfig]

The number of significant figures in the result can be specified. For example, |sigfig=3 ... Category:Convert invalid option E
X08 yes "empty_option" Ignored empty option {{convert/sandboxlua2|123|m|ft|sp=}}

→ 123 m (404 ft)

The option |sp=us specifies that ... Category:Convert invalid option E
X09 yes "invalid_option" Ignored invalid option {{convert/sandboxlua2|123|m|ft|abr=off}}

→ 123 m (404 ft)[convert: invalid option]

The option |abbr=off specifies that abbreviations are off, that is, unit names will be used instead of symbols. By contrast, |abr=off is ignored because "abr" is not the name of an option. This message will only appear if warnings have been enabled. Category:Convert invalid option E
X10 yes "need_unit" Need name of unit {{convert/sandboxlua|12||ft}}

→ 12[convert: needs unit name]
{{convert/sandboxlua|12|x|20}}
→ 12 by 20[convert: needs unit name]

A unit code must be specified following the input value or values. Category:Convert unknown unit E
X11 yes "unit_not_known" Unit is not known {{convert/sandboxlua|12|Ft|mi}}

→ 12 Ft[convert: unknown unit]
{{convert/sandboxlua|12|ft|m i}}
→ 12 feet ([convert: unknown unit])

Each unit code must exactly match a known unit, case sensitive. Available unit codes are listed here. Category:Convert unknown unit E
X12 yes "dimension_mismatch" Cannot convert X to Y {{convert/sandboxlua|123|psi|ha}}

→ 123 pounds per square inch ([convert: unit mismatch])

It is only possible to convert between units that have the same type. For example, psi and Pa are each of type "pressure" so ... Category:Convert dimension mismatch E
X13 yes "x_should_be_y" X should be Y {{convert/sandboxlua|21|pt|L}}

→ 21 pt[convert: ambiguous unit]

Some unit codes are not supported; using them results in an message indicating that a different unit code should be chosen. Category:Convert error E
X14 yes "unit_invalid_here" Unit is invalid here {{convert/sandboxlua|12345|ft|yd+mi km}}

→ 12,345 feet ([convert: unknown unit])

Some units can only be used as outputs. For example "C F" displays a temperature in Celsius and Fahrenheit. Such a unit ... Category:Convert unknown unit E

Discussion

I have implemented WOSlinker's idea above (results below). I guess everyone commenting likes the new format, although various things need to be fixed. Thanks for the comments which I will try to digest. Here are some initial responses:

  • Trappist is correct that if a linked message says "convert: invalid sigfig", then it is disconcerting to arrive at a section with a significantly different title. Currently, each title at Help:Convert is a summary of the full error message which the user would see if they knew to mouseover the error link. There's a conflict: we want the message shown in the article to be brief, yet the help page should have better titles. Perhaps the help section titles could start with the link text? I'll think about that.
  • Also correct is that Help:Convert would become far too big if all the gumph were included. One problem is that before I put the two padding sections at the bottom of that page, clicking an error message link for the last few items failed to scroll the target section to the top of the page. If the page is cleaned up, I'll have to think of some padding to stick at the bottom.
  • The reason "Precision is too large" is vague is that it is implemented by calling the system to format the value as text, and reporting "too large" if the system call issues an error. It's just a call to Lua's string.format, but Scribunto probably passes that to the server's C library, or more likely to some PHP function. At any rate, the result depends on the server and conceivably could change in the future.
  • Likewise "number is too large or too small". Lua's tostring function will happily convert a junk number like 0/0 or 1/0 to a string, yet I don't think convert should display a result like "nan" or "inf". It appears that Lua (or the underlying floating point hardware/software) does not give an underflow error—if a number is too small it is changed to zero. However, a new server conceivably could give an underflow error, and that's why I added the weasel "or too small". OTOH I doubt if the module would detect underflow now because I have found that tostring under Scribunto returns text that is different from my test computer (which helpfully includes "#" in the text if it represents a value that a normal person would have difficulty recognizing as a number). This kind of error will be very rare, so it may not be worth worrying about, but it would be good if someone can think of some clever wording to replace the message to avoid its problems.
  • Re caps: I took the idea of all lowercase from DePiep. I would need to examine some simulated results showing the different message styles to be sure, but I think the lowercase works well in the superscript.
  • I agree with Trappist that anchors should be at least moderately recognizable by humans—I frequently look at the browser's status line to see the URL of a link target, and don't like encoded URLs.
  • Re categories: It makes perfect sense to me that CS1 has a separate category for each type of error becauses citations are complex, and it is likely that it would be easiest to clean up one kind of problem at a time (perhaps fixing other obvious errors at the same time, but essentially focusing on one error category which is one error type). By contrast, I don't see any benefit for convert to have a multitude of categories. We have no idea how much of a mess will be revealed when the module goes live although I think there will be at least 20 unknown units which need to be fixed quickly, and 100 or more pages with errors that have been present for an extended period (dimension mismatch or junk—I've seen things like "3ft" where possibly "3|ft" was wanted). After they are cleaned up, I'm hoping the number of convert errors will be small, and will be easily fixed. An editor with some convert experience won't need to focus on one type of error at a time, although there will be cases where the intention is unclear, and we'll have to wait for a topic expert to research what is needed. I'm now wondering why I devised four categories—perhaps just one would do? I cannot see any benefit from having a separate category for each error message. I did want "unknown unit" as a separate category because, particularly in the first month, there may be lots of units which are not yet defined in the module, and attention will be needed to that category because it represents stuff that probably worked before, but which is now broken. The other errors will mostly be broken wikitext that we have had no way of detecting in the past. After the first month, there would be no reason to have an "unknown unit" category—a bad unit would be just another error to be fixed. There are two problems with having several categories: first, more categories gives more complexity and stuff needing to be monitored; second, there would be no easy way to check for new errors since each of a dozen categories would have to be examined in order to find problems. Johnuniq (talk) 07:16, 30 September 2013 (UTC)
I like the new messageing, so my following remarks are minor.
I used the lowercase superscript message after checking {{fix}} metatemplate (as in:to be fixed) usage, that shows all superscripts in lowercase [to-be-fixed] (unforced, by habit). Even lettercase aside, this superscript text generally is not the same as target text (say a page section title).
A human-readible anchor text is OK with me (I was looking far ahead, to iw transations...).
I expect indeed that the number of pages per message category is low, after an initial cleanup. My background thought for this message setup system is, that the message-fact (detected in running code) should have a simple set of effects (warning level, cat name, superscript text, anchor/helpsection name, show message=y/n, ...). Once set up table-like, naming & handling messages then is a single table simple job (and it would simplify future iw translation). Having said this, I cannot prove this to be to one & only option. I can live with another outcome. -DePiep (talk) 21:19, 30 September 2013 (UTC) Struck & clarified sentence -DePiep (talk) 07:42, 1 October 2013 (UTC)
OK, thanks. I think I'll work on the problems mentioned above regarding some messages, and in particular the section headings. Johnuniq (talk) 23:38, 30 September 2013 (UTC)

Convert documentation and data pages

I guess the preliminary documentation at the following is at the right place:

Later, the template documentation could be tweaked to serve as an introduction:

Presumably the following should be moved somewhere more central.

Module space works with Lua scripts only. Wikipedia space is not suitable. Template:Convert has thousands of subpages, but I can't think of anywhere else. Any ideas on a suitable home? Is "Conversion data" the right name? Johnuniq (talk) 07:54, 2 October 2013 (UTC)

In modulespace, every page that ends with "/doc" accepts regular wikitext (not scripts). We could have:
Note that Template:Convert/doc will stay first port of call for editors; that template documentation text should be refined when the module is live.
Current testcases (where ee test the template) should stay in template space.
Note that I named pages all lowercase. This is required for /doc and /sandbox to use automated page effects (recognition by etc. templates, and allow wikitext at all!).
We should stick to on only choice of course. All lowercase I propose. As we already do: subpages of module:convert.
And the list of subpages should be kept tidy. -DePiep (talk) 08:36, 2 October 2013 (UTC)
That's an attractive idea, although I think we would be stuck with "This is the documentation page of the module Convert/conversion data" at the top (from MediaWiki:Scribunto-doc-page-header which uses {{documentation subpage}}). Actually, I just wrote a nice little script that could live at Module:Convert/conversion data—running it created the wikitext of the tables at Help:Convert units. Johnuniq (talk) 09:32, 2 October 2013 (UTC)
Well, documentation it is, especially the source data table. And I object to the trick. It is not a "help" table, it is source. Help could transclude it into its page. Finally, this will produce a mess of documentation pages cross namespace. -DePiep (talk) 09:47, 2 October 2013 (UTC)
  • A lot of these documentation pages are background material (not directly tied to a parent module page). To keep overview, we could group them this way:
module:convert/documentation/conversion data/doc (the tables)
module:convert/documentation/conversion data introduction/doc (description)
These /doc pages do not have a parent page (this is a quirk).
Regular /doc subpages are named standard:
module:convert/data/doc for module:convert/data -DePiep (talk) 10:19, 3 October 2013 (UTC)
Similar problems with module space are solved this way: Module:Bananas/testcases (lua code) reports in its talkpage: Module talk:Bananas/testcases (wikitext). This is cross namespace though, and our documentation does not have such an input-output relation. -DePiep (talk) 08:14, 4 October 2013 (UTC)
Similar problems with module space elsewhere are solved this way: Module:Bananas/testcases (lua code) reports in its talkpage: Module talk:Bananas/testcases (wikitext). This is cross namespace though, and our documentation does not have such an input-output relation. -DePiep (talk) 08:14, 4 October 2013 (UTC)

Proposal

Based on DePiep's ideas above, and because it would be good to keep all stuff related to module convert together, how about moving these pages:

@WOSlinker: Is this desirable? Is there a reasonably straightforward way to edit {{documentation subpage}} to output nothing for cases like the above (so "This is the documentation page ..." is not displayed by MediaWiki:Scribunto-doc-page-header)? My suggestion (no idea if achievable) is that it would be desirable for Module:Does not exist/doc to show the normal "this is the documentation page", but Module:Something/subpage does not exist/doc need not. Or, could the title part "documentation" be regarded as a magic word to suppress display? Johnuniq (talk) 01:16, 4 October 2013 (UTC)

Afterthoughts:
The idle parent page of a /doc could have the {{documentation}} template, transcluding nicely into a true doc page. We can put a note on top saying like "this is an idle module page, but the documentation is ...".
überdocumentation: module:documentation/doc could have a complete page overview, navigational. -DePiep (talk) 08:14, 4 October 2013 (UTC)
I've updated MediaWiki:Scribunto-doc-page-header to not include the header on those pages, so you can move them now. -- WOSlinker (talk) 08:20, 4 October 2013 (UTC)
Thanks, now moved. Johnuniq (talk) 09:00, 4 October 2013 (UTC)

Maintenance category names

Resolved
 – outdated, see elsewhere -DePiep (talk) 21:14, 9 October 2013 (UTC)

The module uses four categories:

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

I propose name changes:

  1. Make category names plural by standard WP:CATNAME.
  2. Be more descriptive: "Pages with a convert dimension mismatch". This name is longer and less easy, but it is correct to the letter and is according to most maintenance pages. The short names are only usefull for more experienced editors in the topic (you and me), but are sort of code/jargon. Johnuniq replied earlier here.

Proposed names:

  1. Category:Pages with conversion errors
  2. Category:Pages with conversion dimension mismatches
  3. Category:Pages with unknown conversion units
  4. Category:Pages with invalid conversion options
  5. Parent: Category:Pages with conversion messages
Any comments? -DePiep (talk) 12:16, 21 September 2013 (UTC)
Changed into double plurals ("Pages ... errors") copying the CS1 example Category:Articles with incorrect citation syntax. -DePiep (talk) 12:27, 21 September 2013 (UTC)
See Template_talk:Convert#Edit_request_on_20_September_2013 about how to present the error messages. If we choose the Wikid77 proposal (add superscript link, not the colored inline text), we could use the following corresponding maintenance links;
  2. [conversion error]
  3. [dimension mismatch]
  4. [unknown unit]
  5. no superscript link (or [unknown option])
This way we have a triangular connection between message, category and help page section. -DePiep (talk) 13:24, 21 September 2013 (UTC)
I don't think that all the errors should be subscripts as some errors mean that no conversion is done, for example {{convert|1|pt}} → 1 pt[convert: ambiguous unit] Maybe some can be though where they still produce something but for warnings rather than errors, a category would do without any inline messages. -- WOSlinker (talk) 15:21, 21 September 2013 (UTC)
Why not return: 1 pt[unknown unit]. After all, the input did not fail just the conversion. btw, is there a system for these errors? Are they marked or listed? Is the categorization too generic? -DePiep (talk) 15:40, 21 September 2013 (UTC)
Anything in Module:Convert/data with a "shouldbe" parameter. -- WOSlinker (talk) 16:34, 21 September 2013 (UTC)
They should have their own category. Still, there is no error committed so does not merit a red alarming inline errortext. Just add superscript + maintenance category (as I exampled above). -DePiep (talk) 18:02, 21 September 2013 (UTC)
Try one with the current convert template and the error message is even bigger. -- WOSlinker (talk) 19:28, 21 September 2013 (UTC)

1 pt[convert: ambiguous unit]

That must have made a lot of editors happy. So inviting. And what about the category suggestion? -DePiep (talk) 22:28, 21 September 2013 (UTC)

Technical aspects

If we are to use the superscripts, some technical questions arise. Usually, such superscripts are constructed in a template using meta-template {{fix}}. So I created example {{convert dimension mismatch}} for this demo. It has the category name, title, etc: If such an error occurs, the module should: 1. transclude this oldstyle template onto the page; 2. should add the error description to the |title= (will be mousehover-text). 3. Could add a more specific error code somehow for more precise linking |anchor=.
Example: [dimension mismatch].
Johnuniq, do you like this way to go? Of course, the code could be handcrafted and hardcoded in the module too. -DePiep (talk) 14:52, 21 September 2013 (UTC)

Re the display: I don't mind. I had planned deferring clever output until "later", but let's do it now. Some RL issues mean I don't want to devote calm thinking time to this issue at the moment, but the ideas at Template talk:Convert#Edit request on 20 September 2013 look good, and I'm happy to implement whatever is wanted (I will think about it in a day or so). My only concern is that the system should be simple, and should be driven from a table of data (rather than a bunch of "if this else that" code specific to each unit or parameter problem). It appears that we need a single doc page with anchors, and the module table should include the required anchor for each message. In the case of a dimension mismatch, should the anchor be to a units doc page (using the type of the first unit as the anchor)? Given that the existing templates have many significant problems, and cannot detect dimension mismatches except in a few hand-crafted cases, I think that bolting on an AI system to do what the user wanted is not necessary, and is inadvisable. I don't think it's a good idea because very few editors are going to argue with "the computer" once the computer has decided that a certain kind of output was wanted—what's needed is a clueful editor with enough understanding of the topic to know should be done.
One issue I don't think has had enough attention in the current discussion is the case where an editor inserts a convert now, then does a preview (or save). I would prefer that the editor sees a prominent message telling them they need to fix something or get help. Also, while it's good to spare readers the pain of seeing error messages, the rendered text should make it clear that what they are reading is wrong. Johnuniq (talk) 05:32, 22 September 2013 (UTC)

Error message enhancing

Resolved
 – outdated -DePiep (talk) 21:11, 9 October 2013 (UTC)

IIC, the default inline error message reads like: Conversion error: Cannot convert "torque" to "energy" (the link is to this talkpage).

Let's compare this with the earlier Module:citation/CS1: |accessdate= requires |url= (help). It links a specific helppage section, and adding the page to Category:Pages using citations with accessdate and no URL (example now on this page).

First, the link to this talkpage is very generic (the same for all errors), and not that helpful (are we supposed to report it, or to fix it?). I suggest it links to a documentation page section, at least as precise as the four categories are. It can also add a link like (talk) to this talkpage indeed.

Second, about that orange color. Note that these messages are inline, warning a reader who most likely does not know what to do with it (there are 100 readers for one knowing editor). Isn't there a less-alarming way of messaging? Put () brackets around it, to separate it from content text maybe? And anyway, it is way too dark as a background color (black or blue text does not contrast enough this way). The same standout effect on a white page is provided by a lighter orange color say #ffcc69, makes easier reading.


Together: (Conversion error (talk): Cannot convert "torque" to "energy") -DePiep (talk) 14:17, 19 September 2013 (UTC)

I've tweaked the above to remove this talk page from Category:Pages using citations with accessdate and no URL.
–Trappist the monk (talk) 12:38, 4 November 2013 (UTC)
I hope to give a substantive reply later (RL issues are interfering now), but meanwhile I have dumped a reasonably complete list of all messages that the module can display here. That may be useful while considering what should happen. Johnuniq (talk) 03:03, 20 September 2013 (UTC)
It's later, and I'm not likely to get any quality time to spend on this, so I'll just add it to my long todo list. I like the links produced by CS1, but there's a fair bit of work getting that all organized. I don't even have a good doc page, although I made a start here. I prefer your lighter orange, will do soon if no one offers an alternative suggestion. Johnuniq (talk) 10:43, 20 September 2013 (UTC)

@DePiep: I have implemented as much of your above suggestion as I can at the moment. I would like to include links to a help page as above, and have thought about how to implement that. However, it will have to wait for a decent help page, and a bit of time to do the work. I used Special:ExpandTemplates to capture the following:

  • {{convert/sandboxlua|12|m|kg}} → 12 metres ([convert: unit mismatch])
    <span class="noprint" style="background:#ffcc69;">[[Module talk:Convert|Conversion error]]: Cannot convert "length" to "mass"</span>
  • {{convert/sandboxlua2|12|m|ft|abr=off}} → 12 m (39 ft)[convert: invalid option]
    12 metres (39&nbsp;ft)<span class="noprint" style="background:peachpuff;">[[Module talk:Convert|Conversion warning]]: Ignored invalid option "abr=off"</span>

The second example uses the new template {{convert/sandboxlua2}} which includes "warnings = on" (that parameter has to be in the template, not the convert).

I also implemented WOSlinker's suggestion on my talk so tracking categories are only included in the error or warning if the current page is in a wanted namespace (default "0,10", that is, main and template, per your suggestion). In case you missed it, I'll mention here that I updated a reply on my talk to say that some testing shows that 31 warnings were generated in 7,540 converts scraped from various articles. Johnuniq (talk) 09:54, 21 September 2013 (UTC)

Thanks. The link I propose could point to the type-section (in the input list), when applicable (when it is a unit-issue). Like: Help:Convert#length (and add piped label). But maybe the idea Wikid77 launched the other day might be better (using a superimposed linked text). btw, the message could use a starting space. -DePiep (talk) 10:12, 21 September 2013 (UTC)
That is, the warning could use a leading space. Error messages not. -DePiep (talk) 11:06, 21 September 2013 (UTC)
OK, I inserted the space, as is now shown above. Actually, it's "&nbsp;" so the start of the warning appears next to at least some of the convert output. Anyway, that will all have to be refactored when the message plans are finished. Johnuniq (talk) 11:10, 22 September 2013 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Module_talk:Convert/Archive_1&oldid=922766748"