"Authored on" string on multilanguage sites not translating; always renders English "ago" for "time ago" format

This should be config translation, at least its just using the formatter settings for this.

I try it work.

Setting
Field Content: Authored on
Formatter: Time ago

Display
English: 10 minutes 11 seconds ago
Chinese: 10 分鐘 16 秒 ago

Oh, I got! The "Ago" still here.

I too able to test it, "ago" word is still there

I can't find the position for render date, is there any possible position? Or possible overwrite way?

"core\modules\views\src\Plugin\views\field\Date.php" not work.
"core\modules\datetime\src\Plugin\Field\FieldFormatter\DateTimeTimeAgoFormatter.php" also tried.

I spot with Gabor, we found the issue needs to make @interval ago to be marked as label in schema iml file.

On top of that, Views has default settings for format, granularity and timestamp
out of which granularity is only available for export config.

Schema change should fix it.

It is not translated string. This text coming from settings form. Refer core/modules/datetime/src/Plugin/Field/FieldFormatter/DateTimeTimeAgoFormatter.php. What to do in this case?

Something like this?

Let's try one more time with the tests.

I applied patch #13 and still not translating "ago".

I think it fix this problem, and clear deprecated functions

Tested, the german version of the page shows the english translation for the "authored on".

This isn't right - configuration is translated using configuration schema. We need to tell the configuration system this is a translatable string and not use t().

Basically...

field.formatter.settings.timestamp_ago:
  type: mapping
  label: 'Timestamp ago display format settings'
  mapping:
    future_format:
      type: string
      label: 'Future format'
    past_format:
      type: string
      label: 'Past format'
    granularity:
      type: integer
      label: 'Granularity'

Needs to change to

field.formatter.settings.timestamp_ago:
  type: mapping
  label: 'Timestamp ago display format settings'
  mapping:
    future_format:
      type: text
      label: 'Future format'
    past_format:
      type: text
      label: 'Past format'
    granularity:
      type: integer
      label: 'Granularity'

IE. the types need to change to 'text' - which will indicate to the configuration system and localize.drupal.org that this is a translatable string.

