Translations of theme component sample texts

Recently many official theme components were added to Crowdin.

This definitely improves the user experience for components like color scheme toggle where the tooltip is then offered in the user’s locale.

But for components which offer sample texts like the search banner, every added translation makes the customizing more complicated. Before, it was sufficient to add the text for the default forum language (and the English default) to change the text for all users. With every translation that is added, there is another version that has to be customized.

Detailed example

For this example, the site’s default locale is English (US) and the Discourse search banner. This is the default configuration:
image
Since there are no translations in the GitHub Repository, all users, no matter what locale they choose, see:
image


When I edit the default strings for English (US)
image

The theme translations for all other locales still show the default English US text
image

But the strings are overwritten for all locales, even those which still show the default text in the settings
image


After adding en_GB.yml with the same default strings to the GitHub repository, editing the strings for the site’s locale is not sufficient. The version of English GB is not affected by the change.
image

image

So now the admin has to adjust both versions, and the more translations are added, the more strings have to be customized.

My experience looking at sites with different default locales on Discourse Discover is that admins often only edit the text of the default locale. This means that with every translation that is added to the theme component, fewer users see the customized version.

That’s why I think translations for sample texts are less useful as long as there is no option to overwrite all translations at once.

3 Likes

“Admin → Appearance → Site Texts” behaves the same way. Customized text affects only the language you select. I get that this behavior will cause inconsistent UI or lots of work in some cases.

Currently there are only two options:

  1. Disable the allow_user_locale site setting. Every user will see the default language and thus the customized text.
  2. Customize the text for all the languages you care about.

I’m open for suggestions. I wonder if we should add a “force text override for all languages” option. I am not sure if this should be a global toggle or on a per-string basis. :thinking:

1 Like

I would suggest simply not translating components that only contain sample texts.

Maybe I’m missing the advantage, but in my opinion it makes customizing strings that are meant to be customized more complicated.

1 Like

I’m not familiar with those components. The example from search_banner that you posted seems like a good default, not just an example text.

2 Likes

Looking at Discourse Discover I have the impression that the text is often customized. For example many forums replace “community” with the name of their forum:

Screenshot_20240611_202204_Chrome
Screenshot_20240611_202132_Chrome
Screenshot_20240611_202117_Chrome
Screenshot_20240611_202100_Chrome
Screenshot_20240611_202037_Chrome
Screenshot_20240611_202001_Chrome
Screenshot_20240611_202418_Chrome
Screenshot_20240611_202406_Chrome
Screenshot_20240611_202334_Chrome

2 Likes

This forum is another example

One could get the impression that foreign-language users need to be prompted more urgently to use the search function

1 Like