Common fractions in humanize

[max.rabkin@…]

The "humanize" tags are very useful for making a site friendly, but one thing that is missing are common/vulgar fractions, which are much more human than decimal fractions in many contexts. This patch adds text_fraction (which produces fractions like "1 1/4") and html_fraction (which generates HTML using sup and sub tags to position the numerator and denomenator).

[max.rabkin@…]

Adds fractions to humanize

[anonymous]

Hmm.. I like this. Tests, docs and all.

[Simon G. <dev@…>]

Uh, that was me.

[anonymous]

Could you please use the actual entities for the common fractions? Screen readers, search engines, etc, benefit from the actual entities. Plus, they look a lot nicer!

1/4, 1/2, 3/4 are covered by &frac14; &frac12; and &frac34; respectively, or with their Unicode equiv: ​http://www.unicode.org/charts/PDF/U0080.pdf

1/3, 2/3, 1/5, 2/5, 3/5, 4/5, 1/6, 5/6, 1/8, 3/8, 5/8 and 7/8 are the vulgar fractions and are covered by Unicode under the "Number Forms" chart: ​http://www.unicode.org/charts/PDF/U2150.pdf

[max.rabkin@…]

I will change it to use unicode fractions where available. Should I also change it to use U+2044 (FRACTION SLASH) instead of U+002F (SOLIDUS)? I don't have IE, so I can't do serious testing of the generated HTML.

[max.rabkin@…]

Fractions for humanize, using Unicode characters where possible

[max.rabkin@…]

fraction2.diff now uses Unicode fractions where these are available. I'm changing this to "Unreviewed" - not sure if that's right, but since the behaviour is somewhat different I thought it was best.

[Malcolm Tredinnick]

This is not something that can be moved straight to ready for checkin. There are a large number of assumptions being made here that require some thinking.

One obvious technical question is what is the common font support like in different browsers on different platforms for these particular Unicode codepoints? There's a good argument for including conversions for 1/2, 1/3, 1/4, 3/4, say, since they have good font coverage. Anything beyond that is going to need more supporting evidence to suggest it's a good idea. If we don't have solid coverage in all common fonts, we are basically saying "don't use this, because most of your users won't be able to see some of the results".

I'm also not in favour of the sup/sub changes for other fractions at the moment. It's not particularly semantic.

This requires a design decision and before we can make that (for the first point), cross-browser, cross-platform data is needed.

[max.rabkin@…]

Good points. Browser-wise: the fifths and sixths appear as "<" in IE 6 (on Wine/Ubuntu); it's all good on Firefox (2.0, Ubuntu) and Konqueror (3.5.6, Ubuntu).

Perhaps <sup> and <sub> should be replaced with <span class="numerator"> and <span class="denominator">?

The best solution may be to remove the entities which IE doesn't support, and simply render them the other way.

[max.rabkin@…]

only uses unicode fractions which are supported by IE 5, and doesn't use sup and sub

[anonymous]

Thanks. The sup/sub thing doesn't play well, so thanks for not using it. Screen readers can tend to skip over sup elements (thinking they are footnotes or useless text), and read sub inline. So "Out of the group, ¹/₂ were blond" can get read as "Out of the group, 2 were blond". Whereas "Out of the group, 1/2 were blond" would be read as "Out of the group, 1-slash-2 were blond" (not pretty, but the better than <sup>). Just the common fractions are a huge improvement.

[anonymous]

What's happening with this ticket? Is the necessary design decision going to be made?

[James Bennett]

If you have a question of that nature, please post to the django-developers list about it; design discussions usually take place there rather than in Trac because it's much easier to keep track of them via email.

[Jacob]

This feels a bit too special-purpose for addition to Django, and since no other core devs have weighed in I'm going to assume that this is better put into a third-party app.