Created attachment 373291 [details] Receipt-01.png Respect the locale date-data in the field for "Today date format". Go to: Reports > Company > Receipt > Display ... Currently this is hard coded as "%A, %b %e, %Y at %l:%M %P" in the file: gnucash/gnucash/report/business-reports/receipt.scm This is an "english" version (because of the "at" in the code). Also, I'm sure that most users (non-programers) aren't familiar with the shorthand time-codes. It would be better to use the existing string from the po file "%A %d %B %Y", as this is "translated" in the different po files. If the "time" factor isn't really relevant, it could be droped out. IMO, using the existing po file string would be the quickest solution.
This changes display from "Monday, Jun 3, 2019 at 12:27 pm" to "Monday 03 June 2019" All agree?
I agree, as it's probably the quickest solution. In a long run, maybe it would be necessary to change the existing string "%A %d %B %Y" in the .pot file itself. Then, even "%A, %b %e, %Y at %l:%M %P" could be used. But I'm no programmer, and I don't know what the current string is used for.
We're not limited in the number of translatable date format strings. We can simply mark the current "%A, %b %e, %Y at %l:%M %P" for translation and it will show up in gnucash.pot.
I'm sorry, I don't quite understand what John is saying. But ... Watch out for uppercase %A and english text in the strings. The current string in the .pot-file (3.5) with timestamp is: #: gnucash/gnome-utils/gnc-main-window.c:1679 msgid "Last modified on %a, %b %d, %Y at %I:%M %p" msgstr "" ... this one cosists of date/time *and* text. The other string in the .pot-file (3.5) without timestamp is: #: gnucash/gnome-utils/gnc-tree-util-split-reg.c:436 #: gnucash/register/ledger-core/gncEntryLedgerModel.c:576 #: gnucash/register/ledger-core/split-register-model.c:1000 msgid "%A %d %B %Y" msgstr "" ... this one cosists only of date/time. The string used in the application for the receipt is hard coded in the .scm file itself as: "%A, %b %e, %Y at %l:%M %P" ... this one without the "Last modified"-text and with an uppercase %A. Please excuse if I'm confusing you - I'm no programmer.
You're not confusing me, rather the reverse it seems. Whatever format string we use in receipt.scm has to be wrapped in (_ ) to be translated at runtime. If it's one of the already-known strings (I found 4) then the existing translation for that string will be used without further work. If it's not then the next run of xgettext will add it to the potfile. That will require all of the translators to create a new date string that's idiomatic for their languages. Your point about most non-programmers being completely unaware of the codes is a good one, the edit should have a tool tip and a translator comment explaining them.
Yes, tooltip would be good! I only don't know where the spec ends. As I found out, there is also something like "%OB" as well, and I don't know about the interoperatebility(?) between GnuCash different OS's (as said before, I'm no programmer). My problem in croatian is, that genitive form *must* be used when specifying the month. Periods *must* be used after date and year – they are ordinal numbers. In the .po file I can handle "periods" after numbers, but not the "genitive" form. Example for croatian date (Day, date. month[genitive] year. Utorak, 4. lipnja 2019. = Tuesday, 4th of july 2019th When specifying the month per se (e.g. in a calendar), nominative form must be used. When specifying the date per se (e.g. in a calendar), an ordinal number must/should be used (just as my croatian MacOS does). p.s. I've translated Gramps into croatian. It uses "genitive" forms in the .po/.pot files. I don't know if this is necessary for GnuCash, because obviously other methods can be used = all roads lead to Rome.
That's rather a different issue and in GnuCash's case it depends on the date formatting library in use. There's no custom datehandler like there is in Gramps. The full set of format flags is at https://www.boost.org/doc/libs/1_70_0/doc/html/date_time/date_time_io.html#date_time.format_flags. You can plug different formats into the entry in the Receipt options dialog and see if you can get a satisfactory string. If you can't it would be a new bug, and unfortunately not one that we can fix anytime soon.
I know all that, but thank you. No, there isn't a bug. Let's go back to my initial suggestion and Christopher's comment. Can that be implemented as the quickest solution?
I would prefer the receipt to use a date with time component. That report is intended to be used in a point of sale context and I find it useful to have a purchase time on such a receipt. So my preference is to simply make the untranslated date string translatable. That way each language can adapt it to their specific needs. It may not be the "quickest" solution. It is the most flexible one.
I understand your issue with the time component and I aggree. As far as I can tell, that would result in the following: either 1) introduce a *new string* to the .pot file, something like: msgid "%a, %b %d, %Y at %I:%M %p" or 2) *add a time component* to this current string: #: gnucash/gnome-utils/gnc-tree-util-split-reg.c:436 #: gnucash/register/ledger-core/gncEntryLedgerModel.c:576 #: gnucash/register/ledger-core/split-register-model.c:1000 msgid "%A %d %B %Y" Someone would need to check if solution 2) is possible, as I don't know how it would influence the application. John's suggestion about the tooltip would also be nice. Or at least a web-link to the appropriate website. But for that we should probably open a new issue.
Solution 2 is not an option as time is not relevant in the gnucash accounting context so we don't want to add a time component to all date representations. It is useful on a receipt, though not for accounting reasons per se. For clarity, the different date formats brought up so far render as follows in my locale (nl_BE): $ date +"%A, %b %e, %Y at %l:%M %P" dinsdag, jun 4, 2019 at 1:49 $ date +"%A %d %B %Y" dinsdag 04 juni 2019 $ date +"%a, %b %d, %Y at %I:%M %p" di, jun 04, 2019 at 01:50 I'll concede date formats are (aside from a locale thing) also very much a personal taste. The author of the original string clearly didn't like padding zeros on the day (%e vs %d) or hour (%l vs %I) components, where you seem to prefer those. I'm inclined to respect this. Each language can change to their taste. On the other hand considering the receipt report was created to be printed on a label printer with narrow page width, I think using shorthands for day ('di' instead of 'dinsdag') and months ('jun' instead of 'june') is a good thing. So I would propose this format string: $ date +"%a, %b %e, %Y at %l:%M %p" di, jun 4, 2019 at 2:02 I'll add a translator comment if I can and will look into a tool tip as well. Is that ok with you ?
(In reply to Geert Janssens from comment #11) > Solution 2 is not an option ... Understood. > $ date +"%a, %b %e, %Y at %l:%M %p" > di, jun 4, 2019 at 2:02 > > I'll add a translator comment if I can and will look into a tool tip as well. > Is that ok with you ? But is this going to be hardcoded in the "receipt.scm" file again? That's what I'm trying to avoid the whole time. So users don't have to manually change the english word "at" between date and time. Tooltip - great!
(In reply to milotype from comment #12) > But is this going to be hardcoded in the "receipt.scm" file again? That's > what I'm trying to avoid the whole time. So users don't have to manually > change the english word "at" between date and time. > I believe I answered that: (From comment #9) > So my preference is to simply make the untranslated date string > translatable. That way each language can adapt it to their specific needs.
> But is this going to be hardcoded in the "receipt.scm" file again? That's what I'm trying to avoid the whole time. So users don't have to manually change the english word "at" between date and time. @milotype it's fine to hardcode the "%A, %b %e, %Y at %l:%M %P" in receipt.scm; enclosing it in (_ "") will make it translated for different locales. To the user, the format-string will either be the untranslated English one, or one supplied by a translator. So the change is: modified gnucash/report/business-reports/receipt.scm @@ -155,7 +155,12 @@ displaypage optname-logo-width-footer "h" (N_ "Width of the footer logo in CSS format, e.g. 10% or 32px. Leave blank to display the logo at its natural width. The height of the logo will be scaled accordingly.") "72mm")) (add-option (gnc:make-string-option - displaypage optname-date-format "i" (N_ "The format for the date->string conversion for today's date.") "%A, %b %e, %Y at %l:%M %P")) + displaypage optname-date-format "i" + (N_ "The format for the date->string conversion for today's date. \ +This uses ISO C strftime format specifiers.") + ;; Translators: this is an ISO C format strftime to retrieve + ;; today's date and time for point-of-sale receipts. + (_ "%A, %b %e, %Y at %l:%M %P"))) ;; Heading options (add-option (gnc:make-string-option
Thank you Christopher. I did already understand, that enlosing (_ "") instead of (N_ "") makes something translatable (as Geert did such a correction in Bug 797104). But I thought that the text within the quotes must be *identical* to an existing string in the .pot file. Please excuse everybody, that you have to put up with a non-programmer like me from time to time.
Hmm near but not quite. The change is from "something" to (_ "something") to mark as translatable and use the translated text. Enclosing in N_ also marks as translatable but does not actually perform the translation. See, from the coder viewpoint: https://wiki.gnucash.org/wiki/I18N#When_to_use_N_.28.29_and_when_to_use_.28.29 I'll let a non-Anglo user make the change :)
milotype, It seems that "mark for translation" is confusing you. There's a program called xgettext that we run as part of making the tarballs (and can be run anytime manually with 'make pot' or 'ninja pot'). It scans every source file looking for strings that are "marked for translation" and includes them in gnucash.pot. That obviously produces a lag between making a string translatable in code and the user seeing the translated version of the string when using GnuCash. The lag can be avoided by reusing a string that's already in gnucash.pot, but only if there's a string that makes sense to use. Chris, unless the format is being submitted to Scheme strftime (and I thought that you'd just removed all of those) the format codes are from Boost::date_time and are a little different from the Standard C ones. But taking a different tack, if the objection is only about "at", we could rewrite the string to remove it, perhaps %l:%M %P %A %b %e, %Y (maybe still too American) or %l:%M %P %e %B %Y.
(In reply to John Ralls from comment #17) > … and includes them in gnucash.pot. Ahhh, now I get it … Thank you and Chris for explaning it. I'll leave it up to the programmers now, to decide what to do. As long as it's translatable, everything is fine with me!
I'll fix it to "%l:%M %P, %e %B %Y" which produces " 9:56 pm, 19 June 2019" and will be translatable, and will have translator clue.
