At first glance, your changes look good to me, though I have not tested them. I have no strong opinion on the UI changes themselves (so I'll leave those to others to review), but I do have some suggestions for your commit messages:

• Your first commit states what it does, but notwhy. What changes when you add this property in the form file? Why is it useful or needed?
• Your second message only states theproblem of the original issue, but the convention here is to state thechange the commit makes in the first (short) summary line. In the extended description (after an empty line in the commit message), you can use more works to describe the problem that is fixed and how the fix works. It is also good to reference the ticket number, but ideally not in the summary line but at the end of the commit message, e.g. a separate line saying something like "This commit fixes[Preferences] Button problem in Preferences #9185." which also allows github to autoclose the issue when the PR is merged.

As I previously said elsewhere: If you make these changes, please do a force push to this same branch to update this PR, rather than creating a new PR.

Thank you for such descriptive reply.

Another PR is not closed. It is an alternative solution which does not require translation, but is less descriptive. I am using an existing sentence that was already translated. I did this way, so someone can make a decision about how much effort should be done and which change is preferred.

"What changes when you add this property in the form file?"
I doubt it changes anything because the logic was done at the backend (java file). I was following the existing style. All other sentences were duplicated in both files. .form file are XMl files for IDE, by adding a line I am making it to pop up in XML in the form editor. When java logic is hidden.

At first glance, your changes look good to me, though I have not tested them. I have no strong opinion on the UI changes themselves (so I'll leave those to others to review), but I do have some suggestions for your commit messages:

• Your first commit states what it does, but notwhy. What changes when you add this property in the form file? Why is it useful or needed?
• Your second message only states theproblem of the original issue, but the convention here is to state thechange the commit makes in the first (short) summary line. In the extended description (after an empty line in the commit message), you can use more works to describe the problem that is fixed and how the fix works. It is also good to reference the ticket number, but ideally not in the summary line but at the end of the commit message, e.g. a separate line saying something like "This commit fixes[Preferences] Button problem in Preferences #9185." which also allows github to autoclose the issue when the PR is merged.

As I previously said elsewhere: If you make these changes, please do a force push to this same branch to update this PR, rather than creating a new PR.

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign ourContributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let usrecheck it.}