🇩🇪 Error in the German translation? Report it here!

[Moin]

Should the headings all be translated? Currently, it’s not consistent

config/locales/server.de.yml

I compared this with a much older version. It doesn’t mention kneecap contradictions either

config/locales/server.de.yml

[Moin]

Does anyone have a good idea how to shorten these texts from the topic voting plugin?
Currently, “Stimme” (Vote) is the only one that isn’t too long. However, I find it hard to recognize that it’s an activity. Especially when a person has voted, I always read “1 Stimme” (1 Vote). For me, “Abstimmen” (Vote) would still fit as an alternative.

For “Geschlossen” (Closed), one could use “Beendet” (Ended).

But I haven’t thought of anything for “Abgestimmt” (Voted) yet.

Does anyone have an idea?

[tobiaseigen]

What is going on here, you think? On the badges “bulk award” page. My laptop is set to German locale but my discourse is set to english (us). Besides the mixed language issue, which I think we should try to fix, is there something else we can do with this UI to make it work better for long word languages like German?

[gerhard (Gerhard Schlager)]

Select File shows up because it’s a UI element provided by the browser. The browser uses the system language.

[gerhard (Gerhard Schlager)]

@Moin

For “Geschlossen” one could use “Beendet”.

@Moin

Does anyone have an idea?

How about “Gewählt” (Chosen)?
Or “Votiert” (Voted)? Rarely used, but in the Duden…

[Moin]

I noticed that the “about” link under Themes or Theme components was translated to “Über uns” (About us), like the texts referring to the /about page.

admin_js.admin.customize.theme.about_theme

However, in this case, it’s not about ‘us’, but about further information on the theme (component). I find using just “Über” (About) strange.
I then considered using “Dokumentation” (Documentation). If that were meant, the original could also have said “Documentation”. So that doesn’t quite fit either.
ChatGPT suggested “Info”, “Überblick” (Overview), “Details”, and “Mehr erfahren” (Learn more). “Mehr erfahren” (Learn more) is also used in many other places. For example, in the plug-in list, where similar things are linked. However, there is always a little text before it.
In a row with “Quelle” (Source) and “Lizenz” (License), I also find “Info” good.

Are there other ideas?

[thoka (Thomas Kalka)]

Would also suggest “Details”. That would also fit better non-translated.

[tobiaseigen]

Good catch I think the answer here is to provide a different string for the “about” text for theme components vs reusing the same string for “About” linking to the about page. I’ll make a note of it.

[Moin]

It is a different string

@Moin

admin_js.admin.customize.theme.about_theme

But the translation is the same. I think Crowdin automatically translates texts that are identical. So you need someone manually checking the context

[tobiaseigen]

Oh, thanks for letting me know that. Interesting. So it was just incorrectly translated into German.

Can you suggest a fix on crowdin? I think Details is not bad as a German translation of About in this case.

[Moin]

Done

I also tried to suggest “unbegrenzt” for the chat history (js.chat.retention_reminders.indefinitely_short) because for me “unbestimmt” sounds like “not defined”.

But I cannot suggest “unbegrenzt” because it has been suggested before.

[Moin]

I think it would be better to use a consistent translation for “topic map”.
Should we use “Themenübersicht” or “Themenkarte”?

[gerhard (Gerhard Schlager)]

@Moin

Topic Overview

That seems like the better choice to me.

[Moin]

I just saw that topic summary was chosen for the style guide. I suggest overview for both then

[xErrorAmelie]

Hello, I’ve noticed that Discourse uses the generic masculine everywhere. I would like to sit down and make the words gender-neutral. For example, the word ‘Benutzer’ (user) would become ‘Benutzer:in’. What do you think about that? Are there any better ideas?

[gerhard (Gerhard Schlager)]

Yes, unfortunately, that’s the case.
Just a few weeks ago, our translation agency asked if they should accept the proposed gender-neutral translations, and I reluctantly said no.

IMO the translators shouldn’t accept those changes for multiple reasons:

• It will break the UI in various places. Discourse already struggles with long German words, and it’s already difficult to fit “Benutzer” (user) in the UI in some places. Extending that to “Benutzer:innen” or “der/die Benutzer:in” will be a challenge.
• There are multiple styles for writing gender-neutral. For example, “user” could be translated as:
  1. Benutzer:in
  2. Benutzer*in
  3. BenutzerIn
  4. der/die Benutzer/in
  5. Benutzer und Benutzerin
  6. Nutzende

I can promise you that as soon as we start using one of those styles, people will complain that we are using the wrong style. They will also complain that we use gender-neutral language in the first place, but that’s a different story.
We had similar discussions about the usage of formal / informal language (Sie / du).

Don’t get me wrong. I’d really love to support a gender-neutral German language in Discourse. The same goes for formal language. But it should be up to the admins to decide what they want to use, not us.

And, keeping the current type of translation as default while allowing users to choose between informal/formal and gender-neutral or not, comes also with the benefit that we don’t break the UI for everyone at once. It would allow us the time to adjust the UI where long words don’t fit.

However, for that to work, we’ll need to support language variants in Discourse. Some years ago, I created a proof of concept plugin. It should be easy to integrate into core. But our Crowdin integration (translator-bot) will need changes to sync language variants. I estimate somewhere between 3–5 days of effort for that.

I don’t know when yet – time is unfortunately a scarce resource – but I intend to implement the necessary changes in Discourse and our integration with Crowdin this year, so that we can finally offer language variants (for German, this means du/Sie and at least one gender-neutral form).

[schneeland]

@gerhard

so that we can finally offer language variants (for German, i.e., du/Sie and at least one gender-neutral form).

A brief interjection at this point: if I understand correctly, the language variant would be set globally? Or would there also be the possibility for users to choose a variant individually?

[gerhard (Gerhard Schlager)]

Global order, if admins allow it, also by any user. So nothing will change in the existing language selection system. Only additional variants would be added.

[Moin]

How does Set locale from accept language header work then? If you activate this, will it probably always display German and not German (Sie) or German (Neutral)? Could I also see this forum in German (Neutral) if I am not logged in?

Would you have to decide as an admin whether everyone sees the forum in German (Sie) or whether the German-speaking business partners are addressed informally as long as they are not logged in, and in return partners with a different language preference see the forum in their preferred language?

Perhaps it makes sense to move the question about gender and the further discussion to another topic. They are not translation errors.

[Moin]

In English, the keywords in the admin sidebar are connected with an &. In German, however, we have u., &, and and. I already pointed out in the summer that space in the sidebar is limited anyway, and therefore I cannot understand why and is used instead of the &-sign. Unfortunately, I can no longer find the comments on Crowdin because the spelling in English has been changed in the meantime. The topic I created back then at the request of @mcwumbly still exists. Back then, and was changed to u. (and authentication abbreviated). However, this was not continued with further keywords.

I just saw that @gerhard suggested “Server & Protokolle” and now, after proofreading, the new version will likely be “Server und Protokolle”. Was it tested that this version is not too long? It seems to fit just barely.
Nevertheless, I don’t quite understand why we can’t use the &-sign like in the English original, or at least consistently stick to u. when there are already space problems.