Created attachment 373693 [details] umlauts as part of report standard texts German locale: Umlauts in standard texts of reports and associated report dialogue wizards (for option setting) are not properly html-escaped, hence not nicely displayed. However, umlauts as part of account names are nicley displayed. Example report: Reports > Experimental > Balance sheet (multicolumn) See examples in attachments.
Created attachment 373694 [details] text in report option dialogue wizard (German locale)
It is not the task of the translators, to quote non-ASCII characters. The po files are utf-8 encoded. IMHO it is the task of the report coders, to use utf-8 save string functions.
The problem might be that we're not configuring the GtkWebkitWebView to use the right character set.
Jralls see the report options screenshot. The dates from/to are also in invalid charset. This would indicate the problem isn't related to webview (or even guile).
Created attachment 373695 [details] Screenshot showing correct rendering of German text on report and options. Chris, Indeed. As the attached screenshot shows it works fine on MacOS. Since the strings in question are internal, how might they have gotten transcoded out of UTF-8? Jannick, what OS/Distro & version are you really using? What are your locale settings?
The window decorations are also quite old suggesting a version in the early 3.x series. Later 3.x use gtk decorations.
> The window decorations are also quite old suggesting a version in the early 3.x series. Later 3.x use gtk decorations. Nah, that's controlled by the window manager and theme.
Changing this ticket's OS to 'Windows', as the issue now appears to be Windows specific. (In reply to John Ralls from comment #5) > Jannick, what OS/Distro & version are you really using? What are your locale > settings? I am on Windows10 using GC 3.902+(2020-04-27). My locale is German (de), i.e. 'systeminfo' provides: Systemgebietsschema: de;Deutsch (Deutschland) Eingabegebietsschema: de;Deutsch (Deutschland) (In reply to Christopher Lam from comment #4) > Jralls see the report options screenshot. The dates from/to are also in > invalid charset. This would indicate the problem isn't related to webview > (or even guile). Not sure if this is true: For the German locale the date format is and should be 'dd.mm.yyyy'. ... or am I missing something here?
(In reply to Jannick from comment #8) > > (In reply to Christopher Lam from comment #4) > > Jralls see the report options screenshot. The dates from/to are also in > > invalid charset. This would indicate the problem isn't related to webview > > (or even guile). > Not sure if this is true: For the German locale the date format is and > should be 'dd.mm.yyyy'. ... or am I missing something here? Chris is pointing out that Buchährungsperiode is incorrectly encoded, showing that the problem isn't limited to the html display of reports.
(In reply to Christopher Lam from comment #4) > Jralls see the report options screenshot. The dates from/to are also in > invalid charset. This would indicate the problem isn't related to webview > (or even guile). Maybe. Guile does have a problem with converting strings to utf-8 on Win32, see bug 795037, and the strings originate in date-utils.scm, but those are the English strings. If gettext is called from C to get the values for the options dialog and the report then Guile is clean, but if the gettext calls are from Scheme code then it's down to Guile's defective trasncoding.
I wonder if the issue is that make-string-database in c-interface.scm is run *before* the monkey-patch in utilities.scm. To test: Copy the whole block from utilities.scm to c-interface.scm. Can be located e.g. at the end in c-interface.scm, --- ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; compatibility hack for fixing guile-2.0 string handling. this code ;; may be removed when minimum guile is 2.2 or later. see ;; https://lists.gnu.org/archive/html/guile-user/2019-04/msg00012.html ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; (when (string=? (effective-version) "2.0") ;; When using Guile 2.0.x, use monkey patching to change the ;; behavior of string ports to use UTF-8 as the internal encoding. ;; Note that this is the default behavior in Guile 2.2 or later. (let* ((mod (resolve-module '(guile))) (orig-open-input-string (module-ref mod 'open-input-string)) (orig-open-output-string (module-ref mod 'open-output-string)) ---etc---
Assuming Jannick is using the distributed Windows installer, this is Guile 2.2.
The problem was that Geert had converted to using guile's gettext module instead of our rather klugy wrapper function as part of moving core-utils guile bindings to bindings/guile. I've put it back, but this time with a three-line change to core-utils.i that tells swig to wrap gettext() and rename it to gnc:gettext. Unfortunately I didn't get this in time for 3.904, but it will be in 3.905 next weekend and in tomorrow's nightlies.
gnucash-3.904-2020-06-08-git-3.904-1-gb5aeca94b+.setup.exe: I checked and can confirm that the issue is resolved. Many thanks!
(In reply to John Ralls from comment #13) > The problem was that Geert had converted to using guile's gettext module > instead of our rather klugy wrapper function as part of moving core-utils > guile bindings to bindings/guile. I've put it back, but this time with a > three-line change to core-utils.i that tells swig to wrap gettext() and > rename it to gnc:gettext. Interesting, I knew guile was having conversion issues, I just didn't realize they also applied to gettext translations. Sorry for the regression !
