Date formats with abbreviated month name (M) and ordinal suffix are not translated using context

core/lib/Drupal/Core/Language/language.api.php

Because the source of translation strings is English, and some words in English have multiple meanings or uses, this centralized, shared translation string storage can sometimes lead to ambiguous translations that are not correct for every place the string is used. As an example, the English word "May", in a string by itself, could be part of a list of full month names or part of a list of 3-letter abbreviated month names. So, in languages where the month name for May is longer than 3 letters, you'd need to translate May differently depending on how it's being used. To address this problem, the translation system includes the concept of the "context" of a translated string, which can be used to disambiguate text for translators, and obtain the correct translation for each usage of the string.

RTBC #8: 'M' is a short textual representation of a month, three letters and the 'Abbreviated month name' is a correct context of month name abbreviations.

Let's add 'Abbreviated month name' to testLanguageContext()

/**
* Test msgctxt context support.
*/
public function testLanguageContext() {
  // Try importing a .po file.
  $this->importPoFile($this->getPoFileWithContext(), [
    'langcode' => 'hr',
  ]);

  // We cast the return value of t() to string so as to retrieve the
  // translated value, rendered as a string.
  $this->assertIdentical((string) t('May', [], ['langcode' => 'hr', 'context' => 'Long month name']), 'Svibanj', 'Long month name context is working.');
  $this->assertIdentical((string) t('May', [], ['langcode' => 'hr']), 'Svi.', 'Default context is working.');
}

Updated testLanguageContext().

I rerolled added the test only.

Test only passed because it adds context ("Abbreviated month name"). It looks like we need an additional test.

+msgctxt "Abbreviated month name"
+msgid "May"
+msgstr "svib."<code>

This patch also helps German sites to look better as German translations for "Jan" are
Jan (context: Abbreviated month name)
Jan. (no context)

Drupal version 9.1.x
Rerolled the path #18 and updated to Drupal 9.1.x version

Drupal version 9.1.x
Used patch #18 and corrected path #23 which will work on drupal Version 9.1

Confirming issue exists and can be tested with German dates also. For example März is displaying incorrectly instead of Mär. And this patch is solving the issue.

Needs a re-roll. Could also use a test-only patch here to show that it fails without the change.

Hear a reroll patch.

I am arriving late to this but i think my issue is the same issue and i also think this discussion has missed the mark completely. It sounds like the focus is specifically on one part of PHP's date function ('M'); when i suspect this is not at all what this is about. I also think people are referring to interface translation as string translation and translating the text "May" (and i guess all the other months). Pretty sure all of this is incorrect.

PHP and Drupal already correctly translates all the date parts (month, day of the week). The issue is that Drupal (incorrectly) uses the site's
"interface language" to determine the language rather than the "content language".

After digging into this a bit more:

- translation of dates is based on 2 things: locale and translation of format. Locale is set in PHP and determines language to use for textual parts of a date: day of week, months. Format is a Drupal thing and allows to translate a dates "format" which is typically to re-arrange parts of the date definition: Y-m-d (for English) and m-d-Y (for some other language).

both of these, as i mentioned above and imho are done wrong in the core DateFormatter class as they use the site's "interface language". Unclear to me why dates would be considered interface when all other content is considered content. My (simple) solution was to override core's DateFormat class and change this 1 line:

    if (empty($langcode)) {
      $langcode = $this->languageManager->getCurrentLanguage()->getId();
    }

to this:

    if (empty($langcode)) {
      $langcode = $this->languageManager->getCurrentLanguage(LanguageInterface::TYPE_CONTENT)->getId();
    }

which makes dates format translation and locale based off the site's content language.

Interface / content dates is a different task which is not related to the current one.
Moreover, some dates on a page are interface while some other dates on the same page are content. E.g. node creation date output for site visitors is content, but node creation date output as a service field in an editor dashboard is interface.

Just a re-roll of patch #33 to latest 9.4.x. please Review

Fixed CS issues #39, Attached interdiff for same. Please review.

Edited: Needed to fix a module issue that was blocking the upgrade. #41 worked.
None of these patches are working anymore for 9.3.x. The patch won't apply which means I'm unable to upgrade past 9.2 for now.

The failing command is core/scripts/dev/commit-code-check.sh --drupalci, which outputs:

/var/www/html/core/modules/locale/tests/src/Functional/LocaleImportFunctionalTest.php:265:24 - Unknown word (Svib)

CSpell: failed

     $this->assertSame('Svibanj', (string) t('May', [], ['langcode' => 'hr', 'context' => 'Long month name']), 'Long month name context is working.');
+    $this->assertSame('Svib.', (string) t('May', [], ['langcode' => 'hr', 'context' => 'Abbreviated month name']), 'Abbreviated month name context is working.');
     $this->assertSame('Svi.', (string) t('May', [], ['langcode' => 'hr']), 'Default context is working.');

Given that those lines contain words that aren't English words, CSpell should be disabled before those lines and re-nabled after.

The failure is caused by a XML deprecated schema, not the patch.

Could not reproduce under 9.5.3 and 10.0.3. Should be considered fixed by now.

That was too optimistic to mark this issue as fixed.

That was too optimistic to mark this issue as fixed.

Out of misunderstanding! glad that the team members are aware and noticed maximpodorov.

This issue is being reviewed by the kind folks in Slack, #needs-review-queue-initiative. We are working to keep the size of Needs Review queue [2700+ issues] to around 400 (1 month or less), following Review a patch or merge request as a guide.

Appears last patch had a failure.

Updated issue to include support for missing ordinal suffix jS.

Support for ordinal suffixes is a bit more complicated (e.g. https://www.omniglot.com/language/dates/welsh.htm), but providing some translation is better than using English ordinal text within a different language.

And for the more complicated ones, an ordinal dot could could be used.

Available reference: https://3v4l.org/jXP5l#v8.4.4

Test failures are due to a separate issue with functional JS.

Hiding patches.

I've ran the javascript tests 3 times but seem to fail consistently.

Not sure what happened, but the changes didn't touch or should break any of the functional JS tests.

It's now passing following a rerun without any specific changes, so it's something caused by upstream or Gitlab CI as I've experienced something similar in the past.

Odd, definitely ran multiple times guess 4th time was the charm!

Test-only feature has already been ran and shows coverage for the change.

Don't see any open threads or remaining tasks, believe this is good.

Committed/pushed to 11.x, thanks! This doesn't cherry-pick cleanly to any other branches so leaving fixed against 11.x.