Bug 33237 - If TranslateNotices is off, use the interface language includes in slips
Summary: If TranslateNotices is off, use the interface language includes in slips
Status: Needs Signoff
Alias: None
Product: Koha
Classification: Unclassified
Component: I18N/L10N (show other bugs)
Version: unspecified
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Hammat wele
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-03-15 16:23 UTC by Caroline Cyr La Rose
Modified: 2024-04-16 07:08 UTC (History)
7 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments
Screenshot of ACCOUNT_CREDIT with untranslated parts in yellow (47.95 KB, image/png)
2023-03-16 17:56 UTC, Caroline Cyr La Rose
Details
Bug 33237: If TranslateNotices is off, use the interface language includes in slips (3.42 KB, patch)
2023-03-27 21:07 UTC, Hammat wele
Details | Diff | Splinter Review
Bug 33237: If TranslateNotices is off, use the interface language includes in slips (3.48 KB, patch)
2024-03-26 17:55 UTC, Nick Clemens
Details | Diff | Splinter Review
Bug 33237: (follow-up) Tidy (1.01 KB, patch)
2024-03-26 17:55 UTC, Nick Clemens
Details | Diff | Splinter Review
Bug 33237: (follow-up) Unit tests (3.35 KB, patch)
2024-04-08 16:44 UTC, Hammat wele
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Caroline Cyr La Rose 2023-03-15 16:23:13 UTC
Most of our clients use Koha in one language only (French) and their patrons are also all french-speakers. So they don't use TranslateNotices, since they don't need to print slips in different languages.

However, if TranslateNotices is off, the translations for "includes" (in my specific example, account types), are not taken into consideration and print in English. Same if TranslateNotices is on, but the patron's language is Default.

In those cases, shouldn't it use the interface language rather than just print in English?

To replicate:
1. Install the other language (i used fr-CA here)
     1.1. 

     gulp po:update fr-CA

     ./misc/translator/translate install fr-CA

     1.2. In Administration > Global system preferences, search for language and check the added language

2. Create a manual invoice in a patron's account and pay it

3. From the Transactions tab, click 'Print' next to the payment line

   --> On the printed slip, the title is "Payment receipt" (OK)

4. Switch interface to other language

5. Redo step 3

   --> On the printed slip, the title is still "Payment receipt" (not ok)

6. In Administration > Global system preferences, enable TranslateNotices

7. Go to Tools > Notices and slips > ACCOUNT_CREDIT and copy the content of the letter into all the languages

8. Redo step 3 (you should still be in the other language interface)

   --> On the printed slip, the title is still "Payment receipt" (not ok?)

9. Edit the patron's account and change the preferred language to the other language

10. Redo step 3

    --> On the printed slip, the title is "Paiement receipt" (OK)


On step 3, the account type is in English in the English interface (OK)

On step 5, the account type is in English in the other interface, with TranslateNotices off, I feel like the slip should take the interface into account in this case for the include...

On step 8, TranslateNotices is on, but the patron's language is Default, I feel like this should also take into account the interface language...

On step 10, TranslateNotices is on and patron language is set, these are currently the only settings which allow to have the accounttypes in the other language.
Comment 1 Caroline Cyr La Rose 2023-03-15 16:52:16 UTC
I consider this a bug (especially the one where TranslateNotices is off). If I'm the outlier, then I'd like to propose that we add a default language choice in the patron categories (like we do for messaging preferences) so that we don't have to change the preferred language for each and every new patron.

Since "default" is basically "English", unilingual non-english libraries absolutely need to change the patron's preferred language, they can't leave it at default.
Comment 3 Katrin Fischer 2023-03-16 14:34:19 UTC
Hm, I think the interface language is the best we could do in these cases and should work for our libraries as well. Our OPACs are usually at least English and German, but notices are often German only. The current behavior would therefore give us some trouble, but interface language should work ok.

Another alternative might be to use the "first" language in the language selection as default for these cases.

You can reorder them and the first in the list is, I think, also the fallback in other cases. So that might also work.
Comment 4 Caroline Cyr La Rose 2023-03-16 14:44:52 UTC
So if TranslateNotices is off, use interface language

if TranslateNotices is on, use first language as "default"

Would that be ok?
Comment 5 Caroline Cyr La Rose 2023-03-16 17:55:21 UTC
--> check patron's preferred language
--> if patron's preferred language is "default", check interface language
--> if no interface (for overdue_notices for example), check first language in "language" system preference

No need to check for TranslateNotices since borrowers.lang is always filled no matter what. If the pref is off, all the patrons' preferred languages will be "default".

Note that this bug is not for the notice templates. This already works well. It's only for the "includes" included in the templates. In my example, I used ACCOUNT_CREDIT template which uses accounts.inc to print the credit or debit account type. These are all translated in koha-tmpl/intranet-tmpl/prog/{lang}/includes/accounts.inc but only the english file is used in the slips, making all accounttypes (payment, lost item, manual fee, etc.) print in english no matter the language of the template. I added a screenshot of ACCOUNT_CREDIT with the parts that are currently not translated unless TranslateNotices is on and the patron has the correct preferred language in yellow.
Comment 6 Caroline Cyr La Rose 2023-03-16 17:56:12 UTC
Created attachment 148281 [details]
Screenshot of ACCOUNT_CREDIT with untranslated parts in yellow
Comment 7 Hammat wele 2023-03-27 21:07:02 UTC
Created attachment 148785 [details] [review]
Bug 33237: If TranslateNotices is off, use the interface language includes in slips

