Locating and applying the en@truecase option isn't intuitive.

[RokeJulianLockhart]

Is your feature request related to a problem? Please describe.

1. As Capitalize labels in UI #2078 (comment) states:

   Reading entirely lower-case labels is difficult for me. You can see in the responses to https://ux.stackexchange.com/q/33708/132515 that the data is inconclusive on this topic (although this revision of this answer provides a useful explanation of my opinion on this).

2. As Capitalize labels in UI #2078 (comment) states:

   I had to search within the closed issues section on this tracker to ascertain that the option would be listed as a translation, and even then, the fact that a restart of the application is necessary isn't communicated to the user - I expected that the feature didn't function after I hit apply (because there was no success feedback there either).

Summarily, the sentence case feature isn't easily discoverable - it's in the language flyout, despite not being a language - and applying it isn't intuitive:

1. The "Save" button doesn't indicate success; and:
2. The "Restart to apply" pill notification appears solely in the parent window, despite the child configuration window not closing automatically upon application (which would be undesirable, but would at least display the notification to the user).

Describe the solution you'd like

As #2078 (comment) states:

What is your proposal?

My best idea is to have a checkbox appear when en-.* is selected, which is labelled "Sentence case".

I can't imagine that having a checkbox appear or disappear based upon the chosen translation would be problematic to implement, and it would prevent the translation flyout being used to non-translation language stylisation attributes.

Alternatives

Most assistance is provided in tooltips:

However, as #2078 (comment) states:

Tooltips aren't inherently discoverable (due to there being no indication of whether a tooltip exists for an element) and don't function on touchscreen displays.

These are reasons that that KDE is moving to using contextual help buttons, per https://invent.kde.org/frameworks/kwidgetsaddons/-/merge_requests/240 and https://discuss.kde.org/t/element-specific-help-should-be-displayed-consistently/15624/2?u=rokejulianlockhart as others are.

Summarily, provide a button that invokes the tooltip, rather than a hover action, so that the user:

1. Knows that an assistance tooltip is available; and:
2. Knows that they are able to invoke it irrespective of their preferred input method.

The undermentioned is a step in the correct direction:

Additional context

Posted here per #2078 (comment):

The place for discussions is in open issues. If you have an idea to improve the UI please raise a new issue and discuss it there.

[elstoc]

the sentence case feature isn't easily discoverable

You could propose an insert into the user manual to flag this up.

Summarily, provide a button that invokes the tooltip, rather than a hover action

We should be consistent so this would be a change to the whole application if desired (I'm not sure it's a good idea, especially given we already have context-sensitive help that points to the user manual). This would therefore be better as a separate feature request.

I can't imagine that having a checkbox appear or disappear based upon the chosen translation would be problematic to implement

It's problematic if the translation gets dropped due to lapse in its maintenance, as it would lead to a non-functioning tick box. The whole idea of this change was to limit its impact by using pre-existing functionality. There's nothing stopping you from submitting a pull request to the repository proposing this change though.

My best idea is to have a checkbox appear when en-.* is selected

One day I might get annoyed with all the American spellings and propose an en-GB translation, but without a sentence-case variant. In this case the proposed solution will not work

[RokeJulianLockhart]

We should be consistent so this would be a change to the whole application if desired (I'm not sure it's a good idea). This would therefore be better as a separate feature request.

@elstoc, I agree - it's rather outside the scope of this. I'd be glad to file it if you think it's of worth, or merely to have the issue linked here, if ever it's created.

It's problematic if the translation gets dropped due to lapse in its maintenance, as it would lead to a non-functioning tick box. The whole idea of this change was to limit its impact by using pre-existing functionality.

Is that currently a concern?

There's nothing stopping you from submitting a pull request to the repository proposing this change though.

@elstoc, surely you're aware that for the vast majority of people there is - I'm unable to develop in C, Lua, or C++. I'm still getting the ropes of damn CSS.

One day I might get annoyed with all the American spellings and propose an en-GB translation, but without a sentence-case variant. In this case the proposed solution will not work

In which case, I could merely rescope this to en-US, surely?

[elstoc]

Is that currently a concern?

With FOSS, people come and go. So I don't know if/when this will become a concern.

Anyway, as you might have gathered, apart from perhaps an addition to the user manual, I'm not sure I agree that these suggestions are necessary.

[RokeJulianLockhart]

perhaps an addition to the user manual

@elstoc, I've created darktable-org/dtdocs#677 (comment) per your suggestion.

With FOSS, people come and go. So I don't know if/when this will become a concern.

Indeed, but if there's no reason to believe that this shall occur, why not build upon it?

[elstoc]

@elstoc, I've created darktable-org/dtdocs#677 (comment) per your suggestion.

Thanks

[victoryforce]

With FOSS, people come and go. So I don't know if/when this will become a concern.

Indeed, but if there's no reason to believe that this shall occur, why not build upon it?

@RokeJulianLockhart Why do you think that there is no reason to believe?