Release 1.2.x

[Skif-off]

@alexx2000, @rich2014, @H1DDENADM1N (if you want to support the zh translation)

The master branch contains changes that are not available in the current 1.2.x release.
Perhaps need create the "v1.2.x" branch based on 507474e9 and create a help version for the current DC release? (In Debian and Ubuntu contain help packages for DC, but I don't know about other Linux distributions.)
It will take me a little time with PR#87.

What's the next step? Add alpha markers to the master branch?
I can also add alpha features from this branch (except screenshots, history and maybe Stash).

Or should we remove the new/alpha features from the main help branch?

[rich2014]

i feel the cost of maintaining branches is too high.

would it be more appropriate to specify the applicable version in the relevant places?

[Skif-off]

would it be more appropriate to specify the applicable version in the relevant places?

It's not always easy. "Alpha version" and "Beta version" markers are easy to add, but they can be tricky if behavior changes after release.
For example:

alpha: ADD: cmds.html: 'cm_SetSortMode';

alpha: ADD: configuration.html: Section 'Files views': 1K, switch binary/decimal prefixes;

alpha: ADD: configuration.html: Section 'Keys': Force F1, F2, etc. to be treated as function keys (macOS).

Simple marker is visible and clear. But what about

alpha: UPD: configuration.html, findfiles.html, help.html, syncdirs.html: Separate file mask history is now used."

? (Syncdir's filters are stored separately in 1.3.0+, but before, this was part of the general history of masks; notes in several places.)

Notes in addition to markers?

Also, some Linux distributions do not contain the current version of the application. For example,

Debian 11:    0.9.10
Debian 12:    1.0.10
Debian 13:    1.1.22
Debian sid:   1.1.32
Ubuntu 22.04: 1.0.5
Ubuntu 24.04: 1.1.11
Ubuntu 25.10: 1.1.28
Ubuntu 26.04: 1.1.32

Well, when the help/documentation of a library/application corresponds to the current release of that library/application, it's a old and good tradition.
In some ways, it's simpler. (For example, I didn't just add the cm_CallPlatformFunctions description (translation in this case), in the first I removed the descriptions for cm_Share, cm_AirDrop, and cm_RevealInFinder.)
But I am not sure which way is better.

P.S. Also screenshots...