सदस्य:Johnuniq/number

Overview

• en:User talk:Johnuniq/Archive 13#Module:Convert and non-arabic digits ∙ Discussion with User:Siddhartha Ghai.
• Template:अंक परिवर्तन/sandbox ∙ Template to invoke module.
• Module:अंक परिवर्तन ∙ Module to change a number.
• User:Johnuniq/number/tests ∙ Test results of using template.
• सदस्य:Siddhartha Ghai/अंक परिवर्तन प्रयोग ∙ Test cases for actual usage in templates

I may add more tests in due course, or anyone is welcome to add tests. Please start a new section at the end of this page to report things that need to be fixed in the tests. Johnuniq (वार्ता) 10:54, 10 सितंबर 2013 (UTC)

Padding

I could not quite decide how to handle padding and grouping. I can't see any reason why padding on the left with zeros would be wanted if commas were also being inserted to group numbers, and I really can't imagine that anyone would want grouping in the padding. Therefore, I did what was easy, namely to add padding if specified regardless of whether grouping is also in effect. The padding does not have commas. See the tests for some results. Let me know if something different is wanted. Johnuniq (वार्ता) 10:54, 10 सितंबर 2013 (UTC)

I think this behaviour should be fine. I don't see why anyone would need the padded zeroes to be comma seperated either.--सिद्धार्थ घई (वार्ता) 21:29, 10 सितंबर 2013 (UTC)

Translations

The following shows a few lines extracted from the module:

local mtext_hi = {
    parm_numdot = 'decimal', -- parameter to specify decimal mark (single byte; default dot)
    parm_numsep = 'sep',     -- parameter to specify group separator (single byte; default comma)
    -- Output messages ("%s" is replaced with the invalid input text).
    invalid_number = 'Value "%s" is not a valid number',
    invalid_parm = 'Parameter "%s" has invalid value "%s"',
    missing_parm = 'Need value',
}

It is possible to enter parameters:

• decimal = .
• decimal = ,
• sep = .
• sep = ,

These are optional; they set the decimal mark (default ".") and group separator (default ","). Probably the best thing would be to remove them from the template, and forget about them in the module. The defaults do what is wanted here, and I only included the items in the template for my testing. However, they could be retained and replaced with suitable translations if wanted.

The output messages need to be translated. Please either edit the module or edit this section and post something below. Johnuniq (वार्ता) 09:58, 10 सितंबर 2013 (UTC)

Yes, the decimal and seperator parameters are not needed in the template. I seriously doubt they would ever need to be changed. However, I think it would be a good idea to leave them in the module just in case.

I've translated the error messages in the output.--सिद्धार्थ घई (वार्ता) 22:33, 10 सितंबर 2013 (UTC)

Decimal Handling

As of now, entering a number with a decimal at the end such as 12345. produces the output with a decimal at the end. I don't think this would be desired behaviour. I think if there's nothing after the decimal, then the decimal should be stripped from the output.--सिद्धार्थ घई (वार्ता) 22:33, 10 सितंबर 2013 (UTC)

Incorrect handling of second parameter in formatted output

The second parameter, for the output length, was originally intended to provide the output in the specified number of digits. That is, {{अंक परिवर्तन/sandbox|12345|6}} should give 012345, which happens correctly. However, using {{अंक परिवर्तन/sandbox|12345|6|स्वरूपण=अंतर्राष्ट्रीय}} or {{अंक परिवर्तन/sandbox|12345|6|स्वरूपण=भारतीय}} should give 012,345 in both cases whereas the current output is 12,345 or 12,345.

The incorrect handling is that it appears the output string length is being matched with the second parameter. What needs to be matched is the length of the number, that is, commas and the decimal need to be ignored in that length.

So I would expect {{अंक परिवर्तन/sandbox|12345.678|12|स्वरूपण=अंतर्राष्ट्रीय}} to give ००००१२,३४५.६७८

Note that the padding is still without commas, but the total number of characters in the string is 14 (12 numerals + 1 comma + 1 decimal). --सिद्धार्थ घई (वार्ता) 22:33, 10 सितंबर 2013 (UTC)

