Generalized and Structured Keys (Like in Minecraft)
kawashirov
Translation keys are unique identifiers assigned to specific strings.
These keys act as placeholders for the actual content that needs to be translated.
Currently, "1:1" English strings are used as keys.
This is a really bad approach.
It's been almost half a year since we started, and we have already encountered numerous problems because of this:
- Keys are supposed to be static, but as the original string changes, keys often change too (accidentally), causing duplication of strings and creating a mess both in Crowdin and the community.
- These keys provide no context, and even if it's given, manually-assigned labels like "General", "Tooltip", and "Main Menu" don't provide many clues. I propose using generalized, structured, and unified keys, exactly like in Minecraft. They use keys likecategory.subcategory.whatever.entryfor every string in the game.
This approach is better because:
- It's stable and future-proof. Developers can change the original English text however they want, and it will not cause a mess on Crowdin. No strange symbols or placeholder leak into keys. Simple static key.
- It always provides context(both grammatical and semiotic)and the location where the string is used. For example, we see the string "Custom", but we look at the keyitem.minecraft.firework_star.custom_colorand know for sure that it's about a standard Minecraft-namespaced firework item which has a custom color. As we know it's about color and fireworks, we can translate it with grammatically correct gender, case, and number - "Пользовательский". Or we see "Hidden" with the keygui.socialInteractions.status_hiddenand now know it's about status and should be "Скрытый", not "Скрытое" or "Скрытая". And so on.
- Strings will be automatically split for contexts. If we only had (for example)gui.mainmenu.group.membership_visibility.hiddenandgui.nameplate.visibility.hidden, orinstance_type.friendsandgui.world_list.access.friends, half of the posts on this Canny might not have even happened.
- It also solves problems of searchingas it alsoprovides grouping and categorization. In the example of Minecraft, we can always search forgui.socialInteractionsto see all the keys related to the "social interactions" context and translate it consistently.
The same approach can be useful in VRChat. I hope for understanding, this system will make things easier for everyone: Devs, Managers, Proofreaders and Translators.
Gonna drop some examples below.
Log In
kawashirov
Right now we experiencing a lot of similar issues related to bad keys:
- https://feedback.vrchat.com/localization/p/98884-not-shown-view-avatar-details-tooltip
- https://feedback.vrchat.com/localization/p/22615-blocked-is-not-localized
- https://feedback.vrchat.com/localization/p/the-string-23179-allow-override-with-show-avatar-is-not-changing-to-other-langua
- https://feedback.vrchat.com/localization/p/rename-clear-favorites-list-actions-are-not-translated-in-game
- https://feedback.vrchat.com/localization/p/create-new-instance-modal-uses-wrong-string-for-public-instance-type
- https://feedback.vrchat.com/localization/p/inconsistent-wording-groups-public-and-groups-plus
- https://feedback.vrchat.com/localization/p/avatar-details-use-untranslatable-performance-ratings
- https://feedback.vrchat.com/localization/p/23397-view-needs-splitting
- https://feedback.vrchat.com/localization/p/new-tooltip-of-microphone-behavior-is-not-added-to-crowdin
- https://feedback.vrchat.com/localization/p/source-string-24455-medium-shared-across-multiple-places (still messed up after few months!)
- https://feedback.vrchat.com/localization/p/the-friends-string-needs-splitting (also not resolved after few months!)
This would less likely to happen, if 👆 suggested key system was implemented before. Still not too late to do that to avoid those cringy fails in future.
kawashirov
Pic related, for the history
kawashirov
🤷🤷♂️🤷♀️
kawashirov
I am 80% sure this problem 👉🏻 https://feedback.vrchat.com/localization/p/some-strings-about-posts-of-groups-are-not-translatable
happened because when they renamed "announcements" to "posts" they by accident also broke/renamed the keys.
"1:1 English as keys" can easily cause those problems, but mistakes like this one is easier to notice, when keys are structured, and original English language is being applied to the client UI the same way as any other language.
kawashirov
This problem 👉🏻 https://feedback.vrchat.com/localization/p/add-a-newline-variable-that-is-only-works-in-specific-menus
would be solvable by translators itself with no need for any extra formatting placeholders, if this system were accepted and used.
If every string in every place (where it used) would have its own key, it can be translated with necessary formatting in own context.
kawashirov
Just noticed line break missing there 🥲 can't edit post for some reason.
kawashirov
btw Minecraft's crowdin page if someone wants to take a look: https://crowdin.com/editor/minecraft
kawashirov
This mess of repeating versions of the same strings would never happen if properly structured keys were used:
kawashirov
Such situations would not have happened if this system had been adopted.
There is nothing wrong if same strings were duplicated for different places, so translators can freely pick correct form of words depending on context.
kawashirov
Here we can see how elegant it looks
in Minecraft
: works well for long texts, phrases and single words, and no placeholders leaking into keys. Context is understandable with no extra labels.kawashirov
But this key in VRC is a mess: 🙈
kawashirov
...and we can't be sure about contextual differences between this and that (I assume it's duplicate):
kawashirov
Or this 🤷
(but the second one is closer to what I propose)