Add the sentence case version of Darktable UI that can be selected as another UI language

[victoryforce]

For many years there has been a request to get rid of the exotic "no-caps" darktable style, in which everything possible was converted into lower case.

There were those who, over the long history of darktable existence, got used to this style and even consider it more pleasant.

But just as many, if not more, people find this style very annoying.

What can be done in this situation? The right solution must meet the following requirements:

• Users should be able to choose the style of the interface (old "no-caps" or normal casing, as in other programs). That is, it should not be an irreversible change of style.
• If possible, it should be done with minimal effort.
• This decision should not impose extra work on translators.

The only solution that meets these requirements is to add a pseudo-translation, which will be in the same original language, but with the corrected case of the words.

This "translation" was created and completely reviewed and corrected manually. I can say with a large degree of confidence that it is 100% (ok, 99.9% due to human factor) free of errors related to the shortcomings of automatic case conversion.

I expect everything regarding the fate of this PR from being included in 4.0.1 to being frozen forever due to fruitless discussions, but I hope that it will not be rejected. :)

So I'm keeping my fingers crossed and hit the "Create pull request" button.

[TurboGit]

Thanks, and I'm one of the guy which would move away from all lower-case, but..

I don't think this is the right way to go. We want to convert all the strings in the C code that will be then be used as base for the translation automatically (that's what is done when I create the darktable.pot file). From there we need to change all the English strings in all po/*.po file to not break the translation.

At this stage we have a UI with capital letters for English. Great!

Next step if for all translators to also translate their language with capital letters if they like.

This is the plan (I have already exposed this somewhere, don't remember where at the moment).

[TurboGit]

Found the reference : https://github.com/darktable-org/darktable/issues/2078#issuecomment-749031332

[TheBB]

As someone who desperately wants capitals in the UI, this translation file seems like it checks the first few items in your plan of attack. If we continued with it now (using this as a starting point), would there be sufficient will to get that merged? I'm just asking because the longer we wait the less useful this starting point becomes.

[TurboGit]

@TheBB : No this is not a good starting point as I have explained. The plan to have a proper capitalized UI for all languages is a bit more challenging. I suppose that someone with good Python skill and lot of energy could setup something to do the needed changes.

[TheBB]

@TurboGit then maybe you can clarify. You wrote in https://github.com/darktable-org/darktable/issues/2078#issuecomment-749031332

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

So presumably the po-file in this PR constitutes a database of already capitalized code-strings. Not automatically capitalized code-strings, but capitalized code-strings nonetheless.

• Then the harder part, we need to match the strings with new casing into the code

And it seems to me that, as you say, "someone with good Python skill and lot of energy" could proceed with this step in a new branch, using the po-file as a source of new strings.

[victoryforce]

And it seems to me that, as you say, "someone with good Python skill and lot of energy" could proceed with this step in a new branch, using the po-file as a source of new strings.

And who's that?

[TheBB]

I'm willing to give it a shot, though we'll see if the energy part of the equation holds up. I just wanted some clear indication that if this PR is rejected because it doesn't align with https://github.com/darktable-org/darktable/issues/2078#issuecomment-749031332 then one that does would be, if not necessarily approved then at least considered.

[victoryforce]

one that does would be, if not necessarily approved then at least considered.

I began this work without even imagining that this PR could be rejected, since it (unlike the plan from https://github.com/darktable-org/darktable/issues/2078#issuecomment-749031332) is not controversial. Moreover, I consider the mentioned plan to be a downright failure in terms of not getting feedback from users. My plan was not to immediately make irreversible changes, since having an intermediate implementation in the form of a pseudo-translation, we can always listen to the wishes of users.

Well, I'm going to have to explain in more detail now (see the next comment) why I don't agree.

[victoryforce]

Later on, it may be appropriate to implement the discussed plan, but you should not start with it.

It solves the problem nicely if everyone agrees to "kill" the current UI style and everyone agrees on a specific style from the possible options: "sentence case", "title case", some mix of different styles for different UI elements... I'm not sure right now which is better.

My pseudo-translation is just a suggestion that can be easily changed without having to make changes to the source code. In addition, the transition from such a pseudo-translation to the replacement of the original texts will be simply imperceptible to the user. After all, when the user chooses English(en@truecase) as the UI language, and later we remove this "translation" and make changes to the source code, the user simply won't notice the transition.

In fact, right now I'm not even sure which option I would choose myself. I need more time to understand what I like more. I'm already so used to the current lowercase interface that the interface "like other programs" seems a little unusual to me. :)

To summarize, there may be different views. So it would be best to give users an opportunity to evaluate changes in the interface and hear their feedback. And only then start the big and irreversible work of replacing the interface texts in the source code.

So my suggestion would be to add this "translation" to the upcoming 4.0.1 release to give users more time for feedback.

[TurboGit]

I'm willing to give it a shot, though we'll see if the energy part of the equation holds up. I just wanted some clear indication that if this PR is rejected because it doesn't align with #2078 (comment) then one that does would be, if not necessarily approved then at least considered.

Thanks @TheBB ! This will definitely be considered. Many people have requested this, and I'm myself ok for this move as expressed many times. I do not remember having heard someone asking to keep the UI all lower-case ! So I'm pretty sure this will be not on considered but merged. Thanks a lot for taking this project. Do not hesitate to keep us informed about the status, do not hesitate to ask if something needs clarification.

[elstoc]

I have previously stated that I'm more than happy to keep the module and control names lower case. I don't personally see an issue with that. My only complaint is the tooltips, where we completely ignore the rules of grammar and have sentences that start with lower case letters.

Please note that we have kept the all-lower-case style in dtdocs as well so as soon as you merge anything that rewrites this it will be a massive job for dtdocs to reflect it and because we use weblate for translations, I'm not convinced we can easily do it in an automatic way. I really don't want to have to do that much manual editing, and invalidate all of the dtdocs translations.

[aurelienpierre]

Already implemented in https://github.com/aurelienpierre/R-Darktable/commit/31d406c5eb30e0efe1b34e04bd8d7a904afb6997

The gist is:

void dt_capitalize_label(gchar *text)
{
  if(text)
    text[0] = g_unichar_toupper(text[0]);
}

then it's 37 LoC and no translation breaking (except for Hebrew, Chinese, Japonese and Cyrillic langages where I have no way of checking how upper case behaves).

[elstoc]

Again, simple to do in darktable but I'm not sure how it would be possible in dtdocs (in fact I'm virtually certain it wouldn't be)

[aurelienpierre]

See https://gist.github.com/aurelienpierre/a2722cf0603fd1511c5943f598bb7344

[dterrahe]

text[0] = g_unichar_toupper(text[0]);\n

This could give interesting results if the first character is multibyte unicode.

[github-actions[bot]]

This pull request did not get any activity in the past 60 days and will be closed in 365 days if no update occurs. Please verify it has no conflicts with the master branch and rebase if needed. Mention it now if you need help or give permission to other people to finish your work.

[TurboGit]

@victoryforce : Given all the recent try to have this done somehow I'm now convinced that your proposal is the only one that will be accepted somehow. This transfer the casing style to the actual translator. The only drawback here is that we will now need a English translation to be maintained. But no big deal.

Please let me know if you want to pursue this and update this PR and we will move forward.

@Nilvus @dterrahe @elstoc Pinging you here as you've been all discussing/working-on this.

[elstoc]

I have no objections to an optional change via translation, though I do wonder how much anyone will bother to maintain such a thing.

[dterrahe]

@elstoc I guess this is the time for you to make the case for Title Case...

[elstoc]

TBH I care less now that it's optional and I won't be the one maintaining it. Whether it should be sentence case or title case will very much depend on context though (generally the module and control names should probably be title case and everything else sentence case) and I guess this will be down to whoever chooses to maintain it. I will stick to the lower case version (both because I prefer it and because dtdocs will continue to use it), though I believe the tooltips should still be changed in the core English version. I trust @victoryforce to make good decisions in this regard as he has been very helpful correcting grammar/spelling in the English version of dtdocs and in darktable itself.

[Nilvus]

I completely agree with @elstoc here. No more to add.

[pcanning]

Just a "drive by" comment ... if folks care about "enforcing" maintenance, one could imagine incorporating some sort of case-insensitive diff of the two English translations into the CI build, and failing the build if the the diff produced any unexpected differences. I did something similar (but it was more complex than a simple diff) many years ago for in day time job to detect changes that inadvertently broke API compatibility. We checked in a file containing the expected output of the comparison tool, so we could update that file in the (hopefully rare) case that was necessary.

[TurboGit]

@victoryforce : What's your point of view on this at this stage. Do you plan to pursue? If not let's close. TIA.

[victoryforce]

Do you plan to pursue?

Definitely yes. I had a few other unfinished tasks on my to-do list, so this task was on the waiting list. I will definitely update the translation before the release. Hoping to start this weekend or within the next week. This should not take much time, because most of the strings have already been translated, it remains to process the changes.

[victoryforce]

@TurboGit Updated to current state of darktable.pot. Tested again after update. I think it's ready for merging.

[victoryforce]

Thanks! Indeed, "rgb" in module names should now be written in upper case. Regarding the original English interface, I did not propose such a fix due to the feeling that RGB in capital letters would "dominate" the module name in lower case and distract from the actual module name.

[pehar1]

Thank you soooooo much. Finally, if we want, we can get rid of this highly annoying and grammatically incorrect lowercase. Highly appreciated !

[europlatus]

This will make me very happy! I never liked the strange decision of lowercase everywhere, and those tooltips were just migraine inducing for me as an editor by trade. Not to mention that styles, folders and presets can all be sentence case, so it wasn't as if the GUI looked uniform.