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

Translation improvement ideas #451

Closed
Andre601 opened this issue Jun 11, 2022 · 13 comments
Closed

Translation improvement ideas #451

Andre601 opened this issue Jun 11, 2022 · 13 comments
Labels
translation Relating to localization

Comments

@Andre601
Copy link

As recommended in #450 (comment) do I now open this issue in the hopes to start a discussion on possible improvements towards the current source strings for translations.

Right now, I see 2 minor problems that I think should be improved.

1. Usage of past tense in translations

This may depend on the actual translations done but the usage of past tense such as Shown or Hidden feels... Odd.
Sure Minecraft itself uses Shown in some of its settings, but it still doesn't mean it sounds or feels right.
I personally believe that the usage of Show and Hide would also work too.

At least for translations such as german should the present tense be used because Gezeigt sounds seriously stupid.

2. Condense option values

There are a lot of duplicate values in the source String. I already mentioned two: Shown and Hidden.
I feel like there is no need to have separate entries for each option that has the exact same values. Sure, you can come up with the argument that a language may use a different word/character/... for this particular combination, but how likely is that? Can anyone that is translating any of the currently offered languages list such a situation for this mod?

It would benefit both sides for sure to have less duplicate text. Devs have less lines to maintain and translators don't have to repeat the same sentence/word x times.

@Felix14-v2
Copy link
Contributor

There are a lot of duplicate values in the source String. I already mentioned two: Shown and Hidden.
I feel like there is no need to have separate entries for each option that has the exact same values. Sure, you can come up with the argument that a language may use a different word/character/... for this particular combination, but how likely is that? Can anyone that is translating any of the currently offered languages list such a situation for this mod?

In Russian:
hidden=скрыт, shown=показан, BUT:
Библиотеки: показаны/скрыты
Лицензия мода: показана/скрыта
And these are not all existing forms.

@jackassmc
Copy link
Member

1. Usage of past tense in translations

Since there is precedent of using "Shown" and "Hidden" and Mod Menu has used them for a long time now the English source strings won't be changed.

This doesn't mean that the German translation has to follow that, though. What does Minecraft use for the chat settings in German?

Also please note that cloud based localization tools such as Weblate and Crowdin are sometimes a bit too eager with automatic translations. So it is possible that the translations that you dislike were automatically added. If you ever spot a literal translation that doesn't fit please feel free to change it.

2. Condense option values

It seems that at least the Russian translations need the distinction. But to make this easier for translators they get automatically translated. The current setting for duplicate strings in Crowdin is "Show, but auto-translate them", so if the translations are the same for all occurrences no action is required, but if there are different translations they can be added by translators.

The duplicate string setting used to be "Show within a version branch (regular detection) - duplicates will be hidden only between versions branches" with the intention to automatically sync matching translations to other version branches. I don't know if that still happens, if you end up changing the German translations please let me know if the translations get automatically synced to other version branches.

@Felix14-v2
Copy link
Contributor

Felix14-v2 commented Jun 12, 2022

If we are talking about improvements, is it possible make a translation text in "modmenu.mods" (and other strings using numbers) depend on the additional conditions for the number of mods?

For example, there are 4 plural forms in Russian:

  • one: 1, 21, 31, 101, 1001 etc (excluding 11)
  • few: 2-4, 22-24, 32-34 etc (excluding 12-20)
  • many: 0, 5-20, 25-30, 35-40 etc.
  • other: 1.5, 0.8, 11.3 and other fractional numbers. In most cases, the spelling of the word form coincides with few.

Mathematically, this is determined by the following rules:

  • one: |n| × 10 + 1 |n| mod 10 ≠ 1
  • few: |n| × 10 + [2, 3, 4] |n| mod 10 ≠ 1
  • many: |n| × 10 + [5, 6, 7, 8, 9, 0] ∪ |n| × 10 + [1, 2, 3, 4] |n| mod 10 = 1
  • other: all numbers with a fractional part, even if this part is equal to 0 (12 → many, 12.0 → other)

Example:
Mod=мод

  • one мод
  • few мода
  • many модов
  • other мода

As far as I know, similar rules are in German.

@jackassmc
Copy link
Member

Interesting! It is possible but comes with additional complexity. How does Minecraft handle this?

@Felix14-v2
Copy link
Contributor

Minecraft has no solution to this problem. For example, the output of the /fill command always uses only the most popular form — many (the same solution is used in ModMenu now).
To be honest, I have not yet met anyone implementing such a system in Minecraft without using predefined sets of translation strings (although I created this for one of my datapacks, but this is a different area).

