I believe we don't translate these since this is already the translated form?
When the language is supported later, the English version will be added to the string database instead.
I couldn't find where this new 'Post' is being used, so I assume it's the same as the old one for now. If it appears in the list again, I'll ask around to put the context-metadata.
These strings are in use and have been translated by the translators. I think it got accidentally removed from the "send auth token with status call" commit.
## Note from Russian translator
"To/From" in the 'automatic dark mode setting' cannot be re-used for the one in the 'Tip Modal'.
## Change
Wanted to split this into "general" and "time", but I'm guessing it won't satisfy all languages, so we'll just use the usage as the context since there's just 2 instances.
## Issue
4796 - i18n: Allow support for string overloading (multiple contexts)
## Approach
- Minimal code and process change.
- Handle on a case-by-case basis when reported by translators.
- Split the affected key in the string json by appending the context.
- Translators need to be aware of the new format and not translate context itself. Code is added to detect bad translations and will revert to English.
Sample in json:
"About --[About section in Help Page]--": "About",
"About --[tab title in Channel Page]--": "About",
Sample in client code:
title={__('About --[About section in Help Page]--')}
- "--[ ]--" was chosen as it's unique enough (unlikely for real strings to use it) and hopefully not that distracting in the client code.
- In the key itself, spaces are allowed after the string (i.e. before '--[') for neatness. It will be trimmed by the system.
## First example
"About" is used in 3 places:
- Channel Page
- Help Page
- Footer (in Odysee branch)
For Russian, the word "About" is "O" and is usually not used standalone, but requires something behind it. A translator said so, and seems to be the case in other sites as well.
"O xxx"
"O yyy"
## Other languages
For other languages that are not impacted, they can just clone the same translation for each of the split keys, just like in English.
## Possible enhancement in Transifex
I see that Transifex's API includes a `context` entry. It might be possible to move the context-metadata there during the upload, so translators will never see the "--[]--" messiness (it will be shown as "Context: xxx" in the Transifex GUI).
I'm not sure how to test the Transifex side, so I did not investigate further.
Most of the items in the footer don't need to be translated, but it was troublesome trying to make `sections[]` re-resolve the label on a language change, if we want to selectively translate certain labels only.
So, just translate everything for now. Translators can simply clone the English string if it doesn't need a translation.
- "The publisher has chosen to" -- Fix incomplete string, probably broken by linter.
- Fix hardcoded email in invite snackbar.
- Fix 'Upload Settings' to new lower-case style.
- Add few more missing ones.
- Consolidated "Claim xxx" strings together.
- Removed duplicate "Confirming..." due to branch merging.
