Capitalize labels in UI

[aurelienpierre]

I know there was some hype at the early stages of darktable about using all lowercase characters, but using capitals at the beginning of labels gives a visual anchor that helps orientation in an UI. They are especially needed for section titles and such. See https://uxplanet.org/why-letter-casing-is-important-to-consider-during-design-decisions-50402acd0a4e

[parafin]

Interestingly enough that article doesn’t consider all lowercase text;)

[TurboGit]

Oh no please! This makes the text unreadable to me. Capital letters are higher and if the line are too close it is just hard to read or you have to use big font. I'd like to have a poll on this, of course if the majority prefer this we can revisit.

[TurboGit]

Just to clarify, my statement above is about the labels for the sliders or combos. For tooltip why not. But adding a capital letter to a label which is 2 or 3 words will not bring anything to me.

[aurelienpierre]

This is a screenshot of dt in German, where every noun takes a capital by grammar:

Is it that bad ? I find that, once you have a capital to hook up and the lenght of the label, you don't really have to read that label, you can recognize it quickely by its length and initial letter.

[parafin]

Where do you want to add capital letters? I assume/hope it's not everywhere? German screenshot is not awful, but I don't like it.

[aurelienpierre]

I would like capitals at the beginning of sentences, labels, and sections. Just as regular grammar enforces it, really.

[parafin]

I guess I'll reformulate the question - where do you want to keep all lower-case letters?

[aurelienpierre]

maybe in comboboxes menus, I guess.

[mihkel-t]

Another option would be to just add an English pseudo-translation that makes use of capitals at the beginning of labels, sentences, etc. For instance "en_AQ" where the AQ stands for Antarctica :) (so it wouldn't be chosen by default in any "normal" locale).

[mimoklepes]

For me personally, capitalized labels and text (basically like in any other software) would be much more readable. All lowercase, especially with combination with the right-justification of the module names really hurts my brain when quickly trying to find the correct module in the list. The eyes need to constantly jump left and right with nothing to anchor on.

All lowercase is a cool stylish choice for the name of the software and let's say the "lighttable | darkroom | other" tabs on the top-right. But having all text completely lowercase just gives the impression of trying too hard to look like a hacker-tool and in my opinion it impairs the usability.

[livingsilver94]

I also think capitalized labels would be better:

• As already said, you can recognize functions at a glance if they're better distinguished. All lowercase letters instead can be seen as an anamorphic collection of text.
• It's how we're used to use GUIs. Darktable now feels awkward and not elegant.
• It looks unpolished. By using uncapitalized labels, Darktable can give a user the impression of an amateur application

[TheBB]

I agree that the consistent small letters make Darktable unnecessarily difficult to use. I made a branch here with a capital letter GUI, using a new en_US messages file. Unfortunately it's not so simple as just dropping it in an existing installation because I had to differentiate some strings into capitalized and noncapitalized contexts.

I just went through the parts of the GUI that I look at the most, so YMMV. Hopefully it won't be too tricky to keep it up to date.

[junkyardsparkle]

Hopefully it won't be too tricky to keep it up to date.

It would really be more maintainable to make the capitalized version the master, since creating an all-lowercase version from that would be a trivial operation. :-)

[mepi0011]

The capitalized version should now finally be started! Here it should be considered if this can be done until 3.0.1 release or until the next December 2020 version. If enough people are willing to work on the implementation, the files to be worked on can be split and a small team will review the work and merge it into the master.

[TurboGit]

Let organise another way. What I think would work best:

• have a script to extract all English strings from one po.
• have a script to change to mixed casing all lower case word. Do not change uppercase ones.
• Review all this manually
• create sed commands to replace all matches in the C code and in all po files. We don't want to break all translations and force translator to translate again all of them.

From there we are done and we can let translator keep current casing or provide a script to change translated casing. Again this will need to be reviewed manually anyway. How does that sound?

[github-actions[bot]]

This issue did not get any activity in the past 30 days and will be closed in 7 days if no update occurs. Please check if the master branch has fixed it since then.

[antoniovazquezblanco]

I have just started using darktable. While the lowercase theme looks appealing at first, after just a short time I found myself a bit frustraded with this choice for practical reasons.

At the moment I can see that the usage of caps/non-caps is not consistent in some places: This inconsistency seems to have been introduced due to the non-caps policy.

We are exposed to a grammar since we are born and become very fluent on those rules. This policy seems to break basic grammar rules and that can translate into increased dificulty to become profficient in darktable for many reasons: Using only lower casing may make some acronyms difficult to interpret at first. Avoiding traditional capitalization makes it difficult for some people to locate and follow certain functions of your program. Avoiding capitalization may be specially anoying for people with dyslexia that may use visual clues to better perform when reading text...

Personally I think that this choice is a little bit looks over practicallity and seems that there is people willing to contribute in order to provide a solution that allows for user preference (I am among those people). As I said, I am new to darktable so I would love ti get some gidance on how to contribute to solve this issue that seems to have been abandoned due to a lack in response for proposals.

First, could anyone provide any update on the status of a solution? Has this gone past proposed solutions above?

For the time being I can see a solution summarized by @TurboGit in https://github.com/darktable-org/darktable/issues/2078#issuecomment-568861826

I can also think of another solution: Maybe, traditional language capitalizagion could be used in every translation and a CSS feature could be added to convert all the text to lowercase for the apropiate fields. This requires less translation maintenance and takes advantage of the CSS features offered by the UI framework.

Thank you very much, Antonio

[TurboGit]

@antoniovazquezblanco : I don't think anyone has started working on this. I think the solution I have proposed is the most promising as otherwise we will have some more rules for translated languages. I'm more to bite the bullet now and be done with this.

[antoniovazquezblanco]

Perfect!

Do you think is easier to go lowercase -> native language capitalization than the other way around? That is what I get from your summary and for me looks like more maintenance work than the other way around.

If you split this work in tasks I am willing to start contributing. I have never worked with your sourcecode so I prefer to get more strict requirements on the tasks to avoid doing something you may not like.

Thanks

[TurboGit]

My view on this:

• current dt is lower-case
• we need to extract somehow all strings (probably starting from pot files) - these are the strings as they appears in the code, let's call them code-strings
• from there, we can capitalize automatically all code-strings (start with capital letter, after a dot use a capital letter...) standard rules. We probably want to have an exception list and certainly not change word that have currently at least one capital letter.
• Then the harder part, we need to match the strings with new casing into the code, this is the harder part as the strings may span multiple line and be split into multiple strings. Remember in C a single string can be written:

  "some text which"
  " is continued here."

• When we have replaced all strings into the code, we have broken all translations. So we also need to replace all new capitalized strings into all the po files.

At this stage most of the work is done. We just need to provide a way for translator to update the translated text with the same rule if needed as we don't want to impose them to rework all translations to also use capital letters.

When this is done, we are done :)

Note that this to land into the code needs to be ready well before a new release because I do expect some special case to need some manual fixes.

Let me know if something is not clear. And thanks a lot in advance, this is a quite big project!

[antoniovazquezblanco]

I have tryed to use polib to read current English translation file and I have used CoreNLP to try and automatically truecase the sentences with poor results for the time being...

I will revisit this soon.

Thanks

[antoniovazquezblanco]

A second attempt using the https://pypi.org/project/truecase/ package was made. Results were really poor. Mostly, theese NLP packages do not recognize acronyms.

I will have another go soon.

Thanks

[antoniovazquezblanco]

A gist of some of my attempts: https://gist.github.com/antoniovazquezblanco/7c02b08e939bb05b38326d7b83d23a86

[github-actions[bot]]

This issue did not get any activity in the past 30 days and will be closed in 365 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.

[elstoc]

