Bug 512748

Two issues here: a) incorrect french translation. and b) sum of splits not zero.

a) I add the french translation team to the bug report so they can fix it. Thank you for reporting.
b) You mention it yourself: no category assigned. Having an amount and no category is the problem. The transaction therefore is not balanced and in terms of double entry accounting that is an error. It's easy to fix: assign a category to it (e.g. miscellaneous or divers in French).

Searching and modifying a transaction based on its ID is also easy: copy the ID to the clipboard and use Edit/Find transaction (Ctrl+Shift+F) and paste the ID in the text search field (select 'contains' as criteria). Double-click on the transaction should show it in the ledger. That is where you can edit it.

I hope that works for you.

(In reply to Thomas Baumgart from comment #1)
> Two issues here: a) incorrect french translation. and b) sum of splits not
> zero.

    Yes. I was wondering if I had to make 2 BR or only one...


> a) I add the french translation team to the bug report so they can fix it.
> Thank you for reporting.

    That's the power of OpenSource Software. We are _all_ working together
    toward a better software world ;)


> b) You mention it yourself: no category assigned. Having an amount and no
> category is the problem.

     Well. I have 2 answers to that :)

     1. It wasn't a problem before (the operation was displayed in red with a
         "warning" icon and that was sufficient enough for me.

     1. The error message about splits was plain wrong if the problem lies in
         a missing category field.

> The transaction therefore is not balanced and in
> terms of double entry accounting that is an error. It's easy to fix: assign
> a category to it (e.g. miscellaneous or divers in French).

    Well. The search window being now separated from the ledger window,
    that makes it more complex to search & edit such operations. But being
    mislead by the error message wasn't a great help ;) Moreover, it was a
    voluntary error. At the time (2008) I did not have access to what kind of
    expense it was (my wife buys stuff and forgets -_-).

    Up to now, it wasn't an error per se to lack a category. The _other_ problem
    is that the warning is _permanent_. An acknowledge button to make kmymoney
    silent for these same errors in the future, would have been less annoying ;)


> Searching and modifying a transaction based on its ID is also easy:

    I don't agree with you on that point :) I made another BR about the
    search window ^^

> copy the
> ID to the clipboard

    Ok, I didn't know we could make a search on the ID as it's not displayed
    in the GUI.

> and use Edit/Find transaction (Ctrl+Shift+F) and paste

    I'm worried about the Ctrl+Shift+F issue. Almost every other application
    use Ctrl+F or "/" to lookup for stuff. I did use Ctrl+F. It displayed a strange
    input line that I took as the search term entry but wasn't.
    That's after looking in the menus that I found out about Ctrl+Shift+F. I still
    don't know what Ctrl+F is supposed to do (because I didn't take the time
    to have a look at the keyboard shortcuts), but that IS a deviation from
    common uses of Ctrl+F :)


> the ID in the text search field (select 'contains' as criteria).
> Double-click on the transaction should show it in the ledger. That is where
> you can edit it.

     Oh. You can double-click on it ?
     Trying...
     No. That closes the search window.
     Ah ! You have to also display the "R" marked operations...


> I hope that works for you.

     Well... It's fastidious for something that wasn't an error before (or not
     as annoying as having a window pop-up every time the file is saved) :)

Hello and thanks for your report.
As KDE FR translator in charge of kmymoney, the issue for me is a bit unclear:
  (with a wrong french translation for "reported on" -> "signalée sur")

What is for you the expected FR translation in this context?
Thanks for your feedback for fixing the translation issue ASAP.
Regards. Xavier

