How do translators add those keywords? In my experience, empty strings are not shown for translation in Crowdin.
@pento What real-world problem is this supposed to solve? As Moin mentioned, empty strings do not show up on Crowdin, so they canât be translated. Also, in my experience, translators do not have enough knowledge to come up with keywords that do not exist in the English source file.
If we want translators to add new keywords, then we need clear instructions on each string how and why they need to come up with new keywords, and the strings must not be empty. IMO we shouldnât put this task on the shoulders of translators.
Thanks for asking about this one, Moin!
Youâre absolutely right, empty strings are hidden by default in Crowdin. It looks like I can update our string syncing bot to make them visible, however.
Good point Gerhard, the purpose of this is a bit confusing. Hereâs a PR where Iâm looking at providing additional context for each keyword entry:
Iâm not sure how we can add keywords for every site setting in English that arenât mostly redundant, however. Settings search already does a simple match against any substring of the setting name (eg, searching for âavatarâ will also show âgravatarâ settings), so there arenât many settings that could use additional manually defined keywords.
Just the ones for the keywords or all the empty strings? There are more empty strings, so this could cause confusion. When does it make sense to âtranslateâ an empty string, and when is it intentional that it remains empty?
My idea when I saw the PR was to add a translation of the name of the setting. Sometimes words from the settings name arenât repeated in the description, so itâs more difficult to find them with a non-English interface language. At the moment, I usually change my interface language to English before I search because then I can find results from the settings name and description with just one search.
A simple example is searching for âwhisper.â As long as my interface language is English, I can find two settings because âwhisperâ is part of the name in one and mentioned in the description in the other:
whispers allowed groups
Allow private communication within topics for members of specified groups.
create post for category and tag changes
Create a whisper post when a topicâs category or tags change, requires whisper posts to be enabled.
I cannot do the same while my interface is in German. I can use âwhisperâ to find the first one and âflĂźsterâ to find the second one. But there is no way to find both. If the name of the setting was added as a keyword and translated, searching for âflĂźsterâ would return both. This is even more relevant for all settings where, for example, âemailâ is only part of the name but not mentioned in the description.
Maybe adding the name as a keyword would make this more obvious. Is that a problem for English if the name is also a keyword?
But I am not sure how to find other useful keywords. I see that your PR adds the English description for context (with a lot of quotation marks), but that still doesnât tell me what might be missing in the German translation. What else did you have in mind? Everything I can think of, like having âpersonal messageâ as a keyword for all settings that use âPMâ in their name and description, would probably be helpful for all languages. But with the current implementation, every translator would have to think of that themselves and add it.
Honestly, I think adding keywords is a losing battle. This might be a good case for AI, which could look up settings based on related words in multiple languages.
I think the most helpful aspect for search is a consistent translation. As long as âtagâ is always translated with âSchlagwort,â you donât need to add that as a keyword. (In cases where it is not, like site_settings.remove_muted_tags_from_latest
, itâs better to improve the translation.) And in cases where a keyword is used in the English description, itâs probably also helpful to have it in the German one. So, in the case of the description of contact email
:
English
Email address of key contact responsible for this site. Used for critical notifications, and also displayed on /about. Visible to anonymous users on public sites.
German
E-Mail-Adresse einer verantwortlichen Person fĂźr diese Website. Wird verwendet fĂźr kritische Benachrichtigungen und unter /about angezeigt. Sichtbar fĂźr anonyme Benutzer auf Ăśffentlichen Websites.
The German translation could be improved so that âKontaktâ is included, and searching for it returns the setting. However, this wonât help for site contact group name
and site contact username
because the English description does not contain âcontactâ; itâs just part of the name. In this case, a translated setting name would help. It would be even more helpful if it was not just a keyword, but if both the setting name and its translation were visible in the interface. Because the additional context the setting name provides is not only helpful for search but also for understanding the description of the setting.
Many years ago we decided against translating setting names because it is a support nightmare. If people ask questions and mention translated setting names, you have to go look it up, before you can help them. Also, translations change over time. Renaming English setting names is already a burdon, supporting numerous translated settings will be overwhelming. So, we need to come up with a solution that improves settings for localized sites, while keeping the simplicity of having setting names only in English.
I had something like this in mind:
Though that would require quite a bit of space. So maybe a which shows the translation on hover or tap and hold would fit better.
But then, users who do not understand English would have a similar chance of understanding what âNumber of flags from other users before being warnedâ refers to and who will be warned.
I would like to have two language settings, separate languages for backend and frontend.
But what I still actually want is fast language switcher.