Because we're having some discussions about this on IRC I just thought I'd mention that, while we might be able to script a lot of this in darktable, it will probably be an entirely manual and laborious task in dtdocs. Personally I'm fine with the labels staying lower case but the tooltips with full stops in them (followed by lowercase letters) really bug me. If we kept the labels unchanged I wouldn't have to update dtdocs :)

[elstoc]

Further to my comment (and others) above and following some discussions in other issues, I'd say we could keep lower case as a "house style" (hanatos started dt and he is very pro-lower-case!) for most things and try to be sensible with other expected conventions. I guess my ideal house style would be something like the following...

• Names of things defined by darktable developers (the name of the application, controls, buttons, sliders etc.) are written in lower case.
• Named keyboard keys should be referenced with an initial capital letter, e.g. Ctrl, Shift, Alt, Esc, and with CamelCase for the AltGr key. This is a convention in dtdocs at the moment and is (IMO) useful as an indicator that a keyboard shortcut is being referenced. Also this does seem to be more of an accepted external standard that people might already expect.
• When combining keys to describe a shortcut, they should be connected with a plus sign (e.g. Ctrl+Shift+h)
• Clicks of the mouse should be referenced in lower case. Multiple clicks should be joined with a hyphen, e.g. click, single-click, double-click, right-click etc. Similarly for "scroll"
• Single letter key presses should be expressed in lower case. This makes sense since, for example, the keyboard shortcuts Ctrl+Shift+h and Ctrl+H might otherwise get easily confused (especially when you consider the dreaded CapsLock). When referencing a single letter key on its own, quotation marks might be a good idea. For example, press "h" to see a list of active shortcuts.

However, the above rules should never override standard conventions of language, since these will be "expected" by even a semi-literate user and seem unprofessional when not observed. Namely, that sentences always begin with a capital letter, even when the first word of that sentence falls under the house style above (yes, you should either write "Darktable" at the start of a sentence or never ever start a sentence with that word). Following a full stop with a lower case letter looks especially bad to everyone who has ever been taught to write. This last paragraph will mainly impact tooltips and the user manual.

[github-actions[bot]]

This issue did not get any activity in the past 60 days and will be closed in 365 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.

[ralfbrown]

I believe the new en@truecase translation has addressed this.

[RokeJulianLockhart]

https://github.com/darktable-org/darktable/issues/2078#issuecomment-1528882683

@ralfbrown, I think this needs to be more discoverable. 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).

[ralfbrown]

The tooltip when hovering the language pulldown does say "(restart required)", but maybe that needs to be part of the label instead, i.e. "interface language (restart required)"? @TurboGit

[TurboGit]

The tooltip when hovering the language pulldown does say "(restart required)", but maybe that needs to be part of the label instead, i.e. "interface language (restart required)"? @TurboGit

No, this is done this way for all preferences where a restart is needed. The description is part of the XMP file and for this item in preferences.c (again consistency is better here to me).

[victoryforce]

#2078 (comment)

@ralfbrown, I think this needs to be more discoverable.

It is not clear from your comment what exactly should be more discoverable. Availability of en@truecase? Probably not. Then what?

I had to search within the closed issues section on this tracker to ascertain that the option would be listed as a translation,

I did not understand the purpose of your search. What did you do it for?

and even then, the fact that a restart of the application is necessary isn't communicated to the user

This fact is communicated to the user. It is difficult for me to understand how you could not see the text darktable needs to be restarted for settings to take effect when exiting the settings.

I expected that the feature didn't function after I hit apply (because there was no success feedback there either).

There is only one "apply" button in the global settings interface: save CSS and apply. It appears that you clicked this button to apply the language change. If so, we should probably change the text on that button to make it even clearer that it's for CSS only. What would you suggest?

[RokeJulianLockhart]

It is not clear from your comment what exactly should be more discoverable. Availability of en@truecase? Probably not. Then what?

@victoryforce, I don't know what you refer to by "availability", but indeed, the option for en@truecase - it's not actually a translation, so I wouldn't have expected to locate it in that flyout.

I did not understand the purpose of your search. What did you do it for?

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).

