Website should include start and end dates in formatted name of element

[1ec5]

Whenever the user browses an element using the main website, the feature’s automatically generated name should include the start and end dates to disambiguate the feature from similarly named features from different time periods. Since a date disambiguator doesn’t appear automatically, mappers sometimes add the date to name, even though the actual name has no dates in it.

Here’s where the start_date and end_date values would be appended to the feature name.

[danrademacher]

Thanks for the reference to where we can add this!

I imagine we should trap for cases when either or both start_date and end_date are not present

[1ec5]

As of OpenHistoricalMap/iD#184, iD automatically appends a date range to each feature’s label, which creates an expectation that the name should not include this date range. To the extent that users will need to see the date ranges when browsing elements on the main website, we should mimic that enhancement in ohm-website for consistency.

[1ec5]

The active-date-range gem makes it easier to format a date range. It exposes an API similar to Intl.DateTimeFormat.formatRange() in JavaScript. However, it only supports English so far. Maybe for a start, we could just roll our own date range formatter, since we’d only be displaying start and end years as part of this formatted name.

[jeffreyameyer]

@danrademacher - if @1ec5 has already done the work here, can we have someone review it and get this in?

[danrademacher]

I see that @1ec5 has very helpfully shown us where we should add the dates:

Here’s where the start_date and end_date values would be appended to the feature name.

And checked into options for formatting dates:

The active-date-range gem makes it easier to format a date range. It exposes an API similar to Intl.DateTimeFormat.formatRange() in JavaScript. However, it only supports English so far. Maybe for a start, we could just roll our own date range formatter, since we’d only be displaying start and end years as part of this formatted name.

AND Minh did this work to add to the labels in iD (which is awesome!)

But I don't see that the work on the Rails app is actually done, unless there's a PR I missed.

I think the need here is:

1. Modify the browse_helper.rb file to append start_date and end_date probably like (start_date - end_date)
2. Roll our own date formatter to get the dates to appear properly, ideally with some internationalization (I am surprised Rails doesn't have a date formatter already? How does the app handle things like modification dates?)

[1ec5]

Right, I haven’t made the change. I haven’t set up a development environment to do it yet. Sorry for the confusion.

How does the app handle things like modification dates?

We don’t really need to rely on a gem to format dates. The website currently uses the time_ago_in_words function in Rails, plus a custom localizable format string for the tooltip:

https://github.com/OpenHistoricalMap/ohm-website/blob/ed3ff3c171c5040b76cf4620915d02259a7f89ba/app/helpers/application_helper.rb#L28-L34

Rails also has a to_fs function that could format a year respecting the user’s language preference. It also allows for a custom formatting function, which we might need to supply depending on how the built-in implementation handles BCE dates. Gems like active-date-range and date_range_formatter exist because there isn’t built-in support for formatting date ranges. We could tie things together with a custom format for date ranges. We’ll have to define a custom localizable string anyways for the NAME [DATE RANGE] format.

[1ec5]

In openstreetmap/openstreetmap-website#4033, the upstream maintainers were reluctant to construct element labels from anything other than name and ref for fear of a slippery slope. But given the universality of start_date and end_date in OHM, I don’t see that as a risk in our fork.