Short month names lack context, other contexts overly specific

For starters short month names are not translated with context in Drupal 8 either. Then the contexts for several variants are very verbose / detailed and looks like set up a context that will only ever apply to one string (as opposed to the long month name context). So looks like this needs to be standardized in Drupal 8 first and then backported? It does not make sense to introduce different contexts in Drupal 7 I think.

Retitled and moved to 8.x for this. Can you help prepare a patch?

1. +++ b/core/modules/datetime/src/DateHelper.php
   @@ -118,18 +118,18 @@ public static function monthNamesAbbr($required = FALSE) {
   +      1  => t('Jan', array(), array('context' => 'Abbreviated month name')),
   

   If we would introduce some consistency here, this would be "Month name abbreviation" no? Following the other 2.

   That would not fit with "Long month name", but if we are to keep this like it is, we should change the rest of the ones to make them consistent.

2. +++ b/core/modules/datetime/src/DateHelper.php
   @@ -213,13 +213,13 @@ public static function weekDaysAbbr($required = FALSE) {
   +      t('Su', array(), array('context' => 'Weekday 2 letter abbreviation')),
   

   Looks like these could use "Weekday abbreviation" (or "Abbreviated weekday" as per above) as well, since its apparent they are 2 letter, that is not external contextual information we would need to add.

Looks good, then can be backported to Drupal 7.

The RTBC patch is in #8.

@aloyr: please only post D7 patch once the issue in on D7. So long as it is in D8, your patch will be tested on D8 where it does not apply and it makes it harder for committers to figure out what to review and if the issue is in fact ready or not.

15: 2269165-7-add-consistent-context-names-for-date-fragments.patch queued for re-testing.

Committed ac51ec9 and pushed to 8.x. Thanks!

Remove from D8MI sprint.

This does not seem to backport all the changes? Eg. the short month name.

In the D8 code we've got:

• Abbreviated month name
• 3 Abbreviated weekday?
• 2 Abbreviated weekday?
• 1 letter weekday abbreviation?

I think the D7 patch addresses Month & 3 letter abbreviations using PHP's Date functions.

+    } elseif ($code == 'M') {
+      $options['context'] = 'Abbreviated month name';
+    } elseif ($code == 'D') {
+      $options['context'] = 'Abbreviated weekday';
     }

Given that elseif in D7, I'm not sure how we'd bring in 1 or 2 character abbreviations.

About this issue, we have a few multilingual sites that have a problem with this. Because of the problem of "May" translation, we've had to patch (hack) things either in locale.datepicker.js and/or map_month-function in every site that uses Date module, webform or just any date syntax that has month name in it.

I stumbled to this once again with an old site and started to look if there is another issue open about this and came across this one. So besides the _format_date_callback function there is also locale.datepicker.js file and map_month-function in form.inc that could use the same context, I have the patches for them ready.

The patch in #20 seems to do everything that is doable with PHP's date functions, as stated in #23. It would present two new contexts that seem to be already in D8.

Is there any chance that this would go into D7 core? There hasn't been any activity since 3 years. I understand that there is no "backwards compatibility" for switching from translation without context to translation with context so all language translations would have to be added for those.

For us the month issue is of course more pressing, because it affects the UI of sites that have date pickers or dropdowns for months.