2021-12-31 01:37:06 +01:00
|
|
|
// @flow
|
|
|
|
import { isLocalStorageAvailable } from 'util/storage';
|
|
|
|
|
2019-09-04 23:43:37 +02:00
|
|
|
const isProduction = process.env.NODE_ENV === 'production';
|
2021-12-31 01:37:06 +01:00
|
|
|
const localStorageAvailable = isLocalStorageAvailable();
|
2019-09-04 23:43:37 +02:00
|
|
|
|
|
|
|
window.i18n_messages = window.i18n_messages || {};
|
|
|
|
|
2021-12-31 11:24:18 +01:00
|
|
|
/**
|
|
|
|
* Collects new i18n strings encountered during runtime.
|
|
|
|
* The output can be retrieved and pasted into app-strings.json.
|
|
|
|
*
|
|
|
|
* @param message
|
2019-09-04 23:43:37 +02:00
|
|
|
*/
|
2020-12-08 22:50:10 +01:00
|
|
|
function saveMessageWeb(message) {
|
2021-12-31 11:24:18 +01:00
|
|
|
// @if process.env.NODE_ENV!='production'
|
|
|
|
if (!window.app_strings) {
|
|
|
|
return;
|
2019-09-04 23:43:37 +02:00
|
|
|
}
|
2021-12-31 11:24:18 +01:00
|
|
|
|
|
|
|
if (!window.new_strings) {
|
|
|
|
console.log('Copy new i18n to clipboard:%c copy(window.new_strings)', 'color:yellow'); // eslint-disable-line
|
|
|
|
}
|
|
|
|
|
|
|
|
window.new_strings = window.new_strings || {};
|
|
|
|
|
|
|
|
if (!window.app_strings[message] && !window.new_strings[message]) {
|
|
|
|
window.new_strings[message] = removeContextMetadata(message);
|
|
|
|
}
|
|
|
|
// @endif
|
2019-09-04 23:43:37 +02:00
|
|
|
}
|
|
|
|
|
Support for multiple string context + "About" as initial example.
## 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.
2020-10-09 07:38:03 +02:00
|
|
|
function removeContextMetadata(message) {
|
|
|
|
// Example string entries with context-metadata:
|
|
|
|
// "About --[About section in Help Page]--": "About",
|
|
|
|
// "About --[tab title in Channel Page]--": "About",
|
|
|
|
const CONTEXT_BEGIN = '--[';
|
|
|
|
const CONTEXT_FINAL = ']--';
|
|
|
|
|
|
|
|
// If the resolved string still contains the context-metadata, then it's one of the following:
|
|
|
|
// 1. In development mode, where 'en.json' in the server hasn't been updated with the string yet.
|
|
|
|
// 2. Translator made a mistake of not ignoring the context string.
|
|
|
|
// In either case, we'll revert to the English version.
|
|
|
|
|
|
|
|
const begin = message.lastIndexOf(CONTEXT_BEGIN);
|
|
|
|
if (begin > 0 && message.endsWith(CONTEXT_FINAL)) {
|
|
|
|
// Strip away context:
|
|
|
|
message = message.substring(0, begin);
|
|
|
|
// No trailing spaces should be allowed in the string database anyway, because that is hard to translate
|
|
|
|
// (can't see in Transifex; might not make sense in other languages; etc.).
|
|
|
|
// With that, we can add a space before the context-metadata to make it neat, and trim both cases here:
|
|
|
|
message = message.trimEnd();
|
|
|
|
}
|
|
|
|
|
|
|
|
return message;
|
|
|
|
}
|
|
|
|
|
2021-12-31 01:37:06 +01:00
|
|
|
export function __(message: string, tokens: { [string]: string }) {
|
2020-10-20 05:54:32 +02:00
|
|
|
if (!message) {
|
|
|
|
return '';
|
|
|
|
}
|
|
|
|
|
2021-04-06 21:15:08 +02:00
|
|
|
const language = localStorageAvailable
|
|
|
|
? window.localStorage.getItem('language') || 'en'
|
|
|
|
: window.navigator.language.slice(0, 2) || 'en';
|
2021-12-31 01:37:06 +01:00
|
|
|
|
2019-09-04 23:43:37 +02:00
|
|
|
if (!isProduction) {
|
2021-12-31 01:34:19 +01:00
|
|
|
saveMessageWeb(message);
|
2019-09-04 23:43:37 +02:00
|
|
|
}
|
|
|
|
|
Support for multiple string context + "About" as initial example.
## 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.
2020-10-09 07:38:03 +02:00
|
|
|
let translatedMessage = window.i18n_messages[language] ? window.i18n_messages[language][message] || message : message;
|
|
|
|
translatedMessage = removeContextMetadata(translatedMessage);
|
2019-09-04 23:43:37 +02:00
|
|
|
|
|
|
|
if (!tokens) {
|
|
|
|
return translatedMessage;
|
|
|
|
}
|
|
|
|
|
2021-12-31 01:34:19 +01:00
|
|
|
return translatedMessage.replace(/%([^%]+)%/g, ($1, $2) => {
|
2019-12-17 04:50:43 +01:00
|
|
|
return tokens.hasOwnProperty($2) ? tokens[$2] : $2;
|
2019-09-04 23:43:37 +02:00
|
|
|
});
|
|
|
|
}
|