The discussion revolves around translations of theme component sample texts in Discourse. Moin highlights that adding translations for components with sample texts can make customization more complicated. For instance, if an admin edits the default strings for the site’s locale, it will not affect other locales that still show the default text.
Moin suggests that translations for sample texts are less useful without an option to overwrite all translations at once. gerhard agrees that the current behavior can cause inconsistent UI or lots of work and proposes adding a “force text override for all languages” option.
Moin suggests not translating components that only contain sample texts, as it makes customizing strings more complicated. However, gerhard disagrees, citing the search banner as a good default text.
Moin provides examples of forums customizing the search banner text, replacing “community” with their forum’s name. Moin shares another example of a forum with customized search banner text, suggesting that foreign-language users may need more urgent prompting to use the search function.
Overall, the discussion raises concerns about the complexity of customizing theme components with multiple translations and explores potential solutions, such as adding a force override option or not translating 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:
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.
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.
“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:
Disable the allow_user_locale site setting. Every user will see the default language and thus the customized text.
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.
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:
