Open VictoriaSunNIH opened 3 years ago
Approach:
Cc: @VictoriaSunNIH @bryanpizzillo
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.
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
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.
Closing this ticket - this is no longer an issue on prod.
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.
Spanish dates have returned to uppercase. e.g. https://www.cancer.gov/espanol/cancer/naturaleza/que-es
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.
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:
.po
file first like it does with the updates? So I think you don't need a code fix. You'll just need to run the translation updates. And maybe clear caches.
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.
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"
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?
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