This patch set the language used in slips folloinw this logic:
   --> uses patron's preferred language
   --> if patron's preferred language is 'default', use the interface language
   --> if there is no interface (for overdue_notices for example), use the first language in 'language' system preference

To Test:
1. Install the other language (i used fr-CA here)
     1.1.

     gulp po:update fr-CA

     ./misc/translator/translate install fr-CA

     1.2. In Administration > Global system preferences, search for language and check the added language

2. Create a manual invoice in a patron's account and pay it

3. From the Transactions tab, click 'Print' next to the payment line
   --> On the printed slip, there's the word 'Payment' in English (OK)

4. Switch interface to other language

5. Redo step 3
   --> On the printed slip, the word 'Payment' is still in English (not ok)

6. In Administration > Global system preferences, enable TranslateNotices

7. Go to Tools > Notices and slips > ACCOUNT_CREDIT and copy the content of the letter into all the languages

8. Redo step 3 (you should still be in the other language interface)
   --> On the printed slip, the word 'Payment' is still in English (not ok)

9. Edit the patron's account and change the preferred language to the other language

10. Redo step 3
   --> On the printed slip, the word 'Payment' is in the other language (Paiement) (OK)

11. Apply the patch

12. Reset config
    12.1. Edit the patron's account and change back the preferred language to 'default'
    12.2. In Administration > Global system preferences, disable TranslateNotices

13. Redo step 3 (you should still be in the other language interface)
   --> On the printed slip, the word 'Payment' is in the other language (Paiement)

14. Switch interface to the english language

15. Redo step 3
   --> On the printed slip, the word 'Payment' is in English

16. In Administration > Global system preferences, enable TranslateNotices

17. Edit the patron's account and change the preferred language to the other language

18. Redo step 3
   --> On the printed slip, the word 'Payment' is in the other language (Paiement)
Comment 8 Martin Renvoize 2024-03-26 16:09:18 UTC
Sorry, can we get some unit tests here.
Comment 9 Nick Clemens 2024-03-26 17:55:17 UTC
Created attachment 163952 [details] [review]
Bug 33237: If TranslateNotices is off, use the interface language includes in slips

This patch set the language used in slips folloinw this logic:
   --> uses patron's preferred language
   --> if patron's preferred language is 'default', use the interface language
   --> if there is no interface (for overdue_notices for example), use the first language in 'language' system preference

To Test:
1. Install the other language (i used fr-CA here)
     1.1.

     gulp po:update fr-CA

     ./misc/translator/translate install fr-CA

     1.2. In Administration > Global system preferences, search for language and check the added language

2. Create a manual invoice in a patron's account and pay it

3. From the Transactions tab, click 'Print' next to the payment line
   --> On the printed slip, there's the word 'Payment' in English (OK)

4. Switch interface to other language

5. Redo step 3
   --> On the printed slip, the word 'Payment' is still in English (not ok)

6. In Administration > Global system preferences, enable TranslateNotices

7. Go to Tools > Notices and slips > ACCOUNT_CREDIT and copy the content of the letter into all the languages

8. Redo step 3 (you should still be in the other language interface)
   --> On the printed slip, the word 'Payment' is still in English (not ok)

9. Edit the patron's account and change the preferred language to the other language

10. Redo step 3
   --> On the printed slip, the word 'Payment' is in the other language (Paiement) (OK)

11. Apply the patch

12. Reset config
    12.1. Edit the patron's account and change back the preferred language to 'default'
    12.2. In Administration > Global system preferences, disable TranslateNotices

13. Redo step 3 (you should still be in the other language interface)
   --> On the printed slip, the word 'Payment' is in the other language (Paiement)

14. Switch interface to the english language

15. Redo step 3
   --> On the printed slip, the word 'Payment' is in English

16. In Administration > Global system preferences, enable TranslateNotices

17. Edit the patron's account and change the preferred language to the other language

18. Redo step 3
   --> On the printed slip, the word 'Payment' is in the other language (Paiement)

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Comment 10 Nick Clemens 2024-03-26 17:55:19 UTC
Created attachment 163953 [details] [review]
Bug 33237: (follow-up) Tidy

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Comment 11 Nick Clemens 2024-03-26 17:56:08 UTC
(In reply to Martin Renvoize from comment #8)
> Sorry, can we get some unit tests here.

Signed off as test plan works, but Martin is correct, unit tests would be useful
Comment 12 Hammat wele 2024-04-08 16:44:14 UTC
Created attachment 164521 [details] [review]
Bug 33237: (follow-up) Unit tests
Comment 13 Martin Renvoize 2024-04-16 06:59:20 UTC
Thanks for adding the unit test Hammut... but I'm afraid I can't seem to get it to pass on ktd.. I'll investigate a little but I have a feeling it's got something to do with installed languages in that environment.. we don't install any by default but this would require we do.. or at least we install the translated notice for those particular test cases.
Comment 14 Jonathan Druart 2024-04-16 07:07:31 UTC
Yes, I would move this logic in a dedicated subroutine. It will isolate it and make it easier to test ("sub effective_language_for_notices"?)
Comment 15 Jonathan Druart 2024-04-16 07:08:42 UTC
my $lang       = 'en'; 

This is also not needed and confusing as you are actually removing the fallback to "en".

I would re-add it, after the if/else block, add `$lang //= 'en';`