BTW ping @mattcaswell

Other possible words:

center -> centre
initialize -> initialise
initialization -> initialisation
realize -> realise
utilize ->utilise

Try this:

; apropos intialis | wc
; apropos initializ | wc

Does this change the view that we want UK wording?

Added Matt's list, fixed the errors, pushed a new commit.

The apropos should make difference... quite a lot of manuals go for US English, so... plus, you gotta spell "initialis" right 😉

Rather than typing it in, here's a cut/paste of real output on my machine (Debian something)

; apropos initialis | wc
      1       8      65
; apropos initializ | wc 
     36     283    2296

Is OpenSSL going in the wrong direction by using UK spelling?

After all, we just went through a lot of trouble to follow the man7 recommendations...

After all, we just went through a lot of trouble to follow the man7 recommendations...

Do you have a reference/link to spelling recommendations on man7.org?

Never mind, I found it (man man-pages):

   Spelling
       Starting with release 2.59, man-pages follows American spelling conven‐
       tions  (previously,  there  was  a  random  mix of British and American
       spellings); please write all new pages and patches according  to  these
       conventions.

       Aside  from  the well-known spelling differences, there are a few other
       subtleties to watch for:

       *  American English  tends  to  use  the  forms  "backward",  "upward",
          "toward",  and  so  on  rather  than  the British forms "backwards",
          "upwards", "towards", and so on.

I just sent email to openssl-project asking the OMC to formally decide on a policy.

Someone please mark this on HOLD until the decision.

Apropos: all these recent man7 changes have not been backported to 1.1.1. Shouldn't that be done in order to avoid a cherry-picking nightmare for 1.1.1 LTS?

~/src/openssl$ git log --left-right master...OpenSSL_1_1_1-stable --oneline  | grep man7
< 60a7817cac Add wordlist from man7.org
< c18d2d94c8 Funtion name with variable part in doc/man7/ and doc/internal/man3/
< dfabee82be Make doc/man7/ and doc/internal/man3/ conform with man-pages(7)

Is OpenSSL going in the wrong direction by using UK spelling?

I see nothing wrong with that. Making it a popularity contest is not a good reason not to, all it shows is that US folks have so far produced the majority of the documentation (for all sorts of reasons)

It is quite possible doing the cherry-pick will be a nightmare. What I would do is take the PR's and get the diff (via GitHub's .diff pro-tip), and edit filenames for things that have moved, and remove the diff for files that are new.

Or, you could wait until problems actually happen and fix those files.

Lucky for me, this topic came up after most of the changes were done.

all it shows is that US folks have so far produced the majority of the documentation

No, it doesn't show that. It shows that US spelling has dominated, not that the people writing things were all US people.

My take is that policing the choice of UK/US spelling is probably not a good use of our time. What we need is more documentation. Nobody is confused merely because the spelling happens to be US, UK or even a mixture of the two in different sections of the same document.

I'm not opposed to commits that address inconsistencies in spelling within the same sentence or paragraph, variations in spelling can be tolerated, but should not be jarring. I am not in favour of automated normalisation. Even outdated spelling like connexion has its harmless charms if that's what makes the author feel good about writing more text.

No, it doesn't show that. It shows that US spelling has dominated, not that the people writing things were all US people.

You're right... sorry, tired...

... sorry, tired ...

Heh. Hard to be active in all timezones (europe, us, australia) without some snoozing :)

What I would do is take the PR's and get the diff (via GitHub's .diff pro-tip), and edit filenames for things that have moved, and remove the diff for files that are new.

Great fear and anxiousness I sense, Padavan. Trust in the force of git you must. The power of automatic rename detection strong is within git.

IOW: You will practically never need to save or edit patches, because git can do the job for you much faster. Just do a normal rebase or cherry-pick. Whenever git needs to fall back to 3-way merges, it will do an automatic rename detection. How far it goes back and forth in history (from head-of-master via common-merge-base to head-of-1.1.1) to detect the rename depends on the rename limit. You can increase it if necessary (git will tell you when that's the case). Here are my settings

git config merge.renamelimit 32768
git config diff.renamelimit 32768

HTH,
Matthias

P.S: No need for GitHub pro-tips to create diffs or patches: you can simply use
git show [<commit>] > file.diff or git format-patch.

(Edit: it's git show, not git diff)

I guess you can teach an old dog new tricks :) But I'm still glad I'm not on the hook for doing it.

But I'm still glad I'm not on the hook for doing it.

Just name the pr numbers. I'll take care of the backport ;-)

But I'm still glad I'm not on the hook for doing it.

Just name the pr numbers. I'll take care of the backport ;-)

Ah, don't bother. git will tell me anyway.

There are more coming still waiting for review/merge, but looking at git log It appears to be
#10039, #10023, #10073, #10064, #9974, #10041, #10022, #10043, #10034, #9986

There were various other PR's that impacted the docs which aren't mentioned above, as presumably they had their "backport?" question resolved in the PR.

@richsalz, of that lists of PRs, only #10039, #10023 and #9974 are still unmerged.

I have to say I am with @vdukhovni on this.

Was this discussed at the recent F2F? Should I just close this?

We have decided to not shift to US spelling.

And do you want to shift/enforce UK spelling? Should I close this?

Just close I think.