+++ b/core/lib/Drupal/Core/Field/Plugin/Field/FieldFormatter/TimestampAgoFormatter.php
@@ -187,13 +187,13 @@ protected function formatTimestamp($timestamp) {
+        '#markup' => new FormattableMarkup(t($this->getSetting('past_format')), ['@interval' => $result->getString()]),

Also just fyi... if t() was the right answer here (and it's not) then just using $this->t() instead of FormattableMarkup(t()) would be the way to go... ->t() returns a TranslatableMarkup object which is a markup object like FormattableMarkup and what SafeMarkup::format() returns.

I'd just like to note that neither of these work:

    past_format:
      type: text
      label: 'Past format'

    past_format:
      type: string
      label: 'Past format'
      translatable: true

I've tried both ways and the '@interval ago' still refuses to show up in the interface translation.

alexpott #22, thanks. Upd patch

Oops, some went wront.I'm so sorry for it. I download last dev version and renew patch.

Updated patch because previous patch failed to apply.

@alexpott said this is not the right approach. Please read #21.

Thanks @dagmar - please review updated patch taking consideration comment #21 & also added interdiff.

@Yogesh Pawar: Thanks, but I think this is not the right approach.

#21 says:

We need to tell the configuration system this is a translatable string and not use t().

Is worth to mention that not use t() also implies not use $this->t() which is the same.

@dagmar - thanks for your suggestion, i have removed the usage of t() & $this->t(), changes done as per comments #35 & #21

I just do my own work. It is working, you must filter for "@interval ago" and translate that text something like: "hace @interval" (same for "@interval hence").
Not apply other path. I only modified one file from original Drupal 8.3.2 (I don't know if it is already solved in 8.4 dev branch but my solution is simple and clean):

Diff output for the file /core/lib/Drupal/Core/Field/Plugin/Field/FieldFormatter/TimestampAgoFormatter.php

6a7
> use Drupal\Core\StringTranslation\TranslatableMarkup;
97,98c98,99
<       'future_format' => '@interval hence',
<       'past_format' => '@interval ago',
---
>       'future_format' => new TranslatableMarkup('@interval hence'),
>       'past_format' => new TranslatableMarkup('@interval ago'),

Attached patch uses FormattableMarkup to create the string. There is no need for TranslatableMarkup, since the string will be translated by Config translation.

Patch in #41 applies ok and makes the future_format and past_format translatable.

I couldn't see the 'settings' tab in the views UI for my fields that were using timestamp_ago though, so I was confused at first and thought it wasn't working. However, when I manually edited the .yml files and put this in to the English (primary) language config:

settings:
            granularity: 1
            future_format: '@interval hence'
            past_format: '@interval ago'

then the settings appeared in the Translate View UI.

Please help me out here. I've applied the patch in #41. When I go to /admin/config/regional/translate the string "@interval ago" does not show up. Please explain to me step by step what I need to do.

This is what I did:
* apply patch #41
* go to /admin/config/regional/translate and searched for @interval and also for ago. All instances I found were already correctly translated.
* My view still show 38 minuten en 15 seconden ago.

I really need to be able to translate this!

@Bartelli, the translation comes from the translated view entity rather than the global interface translation strings. See the comment in #42 - to make it work, I had to manually edit the yml file.

@nicrodgers, you comment would be so infinitely more helpful if you could elaborate on the location of “the” yml file.
Thanks!
#33 works for the moment.

1. +++ b/core/config/schema/core.entity.schema.yml
   @@ -330,10 +330,10 @@ field.formatter.settings.timestamp_ago:
      mapping:
        future_format:
   -      type: string
   +      type: text
          label: 'Future format'
        past_format:
   -      type: string
   +      type: text
          label: 'Past format'
   

   type: label is a one-line translatable string, text is multi-line.

2. +++ b/core/lib/Drupal/Core/Field/Plugin/Field/FieldFormatter/TimestampAgoFormatter.php
   @@ -187,13 +187,13 @@ protected function formatTimestamp($timestamp) {
          $result = $this->dateFormatter->formatTimeDiffSince($timestamp, $options);
          $build = [
   -        '#markup' => SafeMarkup::format($this->getSetting('past_format'), ['@interval' => $result->getString()]),
   +        '#markup' => new FormattableMarkup($this->getSetting('past_format'), ['@interval' => $result->getString()]),
          ];
   

   This should not be necessary, using the correct schema should automatically make it translatable through config translation.

Settings to 'Needs work' per #48

#48 should be taken care of, and fixed schema for the datetime version.

@mpdonadio at #50 regarding @berdir #48 did not made it translatable to me. Neither did #41.

I had to do the following (patch attached) to get it translated.

This is wrong and not secure. The value of that setting will then not be escaped and can contain anything, including javascript.

The change isn't meant to make it translatable through interface translation but configuration translation. The problem is that formatter/widget settings aren't properly exposed in config translation, there's an old issue about that.

@berdir, is this the issue you're referring to? #2546212: Entity view/form mode formatter/widget settings have no translation UI

If so, then theoretically, the latest patch from ^^ that issue, combined with the patch from #50, should resolve the issue satisfactorily.

@charginghawk I tried your suggestion in your last comment and didn't work for me (D 8.6.1). I applied the two patches and still couldn't find a place to translate "ago"

As per @Berdir 's comment #48, I applied the change in core.entity.schema.yml (string > text) and the TimestampAgoFormatter.php was already changed in core but that didn't make any difference either. The field is still untranslatable

UPDATE: I tried as per comment #42 by @nicrodgers, edited the views.view.content_recent.yml for the Recent Content view e.g. and still no luck !

On a side note: I'm not a programmer but, having seen how long this issue has been on table, I'm shocked that such a tiny "thing" takes so long (years) or is so complicated to get fixed !

In the mean time a custom field formatter can solve it. The following just print the translated time ago (past) format. For newbies, copy and paste into a custom module field formatters folder, such as "www/modules/custom/custom_module/src/Plugin/Field/FieldFormatter/TimestampAgoFormatter.php"

<?php

namespace Drupal\custom_module\Plugin\Field\FieldFormatter;

use Drupal\Core\Field\Plugin\Field\FieldFormatter\TimestampAgoFormatter as CoreTimestampAgoFormatter;
use Drupal\Core\Cache\CacheableMetadata;

/**
 * Custom plugin implementation of the 'timestamp' formatter as time ago.
 *
 * @FieldFormatter(
 *   id = "custom_module_timestamp_ago",
 *   label = @Translation("Time ago (custom)"),
 *   field_types = {
 *     "timestamp",
 *     "created",
 *     "changed",
 *   }
 * )
 */
class TimestampAgoFormatter extends CoreTimestampAgoFormatter {

  /**
   * Formats a timestamp.
   *
   * @param int $timestamp
   *   A UNIX timestamp to format.
   *
   * @return array
   *   The formatted timestamp string using the past or future format setting.
   */
  protected function formatTimestamp($timestamp) {
    if ($this->request->server->get('REQUEST_TIME') > $timestamp) {
      $granularity = $this->getSetting('granularity');
      $options = [
        'granularity' => $granularity,
        'return_as_object' => TRUE,
      ];
      $result = $this->dateFormatter->formatTimeDiffSince($timestamp, $options);
      $build = [
        '#markup' => $this->t('%time ago', ['%time' => $result->getString()]),
      ];
      CacheableMetadata::createFromObject($result)->applyTo($build);
    }
    else {
      $build = parent::formatTimestamp($timestamp);
    }

    return $build;
  }

}

Drupal 8.6.7

Applying manually the patch to the two schema.yml files as in #50 mpdonadio (2639382-50 patch) is working for me now.

Those 2 files are:

• core/config/schema/core.entity.schema.yml
• core/modules/datetime/config/schema/datetime.schema.yml

The "problem" could be easily fixed for the next Drupal update.

You only have to replace the word "string" with "label" under the "type" of "future_format" and "past_format" in both files mentioned above. Done!

Nothing has to be changed in the file core/lib/Drupal/Core/Field/Plugin/FieldFormatter/TimestampAgoFormatter.php, because the necessary changes are already made in that file.

Thank you @alexpott for the advice on this. Updated patch with the config update only as the change to the TimestampAgoFormatter is not actually necessary. Removing 'needs tests' as tests are no longer needed when just schema change.

Steps to translate successfully with just the schema change:

1. Add the second language (I added Dutch)

2. Translate configuration of '1 second', '@count seconds', '1 minute', '@count minutes', etc in Interface Translation:

3. Translate configuration of view (to translate the 'ago') via Configuration Translation > View > Your View:

And the end result, fully translated string:

If you wanted to shift works around, like moving the 'ago' infront of the interval, that can be done in the the Configuration Translation of the view like 'Ago @interval' and if you would want to move the word 'second' infront of the number for instance, that could be done in the Interface Translation like 'second 1' and 'seconds @count', so I believe all situations are covered by this but good to get input from others. In any case, we have more translation flexibility then before with this patch.

And the patch and interdiff

#60 works for date field in views, but not for regular field display. Even with #2546212-93: Entity view/form mode formatter/widget settings have no translation UI, date formatter settings can not be translated due to a similar issue in the datetime module. This issue is assigned to the views.module component, so the patch is OK and a new issue should be added for the same thing but in datetime module.

@manuel.adan It should also be translatable. I am not sure where to find it in the UI, but with the patch applied, if I do this:

1. Add a field 'field_timestamp' to 'page' node type
2. Set manage display for the field to 'time ago'
3. Run `config-export`
4. Copy `/path/to/config/sync/core.entity_view_display.node.page.default.yml` to `/path/to/config/sync/language/nl/core.entity_view_display.node.page.default.yml` (for example for Dutch)
5. Edit the latter config to be '@interval geleden' instead of '@interval ago'

I then get this on the front-end (ie, correctly translated):

One place was overlooked.

#63, it works with timestamp field type, not datetime. #64 patch solves it for datetime, but as previously mentioned, not sure if a new issue should be added since it is a different component.

I have no issue fixing both here.

Glad to see this fixed properly :-)

Closed #3071897: Time ago formatter untranslatable as a duplicate issue.

+++ b/core/config/schema/core.entity.schema.yml
@@ -337,10 +337,10 @@ field.formatter.settings.timestamp_ago:
-      type: string
+      type: label

Does this need an empty update /post update hook to trigger a cache clear?

For #70

@larowan, I've seen many of these patches but none of them performs a cache clear. I suppose a cache clear is part of most deploy scripts.

#72 Can you find a link to a similar issue? It would be interesting to see the discussion / consideration in earlier issues.

In this case Drupal will still be functional without a cache rebuild, unlike adding a new argument to a class constructor for example. I agree we can probably do without.

Some quick examples of issues about scheme patches to make properties translatable:

• Drupal core: Support translation of the list of styles in CKEditor
• Paragraphs: Make widget labels translatable
• Admin Toolbar (reviewed by Gábor Hojtsy): Config labels are not properly translated

Since a lot of developers don't seem to be aware of the type: label shorthand, I also updated the documentation for the translatable property here:
https://www.drupal.org/docs/8/api/configuration-api/configuration-schema...

#74 Cheers, #3063020: Support translation of the list of styles in CKEditor seems a good reference for leaving out an empty post_update hook. RTBC+1

@mpp+++++++ for #75!

Thanks, I looked at those issues and you're correct, there's no update hook - but should we be adding a test here? We would ordinarily require a test for a bugfix.

translating something according to its content is already a complication issue. keeping that in mind, the translation mechanism is already highly customizable, and one solution does not have to fit all. At least I am getting well with languages with right to left direction, like Arabic and Hebrew.

In the case of the time format in some common areas, like: "Submitted by...", In case that is not already translated or you are not satisfied with it, you can translate that by going to:
admin/config/regional/translate , and searching there for the "Submitted by" , Remember this is a case sensitive search. Also pick language you are translating for in the "translation language" field and pick "both translated and untranslated strings" in the "Search in field"; just in case you want to change already translated string to something else.
Most likely the following string will pop up:
Submitted by @author_name on @date

In the target language (in my case it is of direction right to left, otherwise the order is the same) , either type your intended translation in the order of your typing without keeping attention how it looks ,it will look messy but Drupal render it correctly later on according to the language, or else change the direction of typing (In firefox Ctr-Shift+X, in Chrome Left-Click> Writing Direction> RTL)and view what you are typing. Place @author_name and @date where they should fit in that language.

In some languages Day and Hour (and many contextual form of that) might be already translated while others (like Seconds and Minutes) are not yet. In that case, just type for instance "second" in case that is missing, and translate it in a way similar to the case of "hour" while keeping the syntax of the language as correct as possible. Just use the word @count as is.

If all that is already done, the only place where i was using Time Ago format was in the Views, in a place like "Authored On" Field.
If I create a View for something, and by adding for instance an "Authored on" field, I got away with following:

First I chose the format, by editing View>View-To-Edit>Edit>Field(Here "Authored on").
In the settings of that Field ("Authored on"), I change the label to "Authored since". But when translating I will do with more relevant sentence. Keeping in mind that the answer in time in English is like: 2days 4hours, and with an answer similar in the other language.
In the Formatter I will keep Time Ago, in the Future format I replace @interval hence with @interval and in Past format I change @interval ago to just @interval.
The problem with "ago" translation emerges here when trying to to search for "ago" string in the previous method; among the results of that search is that %time ago , but translating that has no effect on the view here.
The only solution I could find was translating and changing "Authored on" title accordingly as I said, in the View area; View>Translate(tab) and then opening all the collapsed titles translating that "Authored on" Title to something meaningful.
The end result in View is like: (lets say in French)
Title: "Publie depuis" , Date: 2jours 4heurs. While in English: Tilte:"Published since" , Date: 2days 4hours.
As you can see, the translation and the way I did things won't let me keep the "ago" word for the English version wihile hiding it from the French one..

This patch for 8.9 and it works for me.

This is for 9.1

Confirming #64 works great for me. As the discussion above states, this should be handled as configuration translation, rather than UI.

Works for me. Thanks!

I think the patch #64 from @mpdonadio is the correct approach.
I've uploaded the patch with the test cases.

I've taken interdiff with that patch only.
For now, I'm keeping the needs tests tag as I need some inputs on whether this test is sufficient or not.

Looking really good!

Mostly just some comment nitpicks/suggestions. But we should expand the test to cover the future format change too.

1. +++ b/core/modules/config_translation/tests/src/Functional/ConfigTranslationViewListUiTest.php
   @@ -60,4 +64,43 @@ public function testTranslateOperationInViewListUi() {
   +    // Update view to set the field formatter.
   

   Update the view ....

2. +++ b/core/modules/config_translation/tests/src/Functional/ConfigTranslationViewListUiTest.php
   @@ -60,4 +64,43 @@ public function testTranslateOperationInViewListUi() {
   +    // Add the views translation.
   

   "Add a translation to the views configuration for the past and future formats."

3. +++ b/core/modules/config_translation/tests/src/Functional/ConfigTranslationViewListUiTest.php
   @@ -60,4 +64,43 @@ public function testTranslateOperationInViewListUi() {
   +      'translation[config_names][views.view.content][display][default][display_options][fields][changed][settings][future_format]' => '@interval hence',
   

   We should also add a test for the future format change

4. +++ b/core/modules/config_translation/tests/src/Functional/ConfigTranslationViewListUiTest.php
   @@ -60,4 +64,43 @@ public function testTranslateOperationInViewListUi() {
   +    // Create one past time stamp, so we can update node's updated field.
   
   index a00901160b..44783bdbef 100644
   --- a/core/modules/datetime/config/schema/datetime.schema.yml
   

   "Create a timestamp just over an hour in the past and set the nodes update time to this."

5. +++ b/core/modules/config_translation/tests/src/Functional/ConfigTranslationViewListUiTest.php
   @@ -60,4 +64,43 @@ public function testTranslateOperationInViewListUi() {
   +    // Translation of "hour" string is english only, as all the strings'
   +    // translations are not uploaded.
   

   "Not all normal string translations are available, so 'hour' is still in English."

Addressing all 5 suggestions mentioned in the comment #91

Nice, just some nits left

1. +++ b/core/modules/config_translation/tests/src/Functional/ConfigTranslationViewListUiTest.php
   @@ -60,4 +64,56 @@ public function testTranslateOperationInViewListUi() {
   +      'future_format' => '@interval hence',
   ...
   +      'translation[config_names][views.view.content][display][default][display_options][fields][changed][settings][future_format]' => '@interval hence',
   ...
   +    $this->assertSession()->pageTextContains('1 hour hence');
   

   Can we make the translation be something else then the English version?

2. +++ b/core/modules/config_translation/tests/src/Functional/ConfigTranslationViewListUiTest.php
   @@ -60,4 +64,56 @@ public function testTranslateOperationInViewListUi() {
   +    // Create a timestamp just over an hour in the future and set the nodes update
   +    // time to this.
   

   Dreditor indicates this is over 80 characters but that might not be true, it's been wrong before I think....

Fixing few more suggestions from #93

Looks good to me now, thanks!

Updated the IS to mention the proposed fix and the discussion on having an update or not.

Fixing issue credit - which is now correct as far as I can see.

@mohit_aghera please add all the schema changes from #64 here. Yes the datetime ones might not be tested but fixing one without the other makes no sense. Once the changes that were removed from #64 you can re-rtbc the patch.

@Lendude pointed out that the datetime schema stuff is there. Nice....

Committed 117168a and pushed to 9.3.x. Thanks!

diff --git a/core/modules/config_translation/tests/src/Functional/ConfigTranslationViewListUiTest.php b/core/modules/config_translation/tests/src/Functional/ConfigTranslationViewListUiTest.php
index fb8f779905..c8bae85e9f 100644
--- a/core/modules/config_translation/tests/src/Functional/ConfigTranslationViewListUiTest.php
+++ b/core/modules/config_translation/tests/src/Functional/ConfigTranslationViewListUiTest.php
@@ -6,6 +6,8 @@
 use Drupal\Tests\views_ui\Functional\UITestBase;
 use Drupal\views\Views;
 
+// cspell:ignore später
+
 /**
  * Visit view list and test if translate is available.
  *

Let's inline the addition to the dictionary. Fix on commit.