Yuvomi

Fixed

• An instalment on a loan the household had taken on could not be corrected (#859). Tick off an instalment on a borrowed loan, then open that booking in the budget and change the amount: saving failed with “Loan repayment entries must remain income.” Nothing the dialog could send was accepted, because the dialog was right and the check was wrong. There was no way around it either

  • deleting the instalment and booking it again was the only remedy.

  The rule dates from a time when every loan was money lent out, where a repayment coming back really is income. Loan direction arrived in v1.77.0 (#638): an instalment on a loan you took on leaves the household and is booked as an expense, so it is negative by design. The loans routes learned that; the entry route kept the old rule and rejected exactly the sign it had itself written.

  The sign of a repayment booking now belongs to the loan rather than to the request, and it is derived from the same rule everywhere - booking an instalment, re-booking after a change of direction, and editing the booking afterwards. That rule lived inside the loans routes, which is why the entry route could contradict it; it is now shared between them.

  Two things the old check had been hiding come with it. The cap against paying off more than the loan still owes compared a signed amount against a positive remainder, so on a borrowed loan it was always satisfied and never stopped anything. And an amount of zero, previously caught by the income rule as a side effect, is now refused on its own terms rather than reaching a database constraint.

  In the budget dialog, the income/expense switch is now inert on a loan instalment and says so. Which of the two it is follows from the loan, is changed there, and any other answer was going to be silently overruled on save.

  Two further faults surfaced once this path could be walked at all, and both are fixed here. Opening an instalment for editing from the loan list filled the dialog from the instalment rather than from the budget entry it belongs to. On a foreign-currency loan that meant the loan-currency figure went in where the budget-currency one belongs, so saving converted it a second time - 100 USD at 0.50 became a 200 USD instalment. And because that stand-in carries no account, the dialog offered “no account” and saving unlinked the instalment from the account it was charged to, moving that account’s balance. Both happened even if all you touched was the title.

  Editing now loads the actual entry instead of assembling a second, partial copy of it. The assembled one still describes the row in the list, where the loan currency is the right figure to show - it was never an editing record, and now nothing treats it as one.

• A booked loan instalment was titled in English, whatever the household language (found while verifying #859). Ticking off an instalment writes a budget entry called Loan repayment: <name>, and that string was fixed in the source. In 23 of the 24 languages it has read as English ever since - in the entry list, in the CSV export, in search results and over the API.

  There is a translated title, and it has been there for a while, but it only ever applied when the stored title was empty. Regular instalments always have one, so it never got a turn. Where it did work was instalments backdated on an existing loan, which carry no budget entry at all - so the same list could show a translated title next to an English one, for two instalments of the same loan.

  The title is now written in the household’s data language, the same way birthday events have been since v1.x (#524, #631, #632), and for the same reason: that row is what the REST API, the CSV export, the search index and MCP read, and none of those paths pass through the translation that happens in the browser. The translated fallback stays where it earns its keep - on backdated instalments.

  Existing entries keep their titles. The title of a budget entry is yours to edit, and rewriting one on a language change would overwrite a decision somebody may well have made on purpose.