Log error when a TranslatableMarkup is created with a non-string input

I am also getting the same error

any help, please let me know

@juhaszg, have you able to resolve this issue ?

Many Thanks
-Jatin

The problem seems to be that the __construct() function call in the TranslatableMarkup.php class, called TranslatableMarkup, is not properly handling a case where translation is disabled and NULL is (automatically?) passed to the translate function.

It might be a good idea to handle the case of NULL as a string.

I suggest adding an if is_null() and manually convert NULL to an empty string.
There should be no reason to fail on NULL, in my opinion.

I have provided a patch as a work around that converts NULL to a string.
The real solution should be to determine why NULL is making to this __construct() and then determine if that should or should not be allowed.

FYI: I came across this on drupal 8.3.7.
I have not (yet) checked to see if this is resolved in later versions.

Also got this error after upgrading from Lightning 2.1.7 to 2.1.8.

Thanks for the patch @thekevinday! Agreed that the patch is probably fixing the consequence of a problem rather than its root.
Meanwhile, I had to adjust the patch #6 because I was getting:

InvalidArgumentException: $string ("0") must be a string.

I will try and do some research as to why this is happening in the first place.

Just realised that empty() function would catch NULL as well. Updated patch attached.

Ugh, I probably should test my patches before submitting. Apologies.

RTBC

Still testing ... Seems that the fix is not working.
not sure if the patch will fix the issue in most cases.

After some troubleshooting:
Seems the issue with plugin_id: text_custom in config
if plugin_id: text we will not have this issue.

In case anyone else end up on this ticket when they visit the "admin > Appearance" from your own custom theme.

This issue I had which caused this bug is leaving a blank description in the custom-theme.info.yml file. Adding in a description resolved the issue.

Reverting the previous issue version change.

The issue I'm running into is that NULL is being passed to the function as the string. Not sure how to fix it, or where the NULL is coming from, but hopefully this helps someone.

i am also getting something like same issue,

ResponseText: The website encountered an unexpected error. Please try again later.InvalidArgumentException: $string ("1") must be a string. in Drupal\Core\StringTranslation\TranslatableMarkup->__construct() (line 132 of core/lib/Drupal/Core/StringTranslation/TranslatableMarkup.php). Drupal\locale\LocaleConfigManager->getTranslatableData(Object) (Line: 167)

can you help anyone,

Thanks,
--Mani.

Added a patch that worked for me, but not sure if it's the appropriate fix. From what I could tell, NULL was being passed in explicitly, so setting the default value of $string to '' wasn't working.

Thank you so much @emclaughlin.

I explain my problem: I create a sub-theme, I install it and everything is ok.
But when I go to visit the site it returns the error as above.

I have apply patch in #26 and its ok now.

I use Drupal 8.7.2 and hope they can update the drupal core with this patch.

Hi, everyone
I also had same problem. I was building theme settings translation (seems like nobody done this since 8.0 release?)

socks.schema.yml

socks.settings:
  type: theme_settings
  label: 'Socks theme settings'
  mapping:
    socks_phones:
      type: text
      label: 'Phones'
      translatable: true

socks.settings.yml

socks_phones:
  value: "## phones"
  format: full_html
  langcode: en

socks.config_translation.yml

socks.settings:
  title: 'Socks theme settings'
  base_route_name: system.theme_settings
  names:
    - socks.settings

And when I hit "save" on admin/appearance/settings/translate/uk/edit - I get error like in subject

So what I had to do (and it worked fine, translation was saved and renders per each language) is

