It would be nice to eliminate remaining inconsistency with spelling of the word 'gray'

[victoryforce]

Different spellings in different parts of the program are not good. As for the word "gray", its spelling is almost consistent and the source code already uses only American spelling. But there are two other places where another, British spelling is still used:

• darktable theme names in the settings interface. These are just the names of CSS files, so we should just rename these files, bringing the word "gray" in their names to the consistent American spelling.

• In addition, in CSS files, color definition names also have a British spelling (such as grey_20, grey_70 etc). Here, in order not to break backward compatibility with CSS tweaks already written by users, we should just add similar color definitions with American spelling.

[Nilvus]

I agree. Or with one or the other. As I'm french, I don't care. The manual would also need to be updated accordingly. @elstoc: what's your view on that?

@victoryforce: I'm not for your suggestion to add color definitions with American spelling. This will override CSS. It's just CSS, not strings visible on the UI. And as I nearly completely rewrite CSS for darktable 4.0, backward compatibility is already broken (many classes added, much shorter code and id names removed). So it's the good time to change that if we want to. If you don't mind, as I know CSS files and this would need to check if we have or not bad side-effects (I'm quite sure we will not have any), I prefer work on that.

@TurboGit: as this should not affect translations, and regarding my last comment about changed CSS and broken backward compatibility, probably this can be done for darktable 4.0?

[Nilvus]

@victoryforce: I'm not for your suggestion to add color definitions with American spelling. This will override CSS.

I mean overload CSS of course (not override...)

[TurboGit]

@Nilvus : Well I agree that it should be fixed, but as this quite invasive change (gray_xx vs grey_xx in CSS) I would certainly prefer having that for 4.0.1. We are too close to the release to introduce possible regressions for something that is not visible to users (except the name of the CSS file).

[Nilvus]

I'm ok for that. So at least just the name of CSS file. Will wait for @elstoc and @victoryforce feedback before working on that.

[victoryforce]

@Nilvus Just renaming of CSS files would be great for 4.0. Spelling of CSS color definitions is very minor issue and it can be discussed separately and wait for next releases.

[elstoc]

Yes I'm all for consistency in the UI but beyond that, fixing the code and/or CSS seems unnecessary and invasive (I count nearly 900 uses of "grey" in the C code). For the CSS file names it's worth testing how it will work if someone has a gr[e|a]y theme on upgrade -- we need to ensure it will "fail" in a graceful way (fall back to the default theme).

It's been like this for ages though so there's absolutely no hurry to get it done for 4.0.0.

[aurelienpierre]

Please don't break CSS and preferences to try and fix divergences between flavours of English. It's not worth it.

[Nilvus]

@elstoc: if we have so much grey words on code, it's better to not change anything. And probably never. Maybe just about filename, but it's also not the more important thing to update. I agree with @aurelienpierre here: it's not worth it. Even if consistency is a good thing.

[elstoc]

I think we should just change everything in the UI to British spellings ;-)

[MStraeten]

we already had string freeze and a couple of further cosmetic changes on strings after that causing additional effort to provide a completed translation. So please no further string changes for 4.0. if someone want's to have a british or american gui providing a po file for that might be a solution;)

[victoryforce]

I will divide my comment into a few shorter ones for better structured answers. I agree with all of the remarks about the importance of not breaking things too much and about the line between necessary and unnecessary edits (as elstoc wrote, there is absolutely no need to edit 900 words in the comments or elsewhere in the code, and I'm far from suggesting this, as you might guess).

I'll start with this comment which is slightly inaccurate:

we already had string freeze and a couple of further cosmetic changes on strings after that causing additional effort to provide a completed translation. So please no further string changes for 4.0.

There are no translatable string changes in this proposal so no efforts for translators.

if someone want's to have a british or american gui providing a po file for that might be a solution;)

This is a very good solution indeed! I'm serious. I think it's worth implementing and creating a .po file for British English. But first we need to make the original consistent, not a mixture of British and American spellings (when even the same word is found side by side in different spellings). And that's what I'm trying to achieve.

[TurboGit]

we already had string freeze and a couple of further cosmetic changes on strings after that causing additional effort to provide a completed translation. So please no further string changes for 4.0. if someone want's to have a british or american gui providing a po file for that might be a solution;)

Agreed, but note that the changes made after the string freeze where already broken and would have made the UI displaying an English word or "(NULL)". So somehow it was already broken, we have allowed some minor changes to make it possible to eventually fix those strings. But it was better to have an English word instead of "(NULL)".

[TurboGit]

But here, as I said we will certainly not change anything for 4.0.

[victoryforce]

Next, about the less important (of two) proposal of adding "gray" color definitions to the CSS.

Rationale: the user will not be surprised why he/she sees the word "gray" in the whole interface, but in the CSS tweak box have to write "grey".

Adding color definitions even theoretically can not break anything. I completely agree with Nilvus that this is an overload (if we add rather than replace the definitions). But the sole purpose of this overload is to allow the user who wants to add their CSS tweaks to use the spelling that is right for him/her, as both options will be supported.

@Nilvus, if I understood your first comment correctly, you prefer replacing rather than adding new definitions (because you don't like excessive overload). But @TurboGit is right that regressions (even if they are almost impossible) when we are too close to the release are undesirable. For me it looks like a good plan will be to add new definitions now, and after the 4.0 to remove British spelling options if you insist it is necessary (I wouldn't do that, though).

[victoryforce]

Next, on renaming themes.

I'll start with a list of what the proposed change really do break. This list consists of one and only one element:

• Only if the user has previously selected theme "darktable-icons-grey", it will be reset to the default theme ("darktable-elegant-gray") and the user will lose the icons in the theme after the upgrade (but not the overall lightness level). This is the only thing that will be broken.

For the CSS file names it's worth testing how it will work if someone has a gr[e|a]y theme on upgrade -- we need to ensure it will "fail" in a graceful way (fall back to the default theme).

I checked it out. Yes, if there is no file with the name specified by the user-selected theme, the default theme will be selected. At the moment, this will be the theme "darktable", and that is a bug, by the way, but until the renaming I proposed, this bug just won't show up. When the theme files with "grey" in the name will be renamed, I will fix this to fall back to "darktable-elegant-gray", not "darktable".

I think we should just change everything in the UI to British spellings ;-)