@Andre601
Copy link
Author

If we are talking about improvements, is it possible make a translation text in "modmenu.mods" (and other strings using numbers) depend on the additional conditions for the number of mods?

For example, there are 4 plural forms in Russian:

  • one: 1, 21, 31, 101, 1001 etc (excluding 11)
  • few: 2-4, 22-24, 32-34 etc (excluding 12-20)
  • many: 0, 5-20, 25-30, 35-40 etc.
  • other: 1.5, 0.8, 11.3 and other fractional numbers. In most cases, the spelling of the word form coincides with few.

Mathematically, this is determined by the following rules:

  • one: |n| × 10 + 1 |n| mod 10 ≠ 1
  • few: |n| × 10 + [2, 3, 4] |n| mod 10 ≠ 1
  • many: |n| × 10 + [5, 6, 7, 8, 9, 0] ∪ |n| × 10 + [1, 2, 3, 4] |n| mod 10 = 1
  • other: all numbers with a fractional part, even if this part is equal to 0 (12 → many, 12.0 → other)

Example:
Mod=мод

  • one мод
  • few мода
  • many модов
  • other мода

As far as I know, similar rules are in German.

German only has separate words for a single and multiple instances:

  • 1 Mod
  • 2 Mods
  • 3 Mods
  • ...

@Felix14-v2
Copy link
Contributor

Oh, ok.

@Andre601
Copy link
Author

This doesn't mean that the German translation has to follow that, though. What does Minecraft use for the chat settings in German?

From looking at it, do they use the present tense for the option, but also a IMO completely different word.

Like, right now did I translate Shown to Anzeigen. In Minecraft are they using Sichtbar however, which usually translates to Visible in English.
Either way, they use present tense, so I'll update the german translation too (Currently working on swiss translation as that's my most native language... Tho I make a proper translation of it and not the joke-translation like MC did since the grammar is a bit different at certain points.)

@Andre601
Copy link
Author

One other thing I noticed and that I personally find relatively weird is, that english has all-caps for stuff like "on" and "off" while german uses normal capitalization...
It's not a big deal for me, but I certainly feel confused why there is such a noticeable difference.

@jackassmc
Copy link
Member

@Felix14-v2 would it be enough to add the few form to strings dealing with a number of objects? AFAIK one and many are already supported because English uses them, too.

@Andre601 translations aren't necessarily literal, they are supposed to communicate the same information as the source text but in a different language. When I learned English in school this was called "mediation".

Minecraft is translated by volunteers so the opinion of these volunteers on how to translate things end up in the official translations. Maybe the German volunteers just didn't like the capitalization so they decided not to capitalize in the translation.

My opinion on translations for Mod Menu is that they should follow what Minecraft does as best as possible. Because if Minecraft uses specific language to communicate a concept and this gets translated in multiple different ways in the same language people might get confused.
So since there is a precedent of using Sichtbar as the German translation for Shown that should be used. I believe in this case people wouldn't get confused because it is rather obvious, so using Angezeigt is fine. But if another translator later changes this to Sichtbar it would trump your translation because it is closer to what Minecraft does.
Sadly the same goes for your proper translation to Swiss. I think your passion for your language is great and I am always amazed by the efforts and dedication of translators. But since the official Minecraft Swiss translations are humorous if somebody comes along and changes the Mod Menu Swiss translations to be more like that that would be allowed.

You might be able to update the Minecraft Swiss translation to be proper. Minecraft's Crowdin project can be found here: https://crowdin.com/project/minecraft. If Minecraft itself uses proper Swiss then Mod Menu will aim to use proper Swiss, too.

@jackassmc jackassmc mentioned this issue Jun 12, 2022
@Felix14-v2
Copy link
Contributor

Felix14-v2 commented Jun 12, 2022

would it be enough to add the few form to strings dealing with a number of objects? AFAIK one and many are already supported because English uses them

Exactly. We won't need the other form, since we don't use fractional values in ModMenu.

@jackassmc
Copy link
Member

Exactly. We won't need the other form, since we don't use fractional values in ModMenu.

Cool, that's doable. Please open an issue for that. If you know Java a PR is also welcome.

@jackassmc jackassmc added the translation Relating to localization label Jun 14, 2022
@jackassmc
Copy link
Member

@Andre601 thank you for your suggestions! Since they won't be implemented I'm closing this issue. Please feel free to open another issue if you have any more suggestions.

@jackassmc jackassmc closed this as not planned Won't fix, can't repro, duplicate, stale Jun 14, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
translation Relating to localization
Projects
None yet
Development

No branches or pull requests

3 participants