Ref: #16218
This PR:
stderr (that is not the case on master).
Note for reviewers: InitWarning() is out of this PR scope.
132
133+template <typename... Args>
134+bool InitErrorFormat(const char* fmt, const Args&... args)
135+{
136+ std::string original_message = strprintf(fmt, args...);
137+ std::string translated_message = strprintf(_(fmt), args...);
make translate wouldn’t pick those up any more.
_() to pick up anymore by gettext.
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
Reviewers, this pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.
InitErrorFormat was named InitError…
I believe
make translatewouldn’t pick those up any more. @laanwj This effectively removes all the translations as there is no_()to pick up anymore by gettext.
Fixed.
The main goal of this PR is to avoid printing localized messages to the debug log file and stderr.
Bilingual GUI messages come for free.
712@@ -713,16 +713,16 @@ static void ThreadImport(std::vector<fs::path> vImportFiles)
713 */
714 static bool InitSanityCheck()
715 {
716- if(!ECC_InitSanityCheck()) {
717- InitError("Elliptic curve cryptography sanity check failure. Aborting.");
718+ if (!ECC_InitSanityCheck()) {
719+ InitError(_("Elliptic curve cryptography sanity check failure. Aborting.", true));
Fixed.
btw, this PR aims that a translated message:
stderr in EnglishTherefore, english error message is always available even for translated messages.
723 if (!glibc_sanity_test() || !glibcxx_sanity_test())
724 return false;
725
726 if (!Random_SanityCheck()) {
727- InitError("OS cryptographic RNG sanity check failure. Aborting.");
728+ InitError(_("OS cryptographic RNG sanity check failure. Aborting.", true));
34@@ -35,6 +35,7 @@ struct UISignals {
35 }
36
37 ADD_SIGNALS_IMPL_WRAPPER(ThreadSafeMessageBox);
38+ADD_SIGNALS_IMPL_WRAPPER(ThreadSafeMessageBox2);
ThreadSafeMessageBox2. What makes this function different?
Fixed.
btw, 2 in ThreadSafeMessageBox2 meant “bi-” in bilingual rather “second” :)
905@@ -904,7 +906,7 @@ bool AppInitBasicSetup()
906 #endif
907
908 if (!SetupNetworking())
909- return InitError("Initializing networking failed");
910+ return InitError(_("Initializing networking failed", true));
If the point is to make it easier to google error messages, wouldn’t it be more efficient to add some kind of error code to the output? E.g. the example from the screenshot could look like this in the English version:
0ERR38278: Prune cannot be configured with a negative value
and like this in the German version:
0ERR38278: Kürzungsmodus kann nicht mit einem negativen Wert konfiguriert werden
This would also help searchability if the English error text changes between versions. Only drawback I suppose is that somebody would have to come up with all the error codes :-)
I like the idea (so Concept ACK), no thoughts on the implementation. @flack Trying to assign numerical error codes in the face of parallel development seems tricky… but not impossible.
The dual languages also helps in the common case that the user also reads English… since the translation may not be good or may not be clear (esp. even a native speaker of another language may have only seen various technical terms but a translator managed to use a rarely used word in the translated language). Error numbers don’t have this benefit, so the dual language output would be useful independently of error numbers.
@gmaxwell yes, it would require some coordination. But I suppose a linter can take care of most of the problems, esp. since the numbers don’t have to be consecutive or follow any kind of logic really.
It’s true what you say about wonky translations. “Kürzungsmodus” from the screenshot is actually a case in point. It literally means “shortening mode”. No way I would have guessed that this refers to pruning (or at least not on the first try). But otoh, if users have the UI set to e.g. German, then all they see are German terms, i.e. there’s probably a checkbox labeled “Kürzungsmodus” somewhere and they might remember that they clicked that. Throwing the word “pruning” into the mix might just add to the confusion at this point, exactly because the meaning is different (“I selected shortening mode and now it’s complaining about ‘pruning’ ?!?”).
Anyhow, I get that my suggestion cannot be easily implemented in the short term, but how about making it a bit more clear that the two messages are actually referring to the same thing (instead of being one translated error and one untranslated error)? E.g. something like:
0Kürzungsmodus kann nicht mit einem negativen Wert konfiguriert werden
1
2Original-Meldung: Prune cannot be configured with a negative value
“Original-Meldung” means “original message”. Could also say “untranslated message” or something.
since the translation may not be good or may not be clear
I think we need to be careful here also to respect the translators. They are not developers and will not understand internal technical details in error messages.
If an error message has more technical terms in it than the standard bitcoin and GUI ones such as window, wallet, block, transaction …. then it shouldn’t be translated.
Translators will get pissed at me for this or substitute some nonsense word. In both cases no one is better off.
If an error message has more technical terms in it than the standard bitcoin and GUI ones such as window, wallet, block, transaction …. then it shouldn’t be translated.
Still, you have to enable the user to make the connection between the error message and what they might have selected in the GUI settings. So e.g. if you don’t translate “prune” in the error message, then you also shouldn’t translate it in the rest of the GUI (or at least show the English term in brackets)
prune is a grey area I guess. It doesn’t go with the obvious bitcoin or computer words but it also isn’t something like “glibc sanity check failed” which makes no sense to users nor translators whatsoever.
So to be clear Im not against showing error messages in both languages, but this shouldn’t a reason to translate things that would otherwise not be because the English message can be used to work around a terrible translation.
After the e2c8ba9f6e782e2545b71e9e34b967c69e18c7f0 commit merged there is no straight way to pass function template InitError(const bilingual_str& fmt, const Args&... args) through the Chain interface.
I ask for advice @ryanofsky, @MarcoFalke, @jonasschnelli, @promag.
53@@ -54,6 +54,16 @@ inline std::string _(const char* psz)
54 return G_TRANSLATION_FUN ? (G_TRANSLATION_FUN)(psz) : psz;
55 }
56
57+struct bilingual_str {
58+ std::string original_str;
59+ std::string translated_str;
60+};
61+
62+inline bilingual_str _(const char* psz, bool translate)
What is the point of the bool argument, when it is always set to true at the call site? Should be called bool ignored or something like this?
0enum class Tr{BI;};
1inline bilingueal_str_(const char* psz, Tr ignored);
133@@ -130,4 +134,20 @@ bool InitError(const std::string& str);
134
135 extern CClientUIInterface uiInterface;
136
137+/** Show bilingual error message **/
138+template <typename... Args>
139+bool InitError(const bilingual_str& fmt, const Args&... args)
I’d prefer if you removed the plain InitError, since it doesn’t seem to be required.
Also, would be nice to add InitError to the linter ./test/lint/lint-format-strings.sh
I’d prefer if you removed the plain InitError, since it doesn’t seem to be required.
If I understand you correctly then what about #15340 (review)? Also see: fea324f90e58f74ad76045bd68db1f96f4b00200
InitError could take as first argument a string or bilingual string, so that the formatting always happens inside of InitError. Then add InitError to the linter.