Weird! If you're really sure there is a use case for that, fine. I could insert the zeros before grouping (so they are grouped, contrary to what you just said), or after grouping (to match what you said). No problem either way, but both seems unlikely to me. I'm going elsewhere and don't know when I'll get that done, but it should be within a few hours. Johnuniq (वार्ता) 00:50, 11 सितंबर 2013 (UTC)

I got back sooner than expected and have changed the module to omit the trailing dot from input like "123." and to make the padding count the number of digits only. I thought it looked nicer to put commas in the padding but will take them out if wanted. Examples:

• {{अंक परिवर्तन/sandbox|123.|12|प्रकार=अरबी|स्वरूपण=अंतर्राष्ट्रीय}} → 000,000,000,123
• {{अंक परिवर्तन/sandbox|123.|12|प्रकार=नागरी|स्वरूपण=भारतीय}} → ०,००,००,००,००,१२३
• {{अंक परिवर्तन/sandbox|1,234,567.890|15|प्रकार=अरबी|स्वरूपण=अंतर्राष्ट्रीय}} → 000,001,234,567.890
• {{अंक परिवर्तन/sandbox|1,234,567.890|15|प्रकार=नागरी|स्वरूपण=भारतीय}} → ०,००,००,१२,३४,५६७.८९०

Johnuniq (वार्ता) 04:16, 11 सितंबर 2013 (UTC)

Thanks. :)

And you're right. Zeroes with commas do look prettier.--सिद्धार्थ घई (वार्ता) 22:55, 12 सितंबर 2013 (UTC)

Untranslatable error message

Line 193 of the module contains the following:

        error(string.format(mtext[code] or 'Unknown error', parm1, parm2), 0)

The Unknown error should be moved to the mtext_en and mtext_hi objects allowing it to be translated. I'm guessing (since I don't really know Lua) that this line would then become:

        error(string.format(mtext[code] or mtext['unknown_error'], parm1, parm2), 0)

and the mtext objects would contain the line:

    unknown_error = 'अज्ञात त्रुटि',

and

    unknown_error = 'Unknown error',

--सिद्धार्थ घई (वार्ता) 22:33, 10 सितंबर 2013 (UTC)

Your code looks good, but I'll need to think about the best procedure. The "Unknown error" text would only occur if someone edited the module and introduced a bug, and even then would only be visible if invalid input was entered in a template in a way to show the bug. The point of a last-resort error message is that you want to show text that would be at least potentially useful, rather than showing nothing. What error text should be displayed if someone edits the module in a year and fouls it up so that mtext['unknown_error'] fails? With the above code, if that ever occurred, the script would crash (because mtext['unknown_error'] would be nil), and the result would be "Script error" in Hindi. I suppose we could have:

error(string.format(mtext[code] or mtext['unknown_error'] or 'Unknown error', parm1, parm2), 0)

Or, just replace the "Unknown error" with Hindi. I'm fine with that. Johnuniq (वार्ता) 03:31, 11 सितंबर 2013 (UTC)

Hmm, I hadn't thought that someone could actually mess up the code enough to break the mtext message interface. But it's always good to have a backup plan. What you suggest seems good enough to me. If someone breaks the module enough to produce the "Unknown error" (ie breaks the mtext), then I think it hardly matters if the error message is in hindi or english. Someone will have to fix it either way.

Also, as far as I can see, both Script Error and Unknown Error offer the same level of useful info, i.e something is broken and we don't know what it is. So I think we'd be fine even without a hardcoded message, unless of course there is a potential of breaking the script in a way as to not show Script Error, in which case the hardcoded Unknown Error message would be useful.--सिद्धार्थ घई (वार्ता) 22:53, 12 सितंबर 2013 (UTC)

Let's wrap this up. The only thing I really want is that the script displaying messages should account for the fact that (due to a broken edit of the module—easy to do), it may be given an invalid message code. One of the problems of a scripting language is that there is no reasonable way to define constants with a compiler to check that the constants are properly defined. Therefore the message script should display a suitable message ("Unknown error" in en or hi), and in general it is not a good idea to over-complicate code for things that should not happen. OTOH, your above code is very straightforward and would be fine. So, please either edit the module or tell me which option to implement: (a) move "unknown" to mtext for translation; or (b) replace "Unknown error" with "अज्ञात त्रुटि"; or (c) do nothing, leave code as is. Johnuniq (वार्ता) 02:39, 13 सितंबर 2013 (UTC)

