This discussion revolves around adding support for formal and informal language variations in Discourse, particularly for languages like Dutch, German, and Hungarian that have a T-V distinction. Sander78 initiated the topic, noting that current i18n systems don’t support such distinctions and proposing separate locale files (e.g., client.nl_formal.yml, client.nl_informal.yml). neil expressed unfamiliarity with the concept, while elberet and others confirmed similar challenges in German. Suggestions included moving translations out of core and into plugins, or using a mapping layer to trick Rails I18n. fantasticfears and sam supported the idea, noting its importance for user experience. nyro later revived the thread, highlighting the need for formal German in their community. The discussion also explored whether Transifex (later replaced by Crowdin) could support such variants via regional or custom tags (e.g., de_formal, de_informal). Tgr emphasized the cultural sensitivity of mismatched forms, and icaria36 noted Crowdin’s support for regional variants, suggesting admins could create custom ones like “Hungarian (Informal)” and leverage auto-filling for non-differing strings. The consensus is that while technically feasible, it requires infrastructure changes and community buy-in. A formal/informal toggle would enhance localization for many languages, especially where tone affects user perception and engagement.
In some languages (Romanic and Germanic for example) there are significant differences between formal and informal speech. Right now I made the whole Dutch translation informal, but I can imagine some people might want to have a formal version.
Could Discourse support this in the future?
If I get it right, you mean you want something to generate a variant from existing translation. Am I right?
In a way. Thing is, the difference between formal and informal in Dutch is big enough to justify a separate language file.
I don’t think l18n supports this at all. So I wonder if it’s possible to tell Discourse to alias files in a way. In the config/locales folder you would have client.nl_formal.yml and client.nl_informal.yml. Discourse would jump in and make l18n believe it’s either one of them, aliased as client.nl.yml, based on site settings.
It might seem like a luxury or plugin territory, but Dutch isn’t the only language with this ‘problem’. Also German, Spanish, French, Italian, etc. have this system. It’s just English that doesn’t. 
As an english-speaker, I don’t understand the concept! I18n will definitely barf on arbirtrary locale codes. It already barfs on fr_FR, which is a valid code (it only accepts fr). A new layer would need to be added to do some mapping.
I don’t know what the solution is in the meantime… A decision about formal vs informal within the language team at the Transifex project should be made so that translators know what they’re supposed to use.
How do other software packages handle this? eg. Mac OS X and Windows seem to both have only one Dutch translation option - do they use formal or informal?
Well, at least in Dutch there’s a way to avoid using formal or informal when instructions are only short (Discourse has longer phrases).
Example:
Weet u zeker dat u dit bestand wil verwijderen? (formal)
Weet je zeker dat je dit bestand wil verwijderen? (informal)
Translates to:
Are you sure you want to delete this file?
On OSX the question would be shortened to:
Zeker weten?
Which is just:
Sure?
You can get away with these versions quite often, but definitely not always.
@Sander78, thanks for bringing this up. I’ve been toying with the idea to create an informal German translation but ran into the same wall.
@neil, you wouldn’t be the first person trying and failing to get to grips with the distinctions between formal and informal speech. However, I don’t believe that deciding on either one is the right approach; the differences between formal and informal may be subtle, but it sets a certain tone and different communities will want to be able to choose.
Maybe translations could be removed from the core entirely and be installed as plugins?
L18n is buried deep deep inside Discourse. You can’t take that out. Everything that’s part of the core functionality shouldn’t be plugin territory.
I don’t see why we can’t provide two translations for certain languages, doesn’t seem too complex provided people are happy to maintain it.
This really seems like a “next year” thing. Is there anything urgent about this?
If that’s possible, great. I was under the impression that the Rails I18n code wouldn’t allow that without major rewrites.
Rails I18n won’t allow it, but we could have a mapping layer that gives I18n what it likes (nl) and loads any arbitrary translations (nl_formal). In my head it works.
It’s ok to not be on a shortlist, but I predict it’ll be a deal breaker for some companies using those languages if there’s no formal (or informal) version. So eventually you’ll want this, business wise.
It would provide a good way of customising existing translations too. Could be good for some communities.
Apart from the discussion of supporting both (in a future version) should the informal one be the one to start with? I came up with the same question for german translation (after I already translated some strings in the formal way).
Since there are multiple translators working on transifex (for one language) it would make sense to put this somewhere noticeable (if that is possible on transiflex at all).
It would be great if Transifex had an announcements area for each translation team. That’s where a message saying “Translations should be in informal language” should be. @samuelchan22 Is this possible?
Otherwise, a project-wide announcement can be posted.
Either do that or just make every project manager responsible for letting the team know about it.
For MediaWiki, thus Chinese Wikipedia, we actually maintain only two version, zh-hans and zh-hant. There is no need to maintain zh-cn, zh-tw, zh-hk, zh-sg, zh…
zh-cn → zh-hans
zh-tw → zh-hant
Hi @neil, if you visit the Teams tab in your Transifex dashboard, there is a chat bubble icon on the right hand side of the Discourse team box. Click on that and you’ll be able to start discussions on a team level, or language level (e.g. discussion for those involved with Italian translations). Note that because there’s only one project associated with the team right now, the team level discussion function is essentially the same as a project-wide announcement.
Let me know if this is along the lines of what you’re looking for.
This Topic is quite old, but are there any news on this issue?
The members in our german community should be addressed formally instead of the default informal translation. Now we have to spend much efforts to override all texts by hand. I’m certain, that this scenario applies to other discourse operators, too. a single solution for all needs would be perfect. Is it possible to create a transifex translation group for this? May we can contribute our work for others.