use simpara for simple paragraphs

[rbowen]

Documentatio CI enforces the use of simpara rather than para for paragraphs containing only inline
content. Converted 62 instances of para to simpara across install/unix/ where no block-level elements (examples, lists, etc.) are nested within to simplify future patches.

[kamil-tekiela]

My remark is not towards you, but towards this whole CI thing. This really should have been done in one go for the whole documentation using some tool. Doing it like this is a huge waste of time.

[rbowen]

Happy to submit a larger PR across the whole doc tree, but I wasn't completely sure if this was welcome, or the right approach. If/when this PR gets merged, I'll take that as a nod of approval to the approach and proceed with that. Seems like something I can probably automate so that I'm not manually patching stuff.

[kamil-tekiela]

I'd be happy to approve and merge this, but honestly, I don't know whether we want to do that. By merging it, the translations will need to be reviewed again. We could skip the translations, but personally, I think that if we do it in English we should sync translations too.

I appreciate the PR, but I don't think it's an improvement on its own, and we should probably first agree on how to proceed with this migration. I am not on Discord, so I don't know if there is any discussion there, but I remember seeing one on GitHub, however, I cannot find it anymore.

[jordikroon]

I very much agree with Kamil. While I appreciate the effort, this is just a drop in the bucket that distracts from all the work that needs to be done.

As a basic rule of thumb, don't fix CS issues just because. Only do them when they are required to do. Which is, when elements are changed copy-wise or structurally. Happy to merge this in just to get you off manual approval for the workflows.

That said, while I agree we should propagate these changes into translations, doing it in small chunks won't add any benefits. So we really need to merge with [skip-revcheck] so maintainers of translations (doc-it, doc-xx etc) don't need to be bothered with that, for now.

My suggestion is to do a mass CS fix. The foundation for that has been set in docbook-cs. And the newer version has a --fix command that can fix the whole manual in 1 go. For that it's best we strategise/coordinate over the mailing list as an official channel.

In order to do this, I am trying to improve the overall build tools for doc-en and doc-xx here: (php/doc-base#337). That tool includes a fix and lint command out-of-the box. And should become the go-to standard to build any translation. As currently there is no documentation on how to build translations. doc-en suggests to use make with docker. Translations define their own method with manual commands.

So for now, let's merge this. If anyone could try to get his hands on php/doc-base#377 that would be great. I am hoping to merge that in the upcoming week or 2. After that I suggest we start the discussion on how to strategise to fix CS violations. Which may or may not include to define new Sniffs or alter existing Sniffs.

[rbowen]

Cool. I only did this because my other PR failed CI, even though the build/test passes locally - so it seems that the Docbook is valid, but not valid enough for the CI.