---

This fact is communicated to the user. It is difficult for me to understand how you could not see the text "darktable needs to be restarted for settings to take effect" when exiting the settings.

Where does the GUI state that? I don't see it, even in retrospect:

---

There is only one "apply" button in the global settings interface: save CSS and apply. It appears that you clicked this button to apply the language change. If so, we should probably change the text on that button to make it even clearer that it's for CSS only. What would you suggest?

It's certainly clear that it's for CSS only, but being a novice at that language, I momentarily forgot that that wouldn't encompass things like language. A label like "Apply style (CSS)" would probably be better, but a specific label that explains that it doesn't apply anything else would really be the sole way to communicate this effectively to the lay man.

[victoryforce]

1. It is not clear from your comment what exactly should be more discoverable. Availability of en@truecase? Probably not. Then what?

   @victoryforce, I don't know what you refer to by "availability",

By "availability" I mean the same thing that can be described by other synonyms: "presence", "the possibility to choose". You wrote "I think this needs to be more discoverable.". I'm just trying to understand what exactly you mean by "this".

Maybe you do mean the "en@truecase" version of the GUI text, but then it is not clear why it is about its discoverability. After all, it is in the list of options of the parameter that controls the change of the GUI text. Where else could it be?

but indeed, the option for en@truecase - it's not actually a translation, so I wouldn't have expected to locate it in that flyout.

Yes, it is not another language in the strict sense. What is the problem with this? I only see words that this is "unexpected" for you, but I don't see any suggestions.

What can we do to meet your expectations? Advertise the presence of a non-lowercase version of the interface somewhere? Where would you expect to see it?

2. I did not understand the purpose of your search. What did you do it for?

   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).

You wrote: "I had to search within the closed issues section on this tracker to ascertain that ...". I was just wondering why this particular search was necessary (you wrote "I had to"). You didn't answer, instead you write about something else.

Regarding your link, I still don't understand why you are writing this to me. I was the one who pushed the idea of ​​creating an option of GUI without forcing everything to be lowercase. Moreover, I once had the very link you provided saved in case I had to convince the team of the desirability of moving away from the legacy style (but no one had objections).

3. This fact is communicated to the user. It is difficult for me to understand how you could not see the text "darktable needs to be restarted for settings to take effect" when exiting the settings.

   Where does the GUI state that? I don't see it, even in retrospect:

Right in front of your eyes after you close the settings window.

4. There is only one "apply" button in the global settings interface: save CSS and apply. It appears that you clicked this button to apply the language change. If so, we should probably change the text on that button to make it even clearer that it's for CSS only. What would you suggest?

   It's certainly clear that it's for CSS only, but being a novice at that language, I momentarily forgot that that wouldn't encompass things like language. A label like "Apply style (CSS)" would probably be better, but a specific label that explains that it doesn't apply anything else would really be the sole way to communicate this effectively to the lay man.

@elstoc Can I ask you to recommend the wording?

[RokeJulianLockhart]

1. After all, it is in the list of options of the parameter that controls the change of the GUI text. Where else could it be?

2. What can we do to meet your expectations? Advertise the presence of a non-lowercase version of the interface somewhere? Where would you expect to see it?

@victoryforce, I would have expected a separate checkbox to appear for "Capitalisation", since not solely English is affected by lower-case wording. As an example, https://github.com/darktable-org/darktable/issues/2078#issuecomment-462080918 depicts lower-case sentence starts, despite the nouns being capitalised, per German convention.

Yes, it is not another language in the strict sense. What is the problem with this?

I predict that, like me, another user looking for the option shan't think to check the language flyout for an option that isn't a language.

Regarding your link, I still don't understand why you are writing this to me. I was the one who pushed the idea of ​​creating an option of GUI without forcing everything to be lowercase.

You asked what the purpose of the search was. What you've quoted answers that query of yours. What is the reason for your confusion?

---

Right in front of your eyes after you close the settings window.

Indeed:

I expect that the low contrast of the selected theme and the fact that the notification pill of sorts isn't a standard notification dialogue window contributed to me missing it. I would have expected the menu in the aforereferenced configuration window.

[victoryforce]

@victoryforce, I would have expected a separate checkbox to appear for "Capitalisation", since not solely English is affected by lower-case wording.

That's not how it works. The translation is the result of the work of the translator, who decides what the translation will contain and what the register of words will be. It's that simple. There can be no "Capitalization" checkbox that magically changes the case of words in ANY translation.

As an example, https://github.com/darktable-org/darktable/issues/2078#issuecomment-462080918 depicts lower-case sentence starts, despite the nouns being capitalised, per German convention.

If this (or something else) looks wrong to you, you can raise an issue or propose a pull request with a fix yourself.

I predict that, like me, another user looking for the option shan't think to check the language flyout for an option that isn't a language.

And? What is your proposal?

[RokeJulianLockhart]

There can be no "Capitalization" checkbox that magically changes the case of words in ANY translation.

@victoryforce, I'm aware of that - language is too inconsistent to have effects applied to it in that manner - but it could apply instead solely to en-.*, so that it could appear solely when that option is (pre)selected.

--- Luckily, since this GUI uses CSS, there's something very similar in [the aforereferenced answer](https://ux.stackexchange.com/revisions/33744/1#:~:text=th.toLowercase%20%7B%20text%2Dtransform:%20lowercase;%20%7D): > ```CSS > element.toLowercase { text-transform: lowercase; } > ``` However, per the German translation, I imagine that, irrespective, your translators manually capitalise proper nouns, so that would require a rethink of how you lower-case strings. ---

If this (or something else) looks wrong to you, you can raise an issue or propose a pull request with a fix yourself.

It's not, else I would have done so. German uses capitalised proper nouns - it's explicitly stated in the referenced comment.

And? What is your proposal?

Since you've asked, my best idea is to have a checkbox appear when en-.* is selected, which is labelled "Sentence case". Think it's any good? Thanks for asking.

[elstoc]

@elstoc Can I ask you to recommend the wording?

I guess you're just talking about the "save CSS and apply" button here (I really don't care to follow the rest of these arguments and have already unsubscribed from this discussion once).

I'd have hoped that the fact that the button is placed within the text box makes it clear that this is associated with that text only and not some sort of UI glitch. I guess "save and apply CSS changes" is maybe clearer (and it includes both "save" and "apply" because technically it's saving the contents of the box to a file and then applying those CSS changes), but IMO it's clear enough already especially when you take into account that it also has a tooltip with more words.

[elstoc]

Just to note here though, 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 and stop posting on closed tickets.

[RokeJulianLockhart]

IMO it's clear enough already especially when you take into account that it also has a tooltip with more words

@elstoc, 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.

[elstoc]

There's literally a question mark button next to the apply button, which opens the manual to the correct page. This is a non problem.

[RokeJulianLockhart]

https://github.com/darktable-org/darktable/issues/2078#issuecomment-2323282195

@elstoc, I was referring to the other elements in the window:

Apologies for being non-specific.

[elstoc]

I was referring to the other elements in the window

They're discussed in the same user manual page

[RokeJulianLockhart]

https://github.com/darktable-org/darktable/issues/2078#issuecomment-2323290464

@elstoc, it appears so. Thanks. I expected that the help button was the same for all pages - that it was window-specific (since the bottom bar remains unchanged between views) rather than viewbox-specific. I should have checked.

Although the relevant documentation is notably absent about the truecase variant:

interface language
: Set the language of the user interface. The system default is marked with an * (needs a restart)

I'll try to add it to https://github.com/darktable-org/dtdocs/blob/963da6b239cc3f25e0c3bbf845715b768c55dd59/content/preferences-settings/general.md?plain=1#L10-L11 if I can think of the correct phrasal.

[elstoc]

Although the relevant documentation is notably absent about the truecase variant:

hence my suggestion to update the manual