Solves #3556.
This PR: 1. Replaces yyyy/mm/dd format in "Edit > Insert date" with yyyy-mm-dd (which happens to be the recommended format in ISO 8601), and mm.dd.yyyy with mm/dd/yyyy (using slashes seems to be more common for that date format), leaving dd.mm.yyyy as is (with dots). 2. Updates all the translation files accordingly (e.g., `es.po` currently translates the string `yyyy/mm/dd` to `aaaa/mm/dd`; this needed to be updated as well). 3. Sets yyyy-mm-dd as the default (first option in "Insert date", default custom date format, and also uses it in "Date & time" under Edit > Preferences > Templates, which is currently using inconsistent date formats).
I have split this PR into three commits for convenience, just in case the devs don't want to pull all of it. _(For example, I understand that @frlan is currently fidgeting with the translations and maybe doesn't want to pull the commit that touches them.)_ Feel free to squash them if preferred. You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/3570
-- Commit Summary --
* Use ISO format yyyy-mm-dd instead of yyyy/mm/dd * Update translations with new date format * Make yyyy-mm-dd the primary date format
-- File Changes --
M po/ar.po (16) M po/ast.po (16) M po/be.po (16) M po/bg.po (16) M po/ca.po (16) M po/cs.po (16) M po/da.po (16) M po/de.po (16) M po/el.po (16) M po/en_GB.po (16) M po/es.po (16) M po/et.po (16) M po/eu.po (16) M po/fa.po (16) M po/fi.po (16) M po/fr.po (16) M po/gl.po (16) M po/he.po (16) M po/hi.po (8) M po/hu.po (16) M po/id.po (16) M po/ie.po (16) M po/it.po (16) M po/ja.po (16) M po/kk.po (16) M po/ko.po (16) M po/ku.po (16) M po/lb.po (16) M po/lt.po (16) M po/lv.po (16) M po/mn.po (16) M po/nl.po (16) M po/nn.po (8) M po/pl.po (16) M po/pt.po (16) M po/pt_BR.po (16) M po/ro.po (16) M po/ru.po (16) M po/si.po (8) M po/sk.po (16) M po/sl.po (16) M po/sr.po (16) M po/sv.po (16) M po/tr.po (16) M po/uk.po (16) M po/vi.po (16) M po/zh_CN.po (16) M po/zh_TW.po (16) M src/templates.h (2) M src/ui_utils.c (26)
-- Patch Links --
https://github.com/geany/geany/pull/3570.patch https://github.com/geany/geany/pull/3570.diff
LGBI.
Maybe updating the translation files is not necessary at all. It would happen with the next string freeze automatically.
For the upcoming release it's too late, I think :(.
I didn't check the GIT history and I don't remember but there is a certain probability that it was me introducing "dd.mm.yyyy" as default format as this is the German variant and I'm used to it. My excuse is that this was more or less 18 years ago and I was young and ignorant :).
I didn't check the GIT history and I don't remember but there is a certain probability that it was me introducing "dd.mm.yyyy" as default format as this is the German variant
Although according to Wikipedia the DIN now allows dots as well, clearly you were prescient. :grin:
Indeed drop the translations, its just noise that hides the useful changes, as @eht16 says translations are updated at release. And those strings shouldn't be translated anyway IMO, they are a pattern, not words.
The discussion on #3556 was to __ADD__ ISO format, not to replace an existing one, yyyy/mm/dd. Somebody added it at some point, so somebody wanted it at some point, removing it without discussion is unacceptable IMO.
Indeed drop the translations, its just noise that hides the useful changes, as @eht16 says translations are updated at release.
OK, I can exclude that commit. Although someone will need to add the translation at some point.
And those strings shouldn't be translated anyway IMO, they are a pattern, not words.
Well, they're translated in several languages. And it makes sense IMO; for example, a Spanish speaker who is not well versed in other languages may not necessarily know that "y" means "year" in English, and would prefer to see it as "aaaa-mm-dd" ("a" for "año"). (OK maybe that was a bad example because it's clear that the 4-digit one is going to be the year, but there are less obvious examples such as Hungarian "nn.hh.éééé", or Bulgarian "дд.мм.гггг", or Korean "일.월.년".) But it's true that it feels weird to translate a code. It just happens to have a translation. (And, to be fair, the ACTUAL patterns are %Y-%m-%d and the like; "yyyy-mm-dd" is just pseudocode inspired in other programs such as Excel which use this formatting syntax.)
The discussion on #3556 was to **ADD** ISO format, not to replace an existing one, yyyy/mm/dd. Somebody added it at some point, so somebody wanted it at some point, removing it without discussion is unacceptable IMO.
Oops. Well, I did mention _"probably replacing yyyy/mm/dd"_ in my comment and nobody seemed to protest so I kinda assumed it was OK. Also it felt kind of redundant to have both yyyy/mm/dd and yyyy-mm-dd (plus, I'm not sure anyone uses that format anyway... maybe in South Africa?), so I assumed it was OK to just replace it with the hyphens one, rather than adding a fourth format that is almost identical to another format.
I'll continue the discussion in #3556 then.
For the upcoming release it's too late
I don't think this is too urgent so that's OK.
LGBI
You make no idea how long it took me to figure out that this meant "looks good by inspection" :laughing: (Apparently you're the only ones using this acronym.)
OK, I can exclude that commit.
Thanks
For translation or not, lets leave it to @frlan as the translation maestro, your allusion to Excel and others is why I considered it a pattern, a human pattern, as you say its not the % patterns, but I'm only an English (well one variant) speaker so I don't know it is just an opinion.
I'm not sure its worth more discussion on #3556, unless you have a good reason to remove existing options just leave the existing items there and add ISO where you want it (presumably at the top :-).
LGBI
Thats my fault, I started it because I am often away from my development machine, and then when I'm back I have other things to work on (not Geany gasp ;-) so inspection is often all I can do. As you can see its has now infected others on the project. :grin:
I would merge this just before the string freeze (which is not yet announced, also due to #3551), but yeah I would also exclude the .po changes. Does anyone object?
yyyy/mm/dd. Somebody added it at some point, so somebody wanted it at some point, removing it without discussion is unacceptable IMO.
Apparently that was @eht16 waaay back in 2006 (312579d); the three formats were added simultaneously on the very moment the "Insert date" feature was added. I don't think that yyyy/mm/dd (with slashes) was specifically chosen for any reason; just to provide a YMD format.
unless you have a good reason to remove existing options
Well, that's why I wanted to discuss it further... I think that having three options to provide YMD, MDY, and DMY formats is enough. I guess you cannot have everyone 100% happy like this; for example in Spain the most common format is `d/m/yyyy` with slashes; but if we're adding all the combinations of orders and separators that menu is going to become annoyingly large. So I thought it was better to keep it simple and just have the three major options; any minor variation could go through the "custom format".
Also, having each of YMD MDY DMY use a different separator kinda helps avoid ambiguity. I remember seeing some platform or program (but I can't remember _where_) that allowed you to choose between three date format options: dd.mm.yyyy, mm/dd/yyyy, and yyyy-mm-dd; just those three, each with a different separator. I thought it was a nice idea because that way one can know which format is being used based on the separators. I don't know if this is kind of a _de facto_ convention or just some arbitrary choice they made.
So in short, the reason was that I wanted to keep the menu simple and avoid drowning the user in options, and thought that having yyyy-mm-dd made yyyy/mm/dd redundant.
And that was my dissertation. If I managed to convince you then I'll go ahead with it; otherwise I'll do what you said and leave the four formats. For now I'll get rid of the translations.
@cousteaulecommandant pushed 1 commit.
22c791ae3e2abb6829b0083b7386e5fec41f4a02 Make yyyy-mm-dd the primary date format
Translations here are needed and there will be a 2.x version anyway.
As this was a little stuck -- I'd vote for merging ;)
Thanks!
To recap, the reason this got stuck was that there seemed to be a bit of disagreement as to whether I should have added the yyyy-mm-dd format *alongside* the existing yyyy/mm/dd, or *replacing* it. I made my point as to why I think the former was probably a better idea, but the discussion didn't move on.
There was also the issue of me having messed with the po files, but that was already addressed (removed).
Essentially removing somebody's template `yyyy/mm/dd` and replacing it with your `yyyy-mm-dd` is in general rather rude. Just because you may not use a particular template does not mean it is not used by those in other parts of the world, and so it is inappropriate to replace someone elses with yours. Your correct approach is to add yours without removing the existing one.
So, do you think I should leave yyyy/mm/dd in addition to yyyy-mm-dd? I didn't think it was that much of a problem to replace slashes with hyphens; as I said, it felt to me more like a "minor stylistic change" on the YMD template, rather than the removal of a template. Note that I also did change mm.dd.yyyy with mm/dd/yyyy (which I think is more common in places that use MDY format), and left dd.mm.yyyy as is (despite of dd/mm/yyyy being more common in Spain, for example). The important thing is that I kept all dd?mm?yyyy, mm?dd?yyyy, yyyy?mm?dd formats, which pretty much covers all formats used around the world (and more specific formats can always be added as custom formats anyway).
But if you think it's better to have *both* yyyy/mm/dd and yyyy-mm-dd formats in the menu (despite of that causing the menu to be larger for a sort of redundant option), I can leave it as well. Whatever you decide.
And to clarify, I did this not out of rudeness or disregard with other cultures or parts of the world, but on the contrary, as an attempt to find the best compromise solution that would satisfy everyone while keeping Geany simple and easy to use, and to fix an open issue that had been reported. My apologies if this effort was seen otherwise. As I said, a quick glance at https://en.wikipedia.org/wiki/List_of_date_formats_by_country suggested that the use of yyyy-mm-dd was far more common than yyyy/mm/dd (and that the most frequent format overall seemed to be dd/mm/yyyy, which Geany has never supported).
Looking more into the matter, and since you sparked my curiosity, a search of mentions to date formats within that article yields the following table:
| Order | . | - | / | |------------|---:|---:|---:| | dd?mm?yyyy | 27 | 7 | 37 | | mm?dd?yyyy | 0 | 0 | 2 | | yyyy?mm?dd | 0 | 24 | 6 |
So maybe we should add dd/mm/yyyy as well (and perhaps dd-mm-yyyy), if we're really aiming to cover most of the world.
(Personally I feel OK with writing DMY dates as 31.01.2024 despite of being more used to 31/1/2024, so I assumed it wouldn't be as much of a big deal for others as well.)
> I didn't think it was that much of a problem to replace slashes with hyphens
That forces change, the user may have existing /s, so now what do they do that you have replaced it with -s? Edit their whole existing files? Be forced a change? DO NOT ENFORCE WHAT YOU PREFER OVER OTHERS CHOICE. You do not know what others have used, maybe they parse syntax by code, or whatever, do not remove it.
As for `mm/dd/yyyy` vs `dd/mm/yyyy` there is a significant issue, they are both valid/invalid and used in many different places so there is no sensible answer. If one of the templates exist then again it should continue to exist[^1], and if someone can make a PR to add the other for lots of users (indeed based on your excellent study and what is used here).
The only point to also make from the study is that one of the only two mm/dd/yyyy is a biiiig country in software so there is likely to get you much negativism if they lose it :-)
> I did this not out of rudeness or disregard with other cultures or parts of the world,
Rudeness wasn't the right terminology, but I couldn't think of an alternative expression at the time, sorry.
The point that was being made is that none of us know what is used by who, in which parts of the world, so removing existing templates is seen as removing something somebody elsewhere in the world has been using and now they lose their templates. So they then have to consider changing a date in existing files and contents, meaning its no longer what they have been doing, it clashes, and if the date is parsed somewhere its possibly also no longer compatible with the parser. So yeah users are likely to be cranky and suggesting [deleted] descriptions of those who removed their previous template.
Really just add things you personally want and don't remove existing things, if someone else wants their preference they can be added too, so long as the menu doesn't get far too big who cares. But trying to make a universal solution is just too hard, too many formats and countries and separator characters (don't format spaces too).
[^1]: my personal view is that since its impossible to know what a date `1/2/2024` is, `mm/dd/yyyy` or `dd/mm/yyyy` and neither should be accepted no matter what the separator, all date/times should be ISO only and others removed, but too late now.
@cousteaulecommandant pushed 2 commits.
258feac982448ebf6c432615fc3979c53928450c Add ISO format yyyy-mm-dd ab273bc04ca9e899c450728ce8616fccdbf31e25 Make yyyy-mm-dd the primary date format
Fair enough. Maybe I underestimated how much this might inconvenience users.
I have done what you wanted, and also left mm.dd.yyyy unmodified instead of changing it to mm/dd/yyyy as I initially thought made sense.
I've also rebased the branch just in case so that it starts in the newest `master`. (Having a branch that jumps over one year of commits sounded potentially problematic.)
> The only point to also make from the study is that one of the only two mm/dd/yyyy is a biiiig country in software so there is likely to get you much negativism if they lose it :-)
Can't lose what you've never had - the MDY format currently supported by Geany is mm.dd.yyyy, not mm/dd/yyyy, which my PR originally "fixed" as well precisely because it's the format of choice in that country you mention, whereas mm.dd.yyyy doesn't seem to be used. So the big country that uses the mm/dd/yyyy format will have to wait for now. Maybe it makes sense to add that format along with dd/mm/yyyy, but that'll be in a future commit. I can do that and include that commit in this PR if you want, while we're at it - should I? Otherwise I can make a new PR to add the new date formats; whichever you prefer.
> Can't lose what you've never had - the MDY format currently supported by Geany is mm.dd.yyyy, not mm/dd/yyyy,
No problem, I'm not from the biiiig country, we have the order right `dd mm yyyy`, irrespective what the separator is :-)
If people have asked for `dd/mm/yyyy` then thanks lots for doing it for them, otherwise if nobody has asked I guess not enough people use it, so lets not add it to make the menu longer.
As far as this PR, if its easier for you to make a separate simple PR instead of cleaning this one up, certainly do it that way, life isn't long enough to worry about hard ways to do it :-)
> Maybe it makes sense to add that format along with dd/mm/yyyy, but that'll be in a future commit. I can do that
Actually, done - see [this commit](https://github.com/cousteaulecommandant/geany/commit/2dcf132466f194a29499a9c...) in my Geany fork (currently not included in this PR but it takes me zero effort to add it).
The menu with all six formats would look like this: 
As I said, I can include the commit with the extra formats in this PR (and change the title a bit), put it on a new one, or forget about it (so that we only have 4 formats).
> If people have asked for `dd/mm/yyyy`
Me, I have asked for it :D Well not really. To my knowledge, nobody has asked for dd/mm/yyyy nor mm/dd/yyyy, so if you prefer (and the sight of that screenshot terrified you) I can leave those out, and this PR is ready to merge.
For reference, this is what the menu with only 4 date formats looks like this: 
Whichever you want to make available, 4 or 6 is still a small enough menu. The only comment I would make is to order the groups of 6 either by common separators, might make it easier to find what the user is looking for, eg:
``` yyyy-mm-dd dd.mm.yyyy mm.dd.yyyy dd/mm/yyyy mm/dd/yyyy yyyy/mm/dd ``` or order by date arrangement ``` yyyy-mm-dd yyyy/mm/dd dd.mm.yyyy dd/mm/yyyy mm.dd.yyyy mm/dd/yyyy ``` whichever seems to work for users.
Yeah, I wasn't quite sure about the order, so I went with what I thought would be "more common to less common" - ISO first, then US m/d/y, then the one eht16 had set up as preferred back in the day (German style with dots), then the remaining three; but it's true that that order doesn't make any damn sense.
Maybe one of ``` yyyy-mm-dd yyyy-mm-dd dd/mm/yyyy dd.mm.yyyy mm/dd/yyyy mm.dd.yyyy yyyy/mm/dd yyyy/mm/dd dd.mm.yyyy dd/mm/yyyy mm.dd.yyyy mm/dd/yyyy ``` works best - probably the right one, so that it's "YMD, DMY, MDY with non-slash separators, and then the same with slash separators".
@cousteaulecommandant pushed 1 commit.
77135099ad6c978c4c2d20c4b05ece515b4891e8 Add more date formats: mm/dd/yyyy and dd/mm/yyyy
github-comments@lists.geany.org