Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support formal-informal language variations #5125

Open
markusgeert opened this issue Jun 6, 2023 · 6 comments
Open

Support formal-informal language variations #5125

markusgeert opened this issue Jun 6, 2023 · 6 comments

Comments

@markusgeert
Copy link
Contributor

Why is this Needed?

In a lot of languages (german, french, dutch, etc.) there exists a difference between formal and informal language. In the Dutch language translations there is no consistency as to which mode is used (informal, formal).

Would it be possible to support two sets of language files for each language that uses different words in formal and informal speak?

If this is too much work and/or not a priority, it might be a good idea to pick one mode (formal or informal) per language, to at least enforce consistent communication? Let met know what you think.

@javierm
Copy link
Member

javierm commented Jun 27, 2023

Hi, @markusgeert 😄.

If this is too much work and/or not a priority, it might be a good idea to pick one mode (formal or informal) per language, to at least enforce consistent communication?

You're right; we should always use one mode. In Spain's Spanish, for instance, we try to use the informal mode because in Spain this mode is very common when talking to the general population.

In the case of Dutch, perhaps the institutions using Consul in the Netherlands could agree on which mode should be used and maybe get in touch with translators via Crowdin 🤔. Other suggestions are welcome!

Regarding support for both modes, it's something we've been thinking about but so far we haven't found a maintainable way to do so.

@markusgeert
Copy link
Contributor Author

markusgeert commented Jun 27, 2023

Yep, I agree that it's quite a hard problem. In the netherlands both modes are used in different organizations, depending on location, target audience, message etc. So there isn't a general consensus on what to use unfortunately.

I'm not really familiar with Crowdin, but based on your response I assume they don't provide a way to add alternative translation in the same way singular and plural modes are handled?

Another feature where this could be useful might be in having different names for the same concept. For example in Dutch, we sometimes want to call the Debates section 'Debatten' (more political, formal) or 'Discussies' (more informal, discussions). Currently we can use custom language files for this which works okay, but it is not ideal in terms of transferability and maintainability.

This might also be more of a feature request for Crowdin than for Consul, I'm not quite sure.

@Senen
Copy link
Member

Senen commented Jun 27, 2023

Hi @markusgeert and @javierm,

Reading the Crowdin docs, it seems we can add a custom target language with a custom locale code in Crowdin and use it in CONSUL so we can have both Dutch versions co-existing in the application. The same applies to every other language.

@markusgeert
Copy link
Contributor Author

Hi @markusgeert and @javierm,

Reading the Crowdin docs, it seems we can add a custom target language with a custom locale code in Crowdin and use it in CONSUL so we can have both Dutch versions co-existing in the application. The same applies to every other language.

This seems like a viable solution. I'm not really clear on this from the docs, but is it then also possible to fall back on the original language, so that for example the formal language only has to contain the strings for which it applies and use the 'default' strings otherwise? Otherwise this requires maintaining two very similar language files.

@Senen
Copy link
Member

Senen commented Jun 27, 2023

Hi @markusgeert,

This seems like a viable solution.

Yes, It seems so.

I'm not really clear on this from the docs, but is it then also possible to fall back on the original language, so that for example the formal language only has to contain the strings for which it applies and use the 'default' strings otherwise?

We control how the fallbacks behave, so we can set any language as a fallback, including custom languages. At first, it seems this should not be a problem.

Otherwise this requires maintaining two very similar language files.

Yes, the fallback can greatly leverage the secondary Dutch version translation task. Although, most Dutch translators won't know we are using a fallback at the application level, and they probably tend to translate everything. This is the only downside I see right now, and my bet is that Crowdin does not have a feature that can help translators with this problem.

@Senen
Copy link
Member

Senen commented Jun 27, 2023

Hi @markusgeert

Another feature where this could be useful might be in having different names for the same concept. For example in Dutch, we sometimes want to call the Debates section 'Debatten' (more political, formal) or 'Discussies' (more informal, discussions). Currently we can use custom language files for this which works okay, but it is not ideal in terms of transferability and maintainability.

I think the situation you describe is very common in most of the languages. For example, we installed CONSUL for many institutions from Spain, mostly government-related institutions, and almost all of them want to reword something.

There is a feature in CONSUL called Custom Information Texts that allow administrators to change the translation from most of the I18n keys. This helps a lot institutions to rename some words like "Debates" to "Discusiones" or whatever the institution wants.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants