Spelling on this wiki

Apology to the readers.
The spelling on this wiki might be kinda bad to pretty horrific at places.

The main reason for that is that I (see User:Apm) value

• getting out all of my ideas in the state of flow over
• getting spelling perfectly fine right from the get-go when I brain-dump my thoughts.

I review my own pages now and then.
Both at random and in context of addition of new content.
The fixing of spelling from that should improve the situation at least a little.

I could blame that I'm not a native speaker but actually I'm not much better in my native tongue.
Actually perhaps even worse since German asks for being concisus about word capitalization and has more emphasis on commas.

Some past spelling fiascos on this wiki I've cleaned up for the most part (hopefully) by now,
like e.g. the random mixing of it's and its. Others are likely still present.

• it's (it is)
• its (possessive)
• today's (possessive)
• todays (plural)

No fun.

If the reader notices something that is bad enough to detract from ease of reading, then
I'd very much appreciate a notification.
Mail is on my homepage where this page links to: APM:About

Grammar

Grammar should be fine.
Just note that I sometimes consciously use somewhat odd but still correct grammar constructs to make reading easier.
Regarding the topic of a sentence, I often like to put it first like the case in Japanese grammar.
I'm mostly not referring to something as extreme as "Yoda speak".
I'll never ever bend grammar just to sound odd on purpouse.

Line-breaks

Sorry to all the mobile readers.
This wiki is not at all optimized for mobile reading.
There' a deeper reason for this. I'll elaborate.

I like to put line-breaks after just a rather short fraction of a sentence that
is still short enough such that the reader can easily find the right row to continue.
Furthermore I like put line-breaks after a complete logic unit of a sentence plus one
more word that clearly signalizes that this sentence must continue in the next line.

I do not care that I don't have a pretty block text.
It is supposed to be easy to read not pretty to look at.
I do only try to make sure to have somewhat similar consecutive line-lengths such
that discerning the paragraphs is easily done by eye.

So just like with bending grammar I use explicit line-breaks extensively for improving text readability.
It definitely improves readability for myself. I hope my readers experience it the same.

To achieve all of the above I need to keep absolute control of my line-breaks.
Leading to me littering the wiki with explicit line-breaks.

Unfortunately my sentences are often still a bit to long for today's (2022) palm sized mobile devices.
So mobile browsers force in some additional line-breaks messing readability up big time.

I also sometimes use line-breaks to split a sentence midway to list cases, such that ...
– either the start of the lines form a repeating pattern
– or matching pairs (it & then) (either & or)
... and the sentence can go on without any disruption after the list.

Of course one can use bullet points for things like this but,
if formatted badly, I consider bullet-points highly detrimental to ease of reading.
And there are quite a lot of platforms that are pretty good at formatting bullet points badly.
This is especially a problem when writing in multiple markdown environments and copying back and forth between them.
More on bullet-points in the next chapter.

Bullet-points

Support for multi-line bullet-points is abysmal in various different software cases (including media wiki)

Auto-formatting of bullet points is often terrible and unadjustable.
E.g. gargantuan spaces everywhere, messing up needed the inhomegenity of visual density that is needed for easy reading.
Mediawiki does decent in this regard though.

It feels like all reasonably easy to type bullet point like symbols of the keyboard are
annexed by at least one of the many markup languages.
Mediawiki only annexes asterisks - thanks.
So at many "platforms" (forums, message boards, …) I often use black stars "★"
which are not naively typeable on desktop keyboards and which thus should be way more
future proof against the next markup language annexing its interpretation.