rdmurphy / journalize Goto Github PK

Per a suggestion on Twitter — there are some conversions that would make sense to be added via wireservice's lookup. The most obvious one is an AP style state abbreviation conversion.

Main questions to answer:

1. Does this actually depend on that repo? Or do we grab a copy to use here?
2. We need JSON. lookup doesn't provide JSON. While there are ways to read CSV in JS, I'd rather not add that to the library. Either we politely ask lookup to add JSON versions of the data files 😄, or we do the conversion on our end.

A variation of AP style on months is that in extremely tight scenarios you can use what they consider the "tabular" forms of month abbreviations, which is the first three characters of a month without a ending period. (Same logic with May of course, but it doesn't matter there.)

If it's worth having, there are a few paths we could take. apmonth (and apdate) currently have a single parameter (the input Date) so it would have to be decided whether we finally break from that and add options, or if there are spin off versions that do this instead. (Something like apmonthtab, tabularapmonth or something else less gross.)

I lean toward the option approach because it'd be wacky IMO to keep making spin offs for each little variation, and apdate is already slightly needing some way to optionally include the year.

Another path is to only do this for apmonth and not apdate, which one could assume is rarely after the tabular format.

JavaScript has built-in functions for doing rounding calculations via the Math object. But what is missing is a way to supply a precision value to control where the rounding takes place in a number.

Lodash's version makes it possible to pass in a second parameter declaring the precision. Jinja2's filters also include a round() function that accepts a precision value and a flag for which rounding logic to use. And because Jinja2 does it, so does Nunjucks. (This does mean that Nunjucks doesn't technically need this enhancement.)

And while the logic to do this isn't complicated it's maybe just annoying enough to re-find/copy in that this would be helpful.

I think it'd be good to rid this function of the regex that figures out where to place commas and migrate to the Intl.NumberFormat API.

This in theory would create a path for adding light localization to journalize without requiring a massive dependency.

Should work somewhat like Django's yesno.

Ideally though it's not a comma separated parameter being passed in and instead the standard function parameters like you'd expect.

If it's good enough for the canonical source, it's good enough for us.

You sometimes see this called yesno as well, but that'd clash with #92. It's in the same ballpark, however.

This would normalize things like yes, YES, y, true, and 1 to the Boolean true, and no, NO, n, false, and 0 to the Boolean false.

This is basically what this package does, and we could even just straight up wrap it. The only iffy thing here is the inclusion of 1 and 0. I can totally see where in a general sense you'd know those should be "boolified," but in the journalism world sometimes numbers are, well, actually numbers. Could be a super edge case though.

Some style guides insert commas in numbers only starting at five digits.

10000 => 10,000
but
5000 => 5000

Also, some style guides use spaces instead of commas:

3000000 => 3 000 000

It would be helpful to have options to deal with each case.

Have run into this a couple times, and running into it now: Editor puts a localized datetime in a source doc. Javascript parses as UTC and displays in local time, which is offset. Now the date is off.

Simplest solution I can think of is to parse and display as UTC, probably as a separate function, alongside apdate.

Do you plan to have a natural time function?

Also, I'm willing to work on it.

Source reference.

This does risk going into a little funky territory — technically this should output HTML markup, and not just return a primitive value. It's not a big deal to build (already doing on the job, easy enough to port) but curious if that'd be a blocker for anyone.

It's also a feature that pretty much expects to be in a server-side world exclusively — cannot think of a scenario where you'd do this client-side.

(We could, however, additionally add a script that helps consume what json_script outputs.)

This would be a breaking change if done.

Frankly in the majority of scenarios that I'm attempting to use apdate the very first thing I do is peel off the , YEAR that's at the end of the string. Would it make sense for it to stop doing it entirely, or to make it a flag?

Originally it was going to be "smart" and only include it if the input date isn't current year, but I worried that was too clever.

Any input would be appreciated. 👋

Source reference.

Struggling a little to figure out an exact use case for this, but would be easy enough to implement.

What
Add an optional parameter to have journalize.ordinal() return solely the suffix. Alternatively, add parameters to return it wrapped in sup or sub (though this assumption is not ideal).

I'm willing to write a quick PR for this.

Why
In many cases I would like to style or otherwise display the suffix. This currently is not possible without evoking the function, running code to split numbers from letters, and then rendering the html. It'd be easier and less expensive to have journalize break it apart for me.

Example use case:

<p>1<sup>st</sup></p>

How

Add an onlySuffix param in the default function of src/ordinal.js:

// if `convertedVal` is 11, 12 or 13, English gets weird
if (ENGLISH_ORDINAL_EXCEPTIONS.indexOf(convertedVal % 100) > -1) {
  if (onlySuffix) return SUFFIXES[0];
  return convertedVal + SUFFIXES[0];
}

if (onlySuffix) return SUFFIXES[convertedVal % 10];
return convertedVal + SUFFIXES[convertedVal % 10];

With an additional parameter, it may be best to have the parameters now be in object form for clarity. This would be a breaking change though.

journalize.ordinal(num, { spellOutOrdinal: boolean, onlySuffix: boolean })

The hour is reported as 0 rather than 12.

var journalize = require("journalize")
var date = new Date("2018-09-15T16:39:27.832Z") // My browser is in Eastern time
journalize.aptime(date) // "0:39 p.m."

I reproduced this bug in Chrome 68 and Firefox 62 running on macOS Sierra.

I don't know if I would call this a feature or a bug or really anything more than just a thing, but I've noticed that intcomma decides to round off decimals of zero, but not other numbers. For instance:

journalize.intcomma(1000.0)
'1,000'

This is the case even when the user submits a value with an explicitly fixed decimal place.

journalize.intcomma((1000.0).toFixed(1))
'1,000'

I'm certain there is probably some good reason for this I'm unaware of, but I wanted to file this ticket since the second example above was not the behavior I expected as a user.

For what it's worth, it is also not the behavior of the old gods of Django.

>>> from django.contrib.humanize.templatetags.humanize import intcomma
>>> intcomma(1000.0)
'1000.0'

Would it be worthwhile to extend intword() so that it indicates whether the result is exact (65000000 = 6.5 million, EXACT) versus rounded (65036204 = 6.5 million, APPROX)?

This has come up multiple times over the years (#176, #276) and v3 is probably a great time to finally make the call.

The internal calls on the input Date in apdate assume the locale the code is running in — this means there are windows of time where you may end up with the wrong day because in a user's timezone the day has not turned over yet or already changed.

What makes this so tricky is journalize has absolutely no say in the origin of the Date it gets passed. Is it timezone adjusted? Was it just built from an ISO string?

The only observation I can confidently make — I've foisted journalize into so many codebases and I cannot think of a single time I've intentionally passed in a timezone aware date. I'd say nearly all scenarios where I've used it the original source was an ISO string I turned into a Date either via date.split('-') (and so on) or with a parse method via something like date-fns.

My hunch is I'm not alone in this.

AP has formatting rules for writing out months. Like states, some get abbreviated, and others are never abbreviated.

Shocked this hasn't really came up until now, but here we are.

Similar to how apnumber converts 1 through 9 to their spelled out versions, ordinal should have a flag that optionally makes values from 1 through 9 be spelled out. (First, fifth, ninth, etc.)

Breaking the dependency on Travis.