Update spanish date display

VictoriaSunNIH commented 3 years ago

VS - find all instances (press releases, blogs, all other content items)

Issue description

Currently, when we display the content dates on Spanish pages, the date is displaying with capitalized letters for the month.

Can we please update the dates so that the months appear in lower case? Example: "Revisión: 1 de Mayo de 2020" should display as "Revisión: 1 de mayo de 2020"

ESTIMATE TBD

What's the expected change?

The first letter of the month that is being displayed on spanish content is displayed as lower case instead of upper case.

What's the current functionality?

Currently, the first letter of the month is being displayed as upper case.

What's the updated acceptance criteria?

Given user is on an /espanol URL 
  When user views a content page that has date display
    Then the date displays as "Revisión: 1 de mayo de 2020" where the first letter of the month is displayed as lower case
  And the date display rules stay as they are now (date displayed depends on which date was selected in the CMS).

Additional details / screenshot

See Wiki for date display rules (these should not change, only the display of the month changes): https://github.com/NCIOCPL/cgov-digital-platform/wiki/Common-Fields#content-dates

Related Tickets

Original Story Ticket #9999
Original Story Ticket #9999

suryatheja-muppalla commented 3 years ago

Approach:

Implementation of ‘hook_preprocess_node’ in ‘cgov_common.theme’ file of ‘cgov_common' theme.
Need to check for the created date or authored date variable.
Need to check for current language and perform operations like: ‘strtolower()’ to convert month name to lowercase in case of Spanish language.

Cc: @VictoriaSunNIH @bryanpizzillo

bryanpizzillo commented 3 years ago

Approach:

Implementation of ‘hook_preprocess_node’ in ‘cgov_common.theme’ file of ‘cgov_common' theme.

Need to check for the created date or authored date variable.

Need to check for current language and perform operations like: ‘strtolower()’ to convert month name to lowercase in case of Spanish language.

Cc: @VictoriaSunNIH @bryanpizzillo

@suryatheja-muppalla Our dates are a bit more complicated than this, and there is not one way they are being used. Please see https://github.com/NCIOCPL/cgov-digital-platform/wiki/Common-Fields#content-dates to understand which fields are used by dates. Additionally, please see if you can find a solution other than a preprocess function, there are also dates on some media fields, so the above approach would miss that.

suryatheja-muppalla commented 3 years ago

Approach:

Implementation of ‘hook_preprocess_node’ in ‘cgov_common.theme’ file of ‘cgov_common' theme.

Need to check for the created date or authored date variable.

Need to check for current language and perform operations like: ‘strtolower()’ to convert month name to lowercase in case of Spanish language.

Cc: @VictoriaSunNIH @bryanpizzillo

@suryatheja-muppalla Our dates are a bit more complicated than this, and there is not one way they are being used. Please see https://github.com/NCIOCPL/cgov-digital-platform/wiki/Common-Fields#content-dates to understand which fields are used by dates. Additionally, please see if you can find a solution other than a preprocess function, there are also dates on some media fields, so the above approach would miss that.

Creating Custom Field Formatter: Altering existing plugin

‘cgov_site’ module have a FieldFormatter implemented ‘CgovDateFormatter.php’
Update the logic to return lowercase of of month name for Spanish language pages and Making sure existing business logic intact. Creating from scratch
Create a new FieldFormatter from scratch to avoid any conflict with existing Plugins.

bryanpizzillo commented 3 years ago

Please create a table of all the locations we are rendering Months. (Also check blogs too for the archive block)

It would be nice if we could hook into any data formatting and check to see if the month is not at the start to lower case the month.

VictoriaSunNIH commented 2 years ago

Closing this ticket - this is no longer an issue on prod.

bryanpizzillo commented 2 years ago

This issue appears to have been resolved between 7/26 05:04 and 7/27 06:47 looking at the content on the wayback machine. https://web.archive.org/web/*/https://www.cancer.gov/espanol/cancer/naturaleza/estadisticas

This coincides with the 1.2.10 release, however we are unclear at this time to what might have triggered the fix. (It could have been an Acquia update around that time as well.) We are no longer investigating this issues. However noting on this ticket in case it comes up again.

blairlearn commented 2 years ago

Spanish dates have returned to uppercase. e.g. https://www.cancer.gov/espanol/cancer/naturaleza/que-es

bryanpizzillo commented 2 years ago

