Module talk:Roman

From Wikimedia Commons, the free media repository
Jump to navigation Jump to search

Initial implemention[edit]

The goal was to preserve the legacy output from the original {{Roman}} and {{Roman year}} templates in the cases where the old templates supported a particular value.

  • {{Roman|1048576}} should output: MXLVMMMDLXXVI
  • {{Roman year|2000}} should output: MM
  • {{Roman year}} outputs: MMXIV

All functionality appears to be working correctly. The {{Roman year}} template is no longer limited to a small range of values. Because these two templates were used in only a few hundred pages, I've moved them to use Module:Roman and hand verified the correctness of the pages transcluding these templates. —RP88 (talk) 16:26, 27 December 2014 (UTC) —RP88 (talk) 16:19, 27 December 2014 (UTC)

I kind of liked {{Roman year}} the way it was because it used fast build in functions, and of used for dates only it was fine since we only use this template in context of years and centuries. If we use the module than we should merge {{Roman year}} and {{Roman}} and keep only one. --Jarekt (talk) 04:04, 29 December 2014 (UTC)
I tested the performance before I switched it over. Surprisingly, the Lua version is comparable, possibly even faster, probably because the old {{Roman year}} nested into {{Str ≤ ≥ len}}. The templates {{Roman year}} and {{Roman}} as they currently stand can't be merged since the semantics are slightly different as {{Roman year}} supports outputing the current year as a roman value (and for years a value zero is an error). —RP88 (talk) 04:44, 29 December 2014 (UTC)
When I wrote {{Roman year}}, my only objective was to simplify {{Roman}} and other templates called by {{Other date}} so we do not run into the template expansion limit. All the used of {{Roman}} that I could find was for years, usually in 1-2000 range or for numbers that are small like floors, centuries, months, etc. As a result I did not see a need for added complexity to cover the numbers in 3k-5M range that are never used, so I wrote much simpler {{Roman year}} and changed most templates that need roman numbers to use it. Calling, the {{Roman year}} with no arguments was never a plan and the behavior is a side effect of the way it is written. I doubt anybody uses it, but we can find and replace those cases with {{#time:xrY}} (MMXIX). --Jarekt (talk) 13:29, 29 December 2014 (UTC)
OK, sounds good to me. It looks like all of the places that currently use {{Roman year}} are either via {{Other date}} or in some code of yours. Would you consider removing the use of {{Roman year}} from your code and then deleting the {{Roman year}} template? I've placed an updated version of Roman in Module:Roman/sandbox and Module:Roman/sandbox/testcases without support for {{Roman year}}. As soon as {{Roman year}} is deleted I'll copy them to Module:Roman. —RP88 (talk) 15:26, 29 December 2014 (UTC)
We can just redirect {{Roman year}} to {{Roman}} so they become alternative names of this same function, than we can swap {{Roman year}} to {{Roman}} at our leisure. --Jarekt (talk) 16:15, 29 December 2014 (UTC)
OK, I've redirected {{Roman year}} to {{Roman}} and updated Module:Roman accordingly. —RP88 (talk) 01:04, 30 December 2014 (UTC)

HTML+CSS deprecated[edit]

I've extended the range of supported numbers, now it works on all non-negative numbers below 5 billions (so it covers the whole set of unsigned 32-bit integers), instead of below 5 millions.

Also another difference is the formating for zero : it is now "N" (for "nec" or "non" adverbs in Classical Latin) instead of the empty string (this convention is standard in CLDR Data /rbnf/root.xml).

It no longer needs to use the HTML+CSS quirks: it generates now ONLY plain-text, using diacritics (U+0304 and/or U+0305). This was this most important reason of this change. You'll note differences in the testcases when comparing the result with the old template that generated HTML+CSS (the existing code was still incorrectly parsing it, in fact it did not work correctly for the reverse conversion to Arabic): these are not "errors" in those test cases but are expected differences.

And it is conforming to Unicode canonical equivalences (for the two graphemes: 'ī' and 'Ī' that can be precomposed or decomposed when using the macron diacritic): the Roman numbers generated ar in NFC form but NFD forms are parsable as well.

It supports also the conversion of Archaic or compatibility Latin Roman characters (they are now recognized when converting them to Arabic numbers, but not used in generated Roman numbers).

Only one Archaic Roman number notation is still not parsable (it uses the reversed C, or for compatibility the open O, for the "lunar" notation of large numbers): this was still not implemented and remains to do (but it requires more complex contextual parsing).

verdy_p (talk) 20:57, 29 April 2015 (UTC)

That sounds great, although I have hard time imagining when it might be useful. The main use of Roman numbers is for century numbers, but it is nice not to have to think if the input is in supported range. --Jarekt (talk) 02:55, 30 April 2015 (UTC)
Before applying the changes, I fully tested in in the sandbox. I have developed some testcases just after.
For big numbers there are several representations possible between "M" and "I" with an aditional overbar: I chose to use "I" with an overbar only at 4 (IV), keeping M for 1 to 3 (for thousands, millions and billions, as this is both more readable and more compact). But all representations are parsed correctly.
They are not used just for centuries or category names, and the fact that it could generate HTML+CSS caused some compatibility problems, for example in title attributes and in some tags where HTML is not suitable.
But now, like in CLDR, if a number is not representable directly, it still has a fallback to Latino-Arabic numbers, so it will normally not fail, unless the parameter really has no parsable numeric value. verdy_p (talk) 09:04, 1 May 2015 (UTC)