Seriously, why not. I don't care about the spelling of the original, as long as it is consistent. Inconsistency, that's what looks ugly and annoying to many.

[elstoc]

I think we should just change everything in the UI to British spellings ;-)

I think the big issue is the word "color", which appears throughout the code and is generally unavoidable, due to css conventions and other code using American English. It's that more than anything that tends to push the UI (on this and other software) to American spellings, even though most of the darktable developers are European and so tend more towards British spellings (hence all the inconsistencies we've been ironing out).

I'm sure everyone worked out that I was kidding about British spellings, but as with @victoryforce, I'm more concerned with consistency than anything else (though "gray" will always look wrong to my eyes). I certainly wouldn't want to bother with a separate GB translation -- I'm not sure how enthusiastically it'd be maintained (I wouldn't be interested in maintaining it).

Again, no objection to changing the spelling of the theme names but it's not a bug, and this particular inconsistency is fairly long-standing, so it's not necessary to change it now. Nothing to do with string freeze, just to do with limiting any unnecessary changes in the lead-up to a release.

[Nilvus]

Next, about the less important (of two) proposal of adding "gray" color definitions to the CSS.

Rationale: the user will not be surprised why he/she sees the word "gray" in the whole interface, but in the CSS tweak box have to write "grey".

As you said, it's the less important. Thinking more and more about that and discussion here, I finally think it's better to not change anything on CSS files (and on darktable code). That will avoid regression to fix for such a minor thing.

About your "rationale", I'm quite there's probably few users that tweaks CSS. And by now, I never see anyone complaining about gray or grey word. They probably don't care. I'm also all about consistency but I'm also to not complicate our life or other users one. And if we have nobody complaining about that, why change it if we risk regressions and so lost time to change code then to fix regressions. Not for me.

Adding color definitions even theoretically can not break anything. I completely agree with Nilvus that this is an overload (if we add rather than replace the definitions). But the sole purpose of this overload is to allow the user who wants to add their CSS tweaks to use the spelling that is right for him/her, as both options will be supported.

We talk about CSS code and few people that tweaks it. So it's really not a problem if the user do not see the spelling right for him/her. British english is the traditional one. American spelling had been made after and based on British english. We can't please anyone and spend (lost) time to please some that never complains about that and for little time they will spend on work regarding the risk to break or load code, do not need to spend more time on that.

@Nilvus, if I understood your first comment correctly, you prefer replacing rather than adding new definitions (because you don't like excessive overload). But @TurboGit is right that regressions (even if they are almost impossible) when we are too close to the release are undesirable. For me it looks like a good plan will be to add new definitions now, and after the 4.0 to remove British spelling options if you insist it is necessary (I wouldn't do that, though).

My first comment was before understanding that this will need more code changes than I previously thought and so understand more risk to have regressions. I'm now to not change anything on CSS code.

[Nilvus]

Again, no objection to changing the spelling of the theme names but it's not a bug, and this particular inconsistency is fairly long-standing, so it's not necessary to change it now. Nothing to do with string freeze, just to do with limiting any unnecessary changes in the lead-up to a release.

I completely agree. And, @victoryforce, note that this is here since at least 4 or 5 years. Should be since there's CSS code on darktable.

[aurelienpierre]

This project has already diverted more man-hours than what it will ever return.

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

[github-actions[bot]]

This issue was closed because it has been inactive for 300 days since being marked as stale. Please check if the newest release or nightly build has it fixed. Please, create a new issue if the issue is not fixed.