@core\lib\Drupal\Core\StringTranslation\TranslatableMarkup.php

  public function __construct($string, array $arguments = [], array $options = [], TranslationInterface $string_translation = NULL) {
    if(is_array($string)) {
      $options = $string;
      $string = $string['value'];
    }
....

This is patch is used to check if it is a string or not and was working when I performed site install.

Apologies members, due to some project commitments not able to work hence unassigned without any inputs.

I have drupal 8.9.2, getting error InvalidArgumentException: $string ("") must be a string. in Drupal\Core\StringTranslation\TranslatableMarkup->__construct() (line 132 of /var/www/html/core/lib/Drupal/Core/StringTranslation/TranslatableMarkup.php).

I am getting this error on Drupal 8.9.1 also:
InvalidArgumentException: $string ("0") must be a string.

I am uploading another patch, similar to #26, but using an empty() function instead of the is_null().

Anyway, I still don't know the root cause of the problem.

***EDIT***
Editing my own comment to avoid confusion, I am not using this patch so I will make no comment on it.
for my particular issue the string translation I was looking to fix did not need fixing so I didn't need a twig workaround , just had to use the configuration translation and dig down a bit to find and translate it.
***END EDIT***

Just my 2 cents here as I also stumbled into this.

The actual issue here is that Drupal\locale\LocaleConfigManager::getTranslatableData passes data directly to TranslatableMarkup constructor without checking what it is or converting it into the string.

In my case schema defined float type value and I was getting:

InvalidArgumentException: $string ("1") must be a string

I think none of the patches here solves the issue.

InvalidArgumentException: $string ("Array") must be a string. in Drupal\Core\StringTranslation\TranslatableMarkup->__construct()

when a views block was rendered. Caused by
{{ label|t }} in my block.html.twig

Solution: created block--views.html.twig and rendered the label without translation {{ label }}

Also getting this error, on Drupal 9.1.4. Haven't tried all the patches, but #26 does not work for me.

I had a similar error:

InvalidArgumentException: $string ("100") must be a string

which I figured to be an issue with a config module's schema

it's in easy_breacrumbs schema:

    truncator_length:
      type: text
      label: 'Set the limit for truncation.'

vs in config:
truncator_length: 100

hope this helps someone else with a similar error

and BTW, I agree with @pmate that this should probably be fixed in Drupal\locale\LocaleConfigManager::getTranslatableData

I have the same issue with NULL value in $string and the error text with one difference word "array" changed to nothing "".
TranslatableMarkup for Invalid Argument Exception: $string ("") must be a string.
And I don't imaging where from this NULL string are coming.

Added a check in Drupal\locale\LocaleConfigManager::getTranslatableData as suggested in #37 in this patch, please verify.

Above patch works fine

Tests will make this issue easier to understand.

The patch #42 doesn't work form me (Drupal 9.3.6). My error is:

Si è verificato un errore inatteso. Riprova più tardi, grazie.

InvalidArgumentException: $string ("Modulistica") must be a string. in Drupal\Core\StringTranslation\TranslatableMarkup->__construct() (line 133 of core/lib/Drupal/Core/StringTranslation/TranslatableMarkup.php).

I experience the same issue on core 9.4.5 on both php 7.4 and 8.1, it occurs on drush locale:update

Patch for 9.5

We had the same problem but the pmkanse fix works in latest version: 9.5.7

Facing this issue in Drupal 10.1.0-beta1

We are facing this issue on Drupal 9.2.20, I didn't saw the version support for it so created a new for it.

Came here from #2730807: WSOD on admin/modules if description is set but is NULL in module.info.yml, where this was raised as a possible fix, but this seems unrelated.

Here is a test for this.

This problem arises when a config item is marked as translatable or uses a translatable type such as 'label', but contains something other than a string. #28 is a good example of this where schema says its a sting and the config is an array.

1. +++ b/core/lib/Drupal/Core/StringTranslation/TranslatableMarkup.php
   @@ -127,6 +127,7 @@ class TranslatableMarkup extends FormattableMarkup {
      public function __construct($string, array $arguments = [], array $options = [], TranslationInterface $string_translation = NULL) {
   +    $string = !empty($string) ? $string : '';
   

   We should not be changing TranslatableMarkup

2. +++ b/core/modules/locale/src/LocaleConfigManager.php
   @@ -175,7 +175,7 @@ protected function getTranslatableData(TypedDataInterface $element) {
   -      if (!empty($definition['translatable']) && $value !== '' && $value !== NULL) {
   +      if (!empty($definition['translatable']) && (($value !== '' && $value !== NULL) && is_string($value))) {
   

   Do we want to be fault tolerant here and just skip this? Or should we throw something to indicate something it trying to translate something untranslatable? The currently suggested fix would leave users without any indication that anything is wrong. But it doesn't necessarily feel like locales responsibility to inform about faulty config

This implements the previous proposed fix of skipping the faulty config, but somewhat refactored.

+++ b/core/modules/locale/src/LocaleConfigManager.php
@@ -175,7 +175,7 @@ protected function getTranslatableData(TypedDataInterface $element) {
+      if (!empty($definition['translatable']) && $value !== '' && is_string($value)) {

As there are some discussions (#2275865: Per language settings (vs translated settings) are not directly supported) around how to localize configuration (even when they are not strings) and this is subject to change, I would use !is_array instead of asserting for is_string().

Even if we never promised to support that you can translate non-labels, I'm pretty sure people is doing that in custom or even contrib modules. This could break their assumptions, which might be ok-ish but we should avoid if we can.

Fixing the failing test.

@penyaskito thanks for linking that, hadn't seen that issue yet. In this case though, the current way getTranslatableData works will always send the value to TranslatableMarkup and since that does this:

    if (!is_string($string)) {
      $message = $string instanceof TranslatableMarkup ? '$string ("' . $string->getUntranslatedString() . '") must be a string.' : '$string ("' . (string) $string . '") must be a string.';
      throw new \InvalidArgumentException($message);
    }

anything that can't get passed is_string() will cause an exception. So I think keeping the check in getTranslatableData the same as in TranslatableMarkup would be the best way to prevent the exception. Should we change in the future what we allow to be translated, we probably need new logic here anyway.

But again, I'm not 100% convinced that preventing the exception is the right thing to do here. It's just that the current exception makes it very unclear what is going wrong. I'd be totally on board with catching the current exception and re-throwing it with a clearer message that a specified config setting can't be translated or something along those lines.

@penyaskito So yeah, maybe we shouldn't use is_string, but catch the exception? That way the logic of what can be translated stays within TranslatableMarkup and any changes would work in getTranslatableData too....

Sill leaves the question about what we want to do if we catch that exception, silently move along or log something or rethrow it?

@Lendude think something should be logged and move along.

Lot of my sites I routinely check the logs for issues and know that's when I would fix that.

Ok lets log something!

This requires the logger factory to be added, so added a deprecation and change record for that.
Added test coverage for the error.

Not sure about the wording of the error, best I could come up with.

Fix the last test

Logged addition looks good.

I think this is the best we can do for having _some_ error handling while still not breaking what people might be doing as in #60. Thanks!

Might be good having a summary update, or at least a title update. I tried to do that, but suggestions welcome.