no checkmark when fork repo

Description

When I fork a repository and click on the checkbox for "Make Repository Private," no checkmark is displayed.
To see this, you may visit https://try.gitea.io/koofio/123123 and click on Fork.

Screenshots

new repo	new repo fork
	hard to see, but I am clicking on the checkbox

Gitea Version

1.19.3

Can you reproduce the bug on the Gitea demo site?

Yes

Operating System

macOS 13.4 (22F66)

Browser Version

Safari Version 16.5 (18615.2.9.11.4)

The UI is misleading.

The real meaning of it is: the checkbox is read-only, you can not change it, you can not change the visiblity of a forked repo.

Once one's fork is created, yes.

If you click private, your fork remains private. Otherwise, your fork remains public.

Until the fork is created, though, then I would reason no.

When you click on the tiny Fork button (previous step), is the fork created yet? I thought the fork is not created until you click on the Fork Repository button (next step).

@wxiaoguang thank you for your response

I also ran some more tests...
if a repo or forked repo even is public, new fork remains public (in fact, the box stays unchecked)
if a repo or forked repo even is private, new fork remains private (in fact, the box stays checked)
so, yes, you are correct to a point 👍

that point being: you cannot change the visibility of a ~~forked repo~~ repo that we fork
"forked repository" is past tense; the repo that we fork may or may not be forked; and our fork is not created yet

I guess if the checkbox were removed and if "The visibility of a forked repository cannot be changed" were reworded, then users would have more clarity

is there any legitimate reason for keeping the checkbox, if it can't be checked or unchecked?
also, why describe the visibility of newly created fork, if we are really describing that of a repo that we fork?

IMO no particular reason for keeping the checkbox, the code was written as so from beginning, and nobody ever changed it (that's open source)

Forks retain the visibility as otherwise the "create a PR" logic gets significantly complex. For example if you create a PR and make the repo private, then how can the original author see the code? This is just one of the many conditions that would need to be considered. GitHub behaves the same for the same reasons.

@wxiaoguang and @techknowlogick I see, thanks
gitea is a masterpiece to me, and I wouldn't want to cause a headache, but mind if I take a stab at it and create a pr to change the checkbox? (just this checkbox for forks)

Feel free to do so. Thank you.

Progress...

Rebased and built Gitea from source following the build instructions and database preparation

Google Cloud instances may need extra RAM, as did mine

Modified the source code, and rebuilt Gitea

gitea/web_src/css/form.css:
.ui.read-only.checkbox label::before,
.ui.read-only.checkbox input:checked ~ label::before {
  opacity: var(--opacity-disabled);
}

.ui.read-only.checkbox input:focus ~ label::before,
.ui.read-only.checkbox input:checked:focus ~ label::before {
  border-color: var(--color-input-border);
}

.ui.read-only.checkbox input:checked ~ label::after {
  opacity: var(--opacity-disabled);
}
Examples using light mode:

Before After

read-only checkboxes and checkmark are faded
and the checkboxes act more read-only/disabled

Reconsidered against commenting out gitea/templates/repo/pulls/fork.tmpl lines 46-53, since users may want to know the visibility.
Also, reconsidered against rewording options/locale/locale_en-US.ini‎ line 934 (and related lines for other locales), since ones could consider "forked repository" to mean a repository that is a fork.
Unsure about .ui.radio.checkbox, though, if it might also benefit from a read-only selector...

Submit PR

Before	After


	read-only checkboxes and checkmark are faded and the checkboxes act more read-only/disabled