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 19:22, 1 November 2013 (Archiving 4 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)

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)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Module_talk:Convert/Archive_1&oldid=579776374"