It seems that "initializ-" is the standard, and not "initialis-"
$ grep -r "initialis" src/ | grep -v "qt/locale" | wc -l
2
$ grep -r "initializ" src/ | grep -v "qt/locale" | wc -l
151
It seems that "initializ-" is the standard, and not "initialis-"
$ grep -r "initialis" src/ | grep -v "qt/locale" | wc -l
2
$ grep -r "initializ" src/ | grep -v "qt/locale" | wc -l
151
3373 | @@ -3374,7 +3374,7 @@ bool CWallet::InitLoadWallet() 3374 | block = block->pprev; 3375 | 3376 | if (pindexRescan != block) 3377 | - return InitError(_("Prune: last wallet synchronisation goes beyond pruned data. You need to -reindex (download the whole blockchain again in case of pruned node)")); 3378 | + return InitError(_("Prune: last wallet synchronization goes beyond pruned data. You need to -reindex (download the whole blockchain again in case of pruned node)"));
I think translators already take care of localisation (or localization).
My goal was to have a standard spelling internally, for things that would never be shown to the user (such as comments as well as localization strings)
Ah, I just realized that discounting files in qt/locale was not a good idea
$ grep -r "Prune: last wallet synchronisation goes beyond pruned data." . | wc -l
23
$
I'll revert the synchronisation vs synchnonization one.
I disagree these are typos. The spelling is correct.
They go against the standard spelling defined elsewhere. They might not be typos, true, because there are multiple accepted spellings, but they are definitely outliers compared to the rest of the codebase. I show this in the pull request description.
Keep in mind most developers are international and do not speak English as their native tongue. It probably will turn out difficult to enforce spelling.
If you feel strong about typos, there would be another one: git grep communc
The other pull fixed some actual typos
On Thu, Aug 18, 2016 at 7:37 PM, Leijurv notifications@github.com wrote:
Okay. Why was #8505 accepted then? Was than an error or something?
IMO such pull requests are not productive... they may are if they fix many of typos in one PR. Closing.
Agree with @jonasschnelli and @MarcoFalke , too much of this is not productive. These are just code comments, if they're hard to understand, then certainly fixing a few typos isn't going to make that better.
Try to restrict fixing typos to end-user facing messages.