Labels are not translated

I agree with @markie - we need instructions to manually test this or (better) an automated test written for it.

Writing *.schema.yml files is not my strong suit - does changing the type from "string" to "label" automatically make it translatable?

We are passing the values of more_text and more_aria_label to t() functions, but I don't see where we are doing that for trim_suffix values, are we sure that we need to change its schema from "string" to "label"?

-mike

does changing the type from "string" to "label" automatically make it translatable?

That's my understanding. If you look at core.data_types.schema.yml you can see how it's defined. Gabor's cheat sheet is super helpful and has a bit on translatability.

are we sure that we need to change [the trim_suffix] schema from "string" to "label"?

Apparently Chinese uses a different ellipsis so I guess it makes sense: ⋯⋯

Thanks!

Yes, I've worked on a module that used config translation, and changing "string" to "label" should be all that's needed in the schema.

However, I think that we should also look at wrapping the translatable values in the defaultSettings function with $this->t().

As I see it, the schema change is required to allow a Smart Trim configured field to work across multiple languages.

Using $this->t() would allow the language values default for the site to be set, and downloaded with a .po file.

However, I don't think it alone would allow a new Smart Trim field to automatically pick up multiple configurations per language, which would seem the ideal behaviour. By this I mean, if a site was in English and French, I don't think configuring a field to use Smart Trim on a field would automatically create configurations for both language, and the site builder would still need to use the config translation editor for each smart trimmed field.

But for a single language site in a language other than English, using $this->t() would mean that the translated strings would be used for the default configuration of each field, and save them from seeing English values every time they added a new Smart Trim.

I agree that an automated test would be desirable.

I think that we should also look at wrapping the translatable values in the defaultSettings function with $this->t().

I dunno (: I initially thought that it made sense to always have one language returned by a plugin's default settings and let the config translation system handle any conversions, but I'm really not sure. I looked around and found a few examples of translatable text not being run through t() but then came across paragraphs which does (and which I feel at this stage is probably quite well tested on the i18n front!). I've asked a Q about it in Drupal Slack #localize:

Hi, I'm looking into #3102324 🐛 Labels are not translated Closed: duplicate and had a question about translating plugin default settings. I know if you have any translatable plugin settings and the settings come from config, then the config itself needs to be declared translatable in its schema (eg. using label). However it's not clear to me in that situation if the default settings should provide translated settings or not (ie should you run things through t()).
I was imagining the answer would be no, and found some examples that seem to back that up (eg. \Drupal\Core\Field\Plugin\Field\FieldFormatter\TimestampAgoFormatter::defaultSettings()) but then noticed that paragraphs does. Can anyone help? Thanks!

Duplicate of 🐛 Regression: More Labels No Longer Translated Fixed .

-mike