Start/End vs From/To? [#1234140]

Currently Date module uses "From Date" & "To Date" to describe the two date values.
But, I think it Start Date & End Date might be sprinkled in there somewhere too. (although I cannot find it atm)
First of all, we need to stay consistent.
Secondly, I think I prefer "Start Date" and "End Date" over From & To.

Other options include labeling the time as well:
Start Date Start Time
End Date End Time

Or we could forget the Date/Time part and just say:
Start
End

This is pretty minor UI change request, IMO. But it has bugged me for a while. I just don't seem comfortable with From and To....
Does anyone else agree or want to voice opions?

Comment	File	Size	Author
#12	1234140-12.patch	964 bytes	David_Rothstein
#5	User_Text_only-1234140-5.patch	46.52 KB	arlinsandbulte

Comments

Comment #1

karens commented 30 July 2011 at 09:37

I actually removed the labels for start and end date in the latest code to compress the amount of space this takes up. Google calendar doesn't have labels like that on their dates, and I'm assuming that's a reasonable model. If people don't like that we can add them back, but the node form is cleaner without so much text.

There are probably other places that text is used. I am fine with 'Start date' and 'End date'. It will break translations, which is why I couldn't change it before, but D7 is still new enough that we could do it.

Comment #2

arlinsandbulte commented 30 July 2011 at 12:19

Assigned:

Unassigned

» arlinsandbulte

I found where "End Date" is used: In the field settings there is an option to "Collect an end date"
"From Date" and "To Date" terminology is used:

On the field edit form.
Display settings (Both From and To dates, From date only, To date only)
Views filter settings (Date default & To date default)
Contextual filter settings (From/To date range & some help text)

A quick search reveals there are places where From and To are used in code and not just user text.
For example, tokens might change.
Also, From & To might be used as array indexes.

Modifying the user display text is easy, but doing that creates a disjoint WTF between what a user might see on a page (Start/End) vs what is in code (From/To).
It would be best to change the code instances to, but that introduces A LOT of opportunity for bugs... stuff like this is never easy.

Does anyone want to provide an opinion on if this idea should be further pursued?

Comment #3

karens commented 30 July 2011 at 12:31

Token support isn't working yet for fields at all, so no one can be using that. I don't know of any places where an array would use 'from' and 'to' as indexes, they are always AFAIK 'value' and 'value2'.

As far as I know, this will only affect user-facing text, nothing that is stored in the database. If you want to look through the code to find out where this actually occurs and make a patch, have at it. I suspect it will mostly be in labels and description text.

Comment #4

arlinsandbulte commented 30 July 2011 at 12:47

Yes, it is MOSTLY labels and description text, but I think there are a few places where this could affect code:
For instance, in date.module, line 531:
if (!empty($options['multiple_from']) || !empty($options['multiple_to']) || !empty($max_count)) {

But things like that are pretty rare.

I will try to tackle this when I get some more time. (assigned to myself).

Comment #5

arlinsandbulte commented 31 July 2011 at 01:44

Assigned:	arlinsandbulte	» Unassigned
Status:	Active	» Needs review

Status	File	Size
new	User_Text_only-1234140-5.patch	46.52 KB

Attached is a patch that should take care of changing all From/To *USER* text into a more consistant Start/End user text. Note: this applies to rendered end user text only, such as labels & descriptions.

For consistency & completeness, this same start/end model SHOULD also be applied to things like variable names & array keys in the Date code.
For instance, do a search for 'fromto' or 'todate' or $fromto or $to.
All code like that should be changed to follow the start/end model.

But, that can be a separate issue to this one. This gets all the translatable strings fixed now. Variable names & arrays can be migrated later, if Karen approves of this text change.

Comment #6

karens commented 31 July 2011 at 10:57

I'm not sure I want to change internal values. For instance, the field has settings for 'fromto', etc. Changing settings is a huge PITA that can break all kinds of things. I don't want to go through that nightmare when I need to get a release out. Changing the user-facing text is plenty. Maybe we can change the internal names in Drupal 8.

Can you check if there is user-facing text in Calendar that needs this change and make a patch there?

Comment #7

arlinsandbulte commented 31 July 2011 at 11:53

Yes, that is what I thought you would say, and I agree about the internal value stuff... one of those things that should be done, but it will continue to work as-is. It just presents a small wtf for developers. It might be possible to to slowly transition that side on a more piece by piece basis... does that sort of change affect APIs?

I will check out calendar module to see if similar user-facing text changes need to be made there to match this change.
EDIT: a quick search of all calendar code (just searching for the string 'from') reveals only 2 places that might need to be changed. And that is just code documentation... no rendered text.

Comment #8

karens commented 31 July 2011 at 12:27

Status:

Needs review

» Fixed

This is committed. Thanks!

Comment #9

arlinsandbulte commented 1 August 2011 at 02:55

Status:

Fixed

» Needs review

Hmm... I don't think this got committed properly...
A fresh checkout shows some or all of the changes were not made, and I cannot find the commit itself at http://drupal.org/node/70963/commits