Range

I'm curious as to what the supported range is for the module. As of now, {{अंक परिवर्तन/sandbox|0.0000001}} and {{अंक परिवर्तन/sandbox|123456789012345.12345}} both seem to work. This is greater than the 1e-4 to 9.9e13 range we discussed. Also, the module code suggests you've thrown in support for scientific notation too. Is this for a possible future convert integration?--सिद्धार्थ घई (वार्ता) 23:27, 10 सितंबर 2013 (UTC)

In our previous discussion on this topic I was thinking with my convert mindset where Module:Convert has to deal with values. When I started seriously on this module I realized that all I'm doing is translating digits—no value is needed. Accordingly, there is no limit on the size of numbers entered. The mention of notation like 1.23e12 was already in some code that I copied from convert, so I left it as there was no reason to purposely not support it. I haven't tested use of "e", but it should work, although whether you want it is another matter. Convert can produce scientific notation output like 1.23×10¹² but I have not implemented that here. No, I don't plan any integration. The complexity level in convert is stunningly high, and I don't think it would be desirable to make some routines more generic for use elsewhere. Johnuniq (वार्ता) 03:13, 11 सितंबर 2013 (UTC)

:D

So it is theoretically possible to input a big enough or small enough number to hit the lua limits?--सिद्धार्थ घई (वार्ता) 22:59, 12 सितंबर 2013 (UTC)

It would be pretty hard hit Lua limits because the module is not doing any arithmetic with the values:

• {{अंक परिवर्तन/sandbox|-1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890.123456789|9999|स्वरूपण=भारतीय}} → −१,२३,४५,६७,८९,०१,२३,४५,६७,८९,०१,२३,४५,६७,८९,०१,२३,४५,६७,८९,०१,२३,४५,६७,८९,०१,२३,४५,६७,८९,०१,२३,४५,६७,८९,०१,२३,४५,६७,८९,०१,२३,४५,६७,८९,०१,२३,४५,६७,८९०.१२३४५६७८९
• {{अंक परिवर्तन/sandbox|1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890|9999|स्वरूपण=भारतीय}} → १,२३,४५,६७,८९,०१,२३,४५,६७,८९,०१,२३,४५,६७,८९,०१,२३,४५,६७,८९,०१,२३,४५,६७,८९,०१,२३,४५,६७,८९,०१,२३,४५,६७,८९,०१,२३,४५,६७,८९,०१,२३,४५,६७,८९,०१,२३,४५,६७,८९०
• {{अंक परिवर्तन/sandbox|-9.87e400}} → −९.८७e४००
• {{अंक परिवर्तन/sandbox|-9.87e300}} → −९.८७e३००
• {{अंक परिवर्तन/sandbox|-1.23e-300}} → −१.२३e-३००
• {{अंक परिवर्तन/sandbox|1.23e-300}} → १.२३e-३००
• {{अंक परिवर्तन/sandbox|9.87e300}} → ९.८७e३००
• {{अंक परिवर्तन/sandbox|9.87e400}} → ९.८७e४००
• {{#expr:-9.87e400}} → -INF
• {{#expr:9.87e400}} → INF
• {{#expr:-9.87e-400}} → -0
• {{#expr:9.87e-400}} → 0

To avoid abuse, I put a limit on the length of padding—it limits the padding to 100 digits but does not show any warning that it has done so. Johnuniq (वार्ता) 02:23, 13 सितंबर 2013 (UTC)

Anything more?

Lots of pages use the template this module is intended to implement, so you may want to think about it some more before changing the template. However, I would like to know if everything seems correct at the moment. What are your plans? Johnuniq (वार्ता) 02:50, 13 सितंबर 2013 (UTC)

Sorry for the delay in response. Everything seems to be working wonderfully. I now intend to initiate discussion with other users about using the module so get reviews. I also intend to make mock-ups of the mainpage and its associated templates to test them with the module. If everything is in order, I'll make the change.--सिद्धार्थ घई (वार्ता) 18:43, 16 सितंबर 2013 (UTC)

OK, good. I tweaked the module because it's nicer to have all the translatable text at the top, and I think the hard-coded text is best.

I'm starting to think about Module:Convert. There are a lot of convert errors at this wiki, and they would all disappear by changing over to the module. However, I see you (or others?) have done quite a number of translations of unit names and symbols, and that all has to be done again, although it will be a lot easier this time because there is no tricky template syntax, and everything is in one place. I'll post more on that in due course.

While investigating, I encountered the "blanking the page" bug, and asked about it at en:Wikipedia:Village pump (technical)#Blank page at Hindi Wikipedia. It turns out to be a bug in formatnum. See that VPT discussion, which points to User:Johnuniq/sandbox which currently has a demo. The bug has been known for a year, but I don't think the issue has been well explained, and it looks like there is no interest in fixing it. Johnuniq (वार्ता) 22:45, 16 सितंबर 2013 (UTC)

The translations have been done by various users over the years. This includes me. However, the translations sometimes broke the template, and not all broken instances were fixed. Then there was the issue of the templates being copied from en-wp over several years, with new subtemplates being added without the older ones being updated. This introduced incompatibilities within the template itself which broke stuff. In short, its a mess.

Off the top of my head, fixing convert would require getting the unit translations from the thousands of subtemplates (to collect it into one place), then fixing the module to accept both the original english parameters and new hindi parameter names, finding links for the units, etc.

Needless to say, this is a very long task. Unless we can come up with a semi-automatic way for scraping the subtemplates for the translations, getting all translations into one place would take weeks, if not months. Add to that the fact that we have to come up with specs for the template, and neither of us fully understand how the one at hindi wikipedia works (due to the various incompatibilities within the template itself).

Also, I see from your english wikipedia talk page that there may yet be changes to be made to the module. Is the module not yet live at en-wp? If not, I would rather prefer to wait till it goes live there and the bucketload of annoyed users (which accompany any technological change at wikis) have had their chance at improving this and any needed changes have been made.

Also, in the immediate future (the next 1-2 weeks), I'm being kept busy on various fronts in my real life as well as with on-wiki stuff (as the delays in my responses undoubtedly show). So, unless you believe that you can begin preliminary work without my significant involvement (or we find someone else to help you out with this in the near-term), we'll have to wait.

In case you're wondering why we need to support english and hindi parameters, the reason's compatibility. Hundreds of articles have been copy-pasted/translated/imported from en-wp to hi-wp over the years with no changes being made in the templates being used. Changing the parameters in these in impracticable. However, since we are working on this, I would prefer that for the future we use hindi parameter names (possibly along with a hindi template name with Template:Convert becoming a redirect). This is why we would need to support both hindi and english parameter names.

Regards--सिद्धार्थ घई (वार्ता) 18:29, 19 सितंबर 2013 (UTC)

There is no rush, and I've got plenty of things to keep me busy! However, just copying the wikitext from Template:Convert/sandboxlua to Template:Convert would fix a lot of problems, including, I suspect, some blank pages. However, doing that before translating the unit names would of course be a step backwards, so we'll wait. Translating will take some effort, but it's not too hard, particularly since I have now had some experience and will probably be better prepared. At the Bengali wiki (see bn:User:Johnuniq/Translation), we have not yet translated the input parameters, but as you say, the en inputs will be kept so articles continue to work, including any new articles copied from en.

The module is not used at en (although it looks like it will start in early October), but that's because many editors have done a lot of work designing and maintaining the convert templates over several years, and replacing all that work needs careful justification. The templates have lots of minor problems at en, but at bn and hi, the situation is quite different—while I haven't examined the situation here yet, I suspect there would be many big convert problems, and even if the module were buggy (it isn't), you would get much better results from it than from the maize of not-quite-compatible templates. I'll ping you later when I'm ready to describe what needs to be done for translations. Johnuniq (वार्ता) 11:12, 20 सितंबर 2013 (UTC)

I just proposed that the template be changed (i.e the module version be used to replace the current version) and notified users on the village pump. Proposal is at सावा:अंक परिवर्तन (in hindi).--सिद्धार्थ घई (वार्ता) 03:57, 28 सितंबर 2013 (UTC)

The template is now live :D --सिद्धार्थ घई (वार्ता) 18:59, 16 अक्टूबर 2013 (UTC)