I think this actually something to do with how/when translations files are imported. We had the lower case version of the dates in the translations pack a long time before it updated on the site. The change only appeared when the "credit" translation change ticket was deployed to production during the 7/26-7/27 timeframe.

During the Drupal 9 upgrade this must have regressed, which I am guessing, was because the Drupal translations file translates these things (incorrectly) and that we imported, overwriting our changes. (Since we did not have any changes)

The root cause of all this is really how the Spanish speaking Drupal community chose to translate dates. Here are the translations from the Drupal translation:

msgctxt "Long month name"
msgid "January"
msgstr "Enero"
msgctxt "Long month name"
msgid "February"
msgstr "Febrero"
msgctxt "Long month name"
msgid "March"
msgstr "Marzo"
msgctxt "Long month name"
msgid "April"
msgstr "Abril"
msgctxt "Long month name"
msgid "May"
msgstr "Mayo"
msgctxt "Long month name"
msgid "June"
msgstr "Junio"
msgctxt "Long month name"
msgid "July"
msgstr "Julio"
msgctxt "Long month name"
msgid "August"
msgstr "Agosto"
msgctxt "Long month name"
msgid "September"
msgstr "Septiembre"
msgctxt "Long month name"
msgid "October"
msgstr "Octubre"
msgctxt "Long month name"
msgid "November"
msgstr "Noviembre"
msgctxt "Long month name"
msgid "December"
msgstr "Diciembre"

NOTE: They are all uppercase.

jfrank-nih commented 2 years ago

I believe you're correct, @bryanpizzillo. I took a look as a learning exercise.

It looks like Drupal by default pulls from their translation server and then secondarily pulls from your .po files. I'm guessing that at the Drupal 9 upgrade between 11/24 and 11/26 your translation dictionary got completely reset and then rebuilt. Though the local files are supposed to take precedence.

On the ODE ncigovcdode442 I poked around and found the translation of "January" was to "Enero" at Home > Administration > Configuration > Regional and language > Translate. Under the "Import" tab it tells us this:

Translation files are automatically downloaded and imported when languages are added, or when modules or themes are enabled.

And under the "Settings" tab we can see that you are configured to pull from the translation server but also that you are configured to only manually update.

If you check for updates (Admin > Reports > Available translation updates) it found updates for a lot of things including the Cgov site. I ran the "Update Translations" button at the bottom and it pulled in the updates, apparently in the correct order (applying local ones over the top of the Drupal ones). Now in the Translate list we see the correct month:

The sample page isn't updating for the "Septiembre" date (I suspect cacheing?) but if I change it to a January date I see "enero" lowercase.

Open questions:

How did the 7/26 to 7/27 update happen? Did it detect the file changed (seems unlikely) or did someone go run a manual translation update?
When Drupal 9 was first deployed, why did it not process the local .po file first like it does with the updates?
Do you actually want it to pull from the Drupal translation server at all? It's a non-controlled source of content. Unlikely that anything happens, but technically possible.

So I think you don't need a code fix. You'll just need to run the translation updates. And maybe clear caches.

jfrank-nih commented 2 years ago

Chatting with @bryanpizzillo this morning he explained that this update is supposed to be run on import by a drush command. Looks like that is the cgov:locales:translate custom command. That is supposed to run the translations check and then translations update, just as I did manually.

Assuming that the drush locale:check and locale:update commands don't have some difference from what's done via the interface then the question is why they're not working here. I don't see anything referencing the timestamp on the local .po file being important as to whether it is processed, what order, etc. I think if it exists at-all it should be picked up and take precedence over the online translations.

One thing I noticed in the ODE environment was that (I'm pretty sure) the Cgov site translation was not listed until I ran the update. Makes me wonder if there is a race condition where the check isn't completing before the update is being called. The underlying drush commands can both execute in batch. I'm not sure if batch is asynchronous in this context, but if it is maybe we're dropping into updates before the check for new translations finishes? Executing those two commands manually should show if they do work given enough time between them.

(Note: the drush locale:update command itself is supposed to check for new translations if the last check is more than 600 seconds ago. But it's possible something about it being a new install messes with that logic.)

Anyhow, I'll stop poking around at this now. Definitely learned a lot about Drupal and how are deployments work, though. One other note, @VictoriaSunNIH, looks like this is still assigned to @suryatheja-muppalla and you may want to re-route it now.

NCIOCPL / cgov-digital-platform