(In reply to Xavier Besnard from comment #3)
> Hello and thanks for your report.
> As KDE FR translator in charge of kmymoney, the issue for me is a bit
> unclear:
>   (with a wrong french translation for "reported on" -> "signalée sur")
> 
> What is for you the expected FR translation in this context?

     As a date is following the mistranslated term, it should be "signalée le".

     Example of current output :
* La somme des fractionnements de l'opération « T000000000000002510 » signalée sur 16/04/2010 n'est pas égale à zéro. 

    When kmymoney is displayed in english:
  * Sum of splits in transaction 'T000000000000002510' posted on 16 Apr 2010 is not zero.

     So the translation may at least be (note the "sur" word transformed in "le") :
* La somme des fractionnements de l'opération « T000000000000002510 » signalée le 16/04/2010 n'est pas égale à zéro. 

    And even though... I don't understand what means "posted" / "signalée" in this context. There are 2 columns for dates
    in the ledger display :
    - "Entry" : the date when the operation has been input into the ledger
    - "Date" : the day the operation happened.


> Thanks for your feedback for fixing the translation issue ASAP.

    My pleasure :)

    As I said before : that's the power of OpenSource Software. We are _all_
    working together toward a better software world ;)

Hello and thanks. I am an old FOSS user and I am every time by the enthusiasm of contributors/users.
So, I would propose to fix the open issues you reported concerning translation.

  * Sum of splits in transaction 'T000000000000002510' posted on 16 Apr 2010 is not zero.
     So the translation may at least be (note the "sur" word transformed in "le") :
==> My proposition is:
* La somme des fractionnements de l'opération « T000000000000002510 » effectuée en date du %2 est différente de zéro. 

There are 2 columns for dates
    in the ledger display :
    - "Entry" : the date when the operation has been input into the ledger
    - "Date" : the day the operation happened.
==> My proposition is:
      - "Entry"  ==> Date de l'opération (Many occurences)
      - "Date"  ==> Date d'exécution (Many occurences)

The translation file had been updated accordingly and commited. 
PS: You can get it and experience the translation update at https://websvn.kde.org/trunk/l10n-support/fr/summit/messages/kmymoney/kmymoney.po?view=log
Let me know if it is more consistent. 
Regards. Xavier

Created attachment 187262 [details]
Date columns description text after translation.

(In reply to Xavier Besnard from comment #5)
> Hello and thanks. I am an old FOSS user and I am every time by the
> enthusiasm of contributors/users.

    I'm also quite an old FOSS user now ;)


> ==> My proposition is:
> * La somme des fractionnements de l'opération « T000000000000002510 »
> effectuée en date du %2 est différente de zéro. 

    Perfect :)


> There are 2 columns for dates
>     in the ledger display :
>     - "Entry" : the date when the operation has been input into the ledger
>     - "Date" : the day the operation happened.
> ==> My proposition is:
>       - "Entry"  ==> Date de l'opération (Many occurences)
>       - "Date"  ==> Date d'exécution (Many occurences)

     Those two were in the ledger and were already (correctly in my opinion)
     translated as "Entrée" and "Date". My point was that "reported" on did not
     match one of the two known dates types :)
     Maybe you found some that weren't ?

     I fear that the translation may be too wide to fit into the columns of the ledger
     rendering them unreadable. As you can see in the attachment I put, there's not
     much space for putting text in there without taking screen space from other
     columns :)


> The translation file had been updated accordingly and commited. 
> PS: You can get it and experience the translation update at
> https://websvn.kde.org/trunk/l10n-support/fr/summit/messages/kmymoney/
> kmymoney.po?view=log
> Let me know if it is more consistent. 

    I'm looking for a way to install it since I do not find any .po files in the debian kmymoney packages
    to overwrite them :)

> Regards. Xavier

    Regards, Thomas.

> I still don't know what Ctrl+F is supposed to do (because I didn't
> take the time to have a look at the keyboard shortcuts), but that
> IS a deviation from common uses of Ctrl+F :)

It shows the widget to search/filter for specific transactions. For that matter, I don't think it is much of a deviation from the common use to find stuff. In older versions of KMyMoney this was already present but always visible.

I agree that the UI experience could be better. Also, in previous version the filter looked at the transaction id (which needs to be added).

Regarding the suppression of the warning (it's not shown as error) about the inconsistency I will add another wishlist entry to prevent a popup for a specific period of time for those unbalanced transactions. Everything else should still be reported.

Regards, Thomas -- also an 'old' FOSS user and contributor.

Git commit e5b6e891a115a46326a5dadb8828dc505669f5fb by Thomas Baumgart.
Committed on 30/11/2025 at 10:17.
Pushed by tbaumgart into branch 'master'.

Also search for transaction ID and date in journal filter

M  +7    -0    kmymoney/models/ledgerfilter.cpp

https://invent.kde.org/office/kmymoney/-/commit/e5b6e891a115a46326a5dadb8828dc505669f5fb

Git commit abb34e8496a28e0452d9eb645113fd68f85fc6f0 by Thomas Baumgart.
Committed on 30/11/2025 at 10:18.
Pushed by tbaumgart into branch 'master'.

Improve journal filter widget description

M  +2    -0    kmymoney/views/ledgerviewpage.cpp

https://invent.kde.org/office/kmymoney/-/commit/abb34e8496a28e0452d9eb645113fd68f85fc6f0

Git commit 143b31187a5f5edc979e94a88c68dd81c86822e0 by Thomas Baumgart.
Committed on 30/11/2025 at 13:30.
Pushed by tbaumgart into branch '5.2'.

Also search for transaction ID and date in journal filter
(cherry picked from commit e5b6e891a115a46326a5dadb8828dc505669f5fb)

M  +7    -0    kmymoney/models/ledgerfilter.cpp

https://invent.kde.org/office/kmymoney/-/commit/143b31187a5f5edc979e94a88c68dd81c86822e0

Hello,
Regarding your point:
>     I'm looking for a way to install it since I do not find any .po files in the debian kmymoney packages to overwrite them :)

If you have installed KMyMoney using your distribution's packages, then you could overwrite your local translation file. The .po file you have from Xavier Besnard must be transformed into .mo file. I suggest to look at this: : https://community.kde.org/KDE_Localization/fr/applications#Tester_localement_le_fichier_traduit to see how to transform it.

If you have installed KMyMoney using AppImage, then the .po file cannot help you since the AppImage is a kind of black box for the end user. BUT there is a solution: download a more recent AppImage file. They are available here: https://kmymoney.org/appimage.html.
Then you may already have the "corrected" (regarding the translation issue of this bug), or not. It depends on when the needed steps happened:
1- Xavier Besnard committed the corrected language file two days ago, 
2- According to Gitlab (see On https://invent.kde.org/office/kmymoney/-/commits/5.2?ref_type=heads the commits named "GIT_SILENT Sync po/docbooks with svn"), the language files have been integrated this morning into the software
3- For example the last stable (=branch 5.2) AppImage file available is 	kmymoney-5.2-5001-linux-gcc-x86_64.AppImage	2025-11-30 14:22 	150M	 , which is from yesterday afternoon. So i presume it has not the most recent language file correction yet. 

If you watch the webpage https://cdn.kde.org/ci-builds/office/kmymoney/5.2/linux/ the next days, you may find a newer version than today and it should contain the corrected language file.

(In reply to surcouf from comment #12)
> Hello,
> Regarding your point:
> >     I'm looking for a way to install it since I do not find any .po files in the debian kmymoney packages to overwrite them :)
> 
> If you have installed KMyMoney using your distribution's packages, then you
> could overwrite your local translation file. The .po file you have from
> Xavier Besnard must be transformed into .mo file.

    Argl... I was looking for po files in the package but it was mo... Of course. Silly me.


> If you watch the webpage
> https://cdn.kde.org/ci-builds/office/kmymoney/5.2/linux/ the next days, you
> may find a newer version than today and it should contain the corrected
> language file.

    Thanks :)
    I'll wait for the package to appear in Debian Testing ;)

    My main goal is to improve debian by testing new versions of softwares that
    appear in it. The fact is, I'm a very long time kmymoney user (2006). So I have
    a bit of history with that software, thus my reports here ^^


Thomas

>Thanks :)
>  I'll wait for the package to appear in Debian Testing ;)

What is the logic behind the apparition of a package update in Debian testing? Does it come because a user triggers it? Or does it come after a given piece of time? Or another logic?

>    My main goal is to improve debian by testing new versions of softwares that appear in it. 
Great, thanks for your involvment!
> The fact is, I'm a very long time kmymoney user (2006). So I have
>    a bit of history with that software, thus my reports here ^^
Impressive. My history is almost 2-years old...
Anyway, if you want to spread the good word regarding KMyMoney in a debian context, you could help in:
- reviewing this wiki article https://debian-facile.org/atelier:chantier:kmymoney-le-gestionnaire-de-finances-personnelles
- after the review, writing a short post here https://debian-facile.org/viewtopic.php?id=36361
this is from the distribution I use and contribute improving the internet footprint of KMyMoney.

(In reply to surcouf from comment #14)
> >Thanks :)
> >  I'll wait for the package to appear in Debian Testing ;)
> 
> What is the logic behind the apparition of a package update in Debian
> testing? Does it come because a user triggers it? Or does it come after a
> given piece of time? Or another logic?

    Upstream makes a new version --> the debian developer in charge of the package
    creates the new package (at his/her own time appreciation) --> the package is
    pushed to "sid" (Unstable, "Still In Development") --> automatic analysis tools are
    used to check for package consistency --> after a week without reports (some users
    test packages in Unstable : those are the really dedicated ones) the package is moved
    to Testing where more timid users (like me) can test a system that is (almost) up to date
    with the state of the art.

    Every 2 years (something like that) Testing freezes progressively and when all problems
    are resolved Testing is moved to Stable. Then, about a week after, Testing thaws and a
    stream of ready Unstable packages flows into it. That was the case last summer.


> >    My main goal is to improve debian by testing new versions of softwares that appear in it. 
> Great, thanks for your involvment!

    I'm certainly not the only one and there are more hardcore testers than me ;)

> > The fact is, I'm a very long time kmymoney user (2006). So I have
> >    a bit of history with that software, thus my reports here ^^
> Impressive. My history is almost 2-years old...

    Not that impressive. I think first time developers of KMM have used it for a longer
    time ;)

Thomas.

*** Bug 512750 has been marked as a duplicate of this bug. ***

(In reply to tnemeth from comment #15)
> (In reply to surcouf from comment #14)
> > >Thanks :)
> > >  I'll wait for the package to appear in Debian Testing ;)
> > 
> > What is the logic behind the apparition of a package update in Debian testing? Does it come because a user triggers it? Or does it come after a
> > given piece of time? Or another logic?
> 
>     Upstream makes a new version --> the debian developer in charge of the package
>     creates the new package (at his/her own time appreciation) --> the package is
>     pushed to "sid" (Unstable, "Still In Development") --> automatic analysis tools are
>     used to check for package consistency --> after a week without reports (some users
>     test packages in Unstable : those are the really dedicated ones) the package is moved
>     to Testing where more timid users (like me) can test a system that is (almost) up to date
>     with the state of the art.
> 
>     Every 2 years (something like that) Testing freezes progressively and when all problems
>     are resolved Testing is moved to Stable. Then, about a week after, Testing thaws and a
>     stream of ready Unstable packages flows into it. That was the case last summer.
> 
> Thomas.
Thanks for the explanations.

Regarding this specific bug, I presume it can be closed, since Thomas Baugart committed his fix into master and 5.2 branches, cannot it?

(In reply to surcouf from comment #17)
> Regarding this specific bug, I presume it can be closed, since Thomas
> Baugart committed his fix into master and 5.2 branches, cannot it?

    Yes of course :)