Bug 38136 - Refactor database translations (alternative)
Summary: Refactor database translations (alternative)
Status: Signed Off
Alias: None
Product: Koha
Classification: Unclassified
Component: I18N/L10N (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement
Assignee: Julian Maurice
QA Contact: Testopia
URL:
Keywords: RM_priority
Depends on:
Blocks: 38460 39118
  Show dependency treegraph
 
Reported: 2024-10-10 12:03 UTC by Julian Maurice
Modified: 2025-04-28 18:07 UTC (History)
5 users (show)

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


Attachments
Bug 38136: Refactor database translations (alternative) (56.48 KB, patch)
2024-10-10 12:05 UTC, Julian Maurice
Details | Diff | Splinter Review
Bug 38136: Fix call to search_with_localization with branchcode param (1.43 KB, patch)
2024-10-16 08:27 UTC, Julian Maurice
Details | Diff | Splinter Review
Bug 38136: [TO SQUASH] Remove unecessary 'use Koha::Caches' from Koha::ItemType (820 bytes, patch)
2024-10-23 09:21 UTC, Jonathan Druart
Details | Diff | Splinter Review
Bug 38136: Show item type when adding translations (964 bytes, patch)
2024-10-23 09:21 UTC, Jonathan Druart
Details | Diff | Splinter Review
Bug 38136: Fix 'Delete' link (2.34 KB, patch)
2024-10-23 09:52 UTC, Jonathan Druart
Details | Diff | Splinter Review
Bug 38136: Return '404 Not Found' when trying to delete a non-existent translation (1.37 KB, patch)
2024-10-23 10:04 UTC, Jonathan Druart
Details | Diff | Splinter Review
Bug 38136: Move DBIC component to Koha::Schema namespace (1.85 KB, patch)
2024-11-15 13:26 UTC, Julian Maurice
Details | Diff | Splinter Review
Bug 38136: Fix C4::Biblio::GetAuthorisedValueDesc for itemtypes (5.32 KB, patch)
2024-11-15 13:26 UTC, Julian Maurice
Details | Diff | Splinter Review
Bug 38136: Fix cache not being cleared when updating a translation (1.11 KB, patch)
2024-11-15 13:26 UTC, Julian Maurice
Details | Diff | Splinter Review
Bug 38136: Fix behavior of lang selector in translations editor (1.12 KB, patch)
2024-11-15 13:26 UTC, Julian Maurice
Details | Diff | Splinter Review
Bug 38136: Fix localization cache (1.02 KB, patch)
2024-11-15 15:29 UTC, Julian Maurice
Details | Diff | Splinter Review
Bug 38136: Die early if the localization relationship does not exist (1.06 KB, patch)
2024-11-15 15:30 UTC, Julian Maurice
Details | Diff | Splinter Review
Bug 38136: Use a single table for all translations (12.83 KB, patch)
2024-12-03 13:59 UTC, Julian Maurice
Details | Diff | Splinter Review
Bug 38136: Refactor database translations (alternative) (63.17 KB, patch)
2024-12-03 14:18 UTC, Julian Maurice
Details | Diff | Splinter Review
Bug 38136: Refactor database translations (alternative) (58.49 KB, patch)
2024-12-03 16:05 UTC, Julian Maurice
Details | Diff | Splinter Review
Bug 38136: Refactor database translations (alternative) (58.94 KB, patch)
2024-12-03 16:19 UTC, Julian Maurice
Details | Diff | Splinter Review
Bug 38136: Refactor database translations (alternative) (61.04 KB, patch)
2025-03-31 11:16 UTC, Julian Maurice
Details | Diff | Splinter Review
Bug 38136: Refactor database translations (alternative) (61.04 KB, patch)
2025-04-01 08:39 UTC, Julian Maurice
Details | Diff | Splinter Review
Bug 38136: Refactor database translations (alternative) (61.08 KB, patch)
2025-04-01 12:06 UTC, Caroline Cyr La Rose
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Julian Maurice 2024-10-10 12:03:41 UTC
This has the same goals of bug 24975 but with a different approach
Comment 1 Katrin Fischer 2024-10-10 12:05:03 UTC
Awesome to see some new activity on this topic. Go Julian go!
Comment 2 Julian Maurice 2024-10-10 12:05:41 UTC Comment hidden (obsolete)
Comment 3 Julian Maurice 2024-10-10 12:10:18 UTC
Changing status to Needs Signoff, but really this patch needs QA eyes more than anything.

Before testing, backup your localization table as the atomicupdate deletes it. Alternatively, comment the DROP TABLE query before running updatedatabase.pl
Comment 4 Marcel de Rooy 2024-10-10 12:18:53 UTC
(In reply to Julian Maurice from comment #3)
> Changing status to Needs Signoff, but really this patch needs QA eyes more
> than anything.
> 
> Before testing, backup your localization table as the atomicupdate deletes
> it. Alternatively, comment the DROP TABLE query before running
> updatedatabase.pl

Definitely interested in getting this further. Great! Hope to have a look soon.
Comment 5 Julian Maurice 2024-10-10 12:22:55 UTC
This is not clear from the patch description, but this is capable of managing translations for several properties of the same object. In other words, we could easily make itemtype's "checking message" and "summary" translatable.
Comment 6 Katrin Fischer 2024-10-10 12:23:35 UTC
(In reply to Julian Maurice from comment #5)
> This is not clear from the patch description, but this is capable of
> managing translations for several properties of the same object. In other
> words, we could easily make itemtype's "checking message" and "summary"
> translatable.

Thanks for pointing out, I had been wondering about the normal and OPAC description for AV values.
Comment 7 Jonathan Druart 2024-10-10 13:29:13 UTC
I will have a look as well, next week.

Some things I have in mind right now (so more a note for myself)
* can we answer the need of translatability for plugins? Bug 37472
* to_string for the rest api (+search +search on embed)
* confirm the key problem we had on the other bugs is taken into account (same string same table, different translations)
* amount of remaining work to apply it to AVs

> It may or may not be what you want but at least
this avoids the problem where fixing an error in the original string
forces users to re-translate everything.

Then it's fuzzy
Comment 8 Julian Maurice 2024-10-11 09:36:21 UTC
(In reply to Jonathan Druart from comment #7)
> * can we answer the need of translatability for plugins? Bug 37472
This would require Koha::Schema to include plugins' result classes. Can it do that ?

> * confirm the key problem we had on the other bugs is taken into account
> (same string same table, different translations)
If I understand the problem correctly, you're talking about having (eg.) two itemtypes with the same description, and the problem is that you have to translate both ?
That's the problem I tried to avoid with my first approach but it had other issues. I'm not sure how you can have translations attached to one object AND avoid this problem.
So the response is: no, it's not taken into account.

But... if I remember correctly this was only a problem when we talked about translating MARC frameworks. If so, I believe it would be possible to have localizations managed differently only for MARC framework (by using a different DBIC component - or adapting the exiting one - to handle a special case where all similar objects share the same translations), while keeping the same public API (Koha::Object::localization).
(I'm thinking as I write, so sorry if it's not clear)

> > It may or may not be what you want but at least
> this avoids the problem where fixing an error in the original string
> forces users to re-translate everything.
> 
> Then it's fuzzy
Just to be clear, the proposed patch here have no concept of fuzziness.
Is it useful ? Can it be replaced by a warning ? ("You modified description, which has translations. Make sure the translations are still correct: <link to translations>")
Comment 9 Jonathan Druart 2024-10-15 14:17:41 UTC
Library limit for item types search is broken

DBIx::Class::Storage::DBI::_dbh_execute(): DBI Exception: DBD::mysql::st execute failed: Unknown column 'branchcode' in 'where clause' at /kohadevbox/koha/Koha/Objects.pm line 321

http://localhost:8081/cgi-bin/koha/cataloguing/additem.pl?op=edititem&biblionumber=4&itemnumber=18#edititem

Koha/UI/Form/Builder/Item.pm
214                 $itemtypes = Koha::ItemTypes->search_with_localization(                               
215                     { branchcode => $branch_limit } );
Comment 10 Julian Maurice 2024-10-16 08:27:35 UTC
Created attachment 172804 [details] [review]
Bug 38136: Fix call to search_with_localization with branchcode param

It was the only place where this parameter was used
Comment 11 Jonathan Druart 2024-10-23 09:21:47 UTC
Created attachment 173195 [details] [review]
Bug 38136: [TO SQUASH] Remove unecessary 'use Koha::Caches' from Koha::ItemType
Comment 12 Jonathan Druart 2024-10-23 09:21:49 UTC
Created attachment 173196 [details] [review]
Bug 38136: Show item type when adding translations
Comment 13 Jonathan Druart 2024-10-23 09:23:18 UTC
We are retrieving the value from the wrong cache in Koha/Template/Plugin/ItemTypes.pm, it is using Koha::Cache::Memory::Lite.

If you have a translation, remove it, add another one: the old one will be displayed (at least on catalogue/detail.pl in the items table).
Comment 14 Jonathan Druart 2024-10-23 09:26:04 UTC
(In reply to Jonathan Druart from comment #13)
> We are retrieving the value from the wrong cache in
> Koha/Template/Plugin/ItemTypes.pm, it is using Koha::Cache::Memory::Lite.
> 
> If you have a translation, remove it, add another one: the old one will be
> displayed (at least on catalogue/detail.pl in the items table).

Nope sorry, this does not make sense. The wrong fetch happens, but obviously not from the TT plugin (Memory::Lite it's not persistent from one request to another)
Comment 15 Julian Maurice 2024-10-23 09:30:07 UTC
(In reply to Jonathan Druart from comment #14)
> Nope sorry, this does not make sense. The wrong fetch happens, but obviously
> not from the TT plugin (Memory::Lite it's not persistent from one request to
> another)

The cache should be cleared when a translation is added, updated or removed. I'll check.
Comment 16 Jonathan Druart 2024-10-23 09:32:42 UTC
It's C4::Biblio::GetAuthorisedValueDesc that needs adjustments.
Comment 17 Jonathan Druart 2024-10-23 09:52:37 UTC
Created attachment 173197 [details] [review]
Bug 38136: Fix 'Delete' link

When a new entry has been added the Delete link was wrong.

Also fix translatability of "Delete"
Comment 18 Jonathan Druart 2024-10-23 10:04:32 UTC
Created attachment 173198 [details] [review]
Bug 38136: Return '404 Not Found' when trying to delete a non-existent translation
Comment 19 Jonathan Druart 2024-10-23 10:20:47 UTC
1. not blocker (personal preference) - I don't think we should have one localization table per table we want to support. The data integrity for free can be discussed as it would be easy to have a single line in Koha::Object->delete to delete the linked localizations. However I don't want to discuss this more or change the implementation, I can live with that.
OTOH it will be faster for the JOINs.

2. It would be nice to have a POC for AVs (on a separate bug report).

3. Not fond of Koha::DBIx, I would keep this under Koha::Schema (personal preference again, not blocker)
Comment 20 Marcel de Rooy 2024-10-25 08:56:43 UTC
I agree that it feels better to not add a table for each translation category.
Comment 21 Julian Maurice 2024-11-15 13:26:14 UTC
Created attachment 174578 [details] [review]
Bug 38136: Move DBIC component to Koha::Schema namespace
Comment 22 Julian Maurice 2024-11-15 13:26:17 UTC
Created attachment 174579 [details] [review]
Bug 38136: Fix C4::Biblio::GetAuthorisedValueDesc for itemtypes

Store itemtypes in memory cache so that we can use
translated_description, which will use the right cache
Comment 23 Julian Maurice 2024-11-15 13:26:19 UTC
Created attachment 174580 [details] [review]
Bug 38136: Fix cache not being cleared when updating a translation
Comment 24 Julian Maurice 2024-11-15 13:26:21 UTC
Created attachment 174581 [details] [review]
Bug 38136: Fix behavior of lang selector in translations editor
Comment 25 Julian Maurice 2024-11-15 13:47:47 UTC
> 2. It would be nice to have a POC for AVs (on a separate bug report).
I'm on it.
Comment 26 Julian Maurice 2024-11-15 15:29:59 UTC
Created attachment 174598 [details] [review]
Bug 38136: Fix localization cache
Comment 27 Julian Maurice 2024-11-15 15:30:01 UTC
Created attachment 174599 [details] [review]
Bug 38136: Die early if the localization relationship does not exist

confess shows the whole stacktrace which is useful to spot where we made
a mistake (croak showed the wrong file)
Comment 28 Julian Maurice 2024-11-15 15:30:36 UTC
(In reply to Julian Maurice from comment #25)
> > 2. It would be nice to have a POC for AVs (on a separate bug report).
> I'm on it.
bug 38460
Comment 29 Julian Maurice 2024-12-03 13:59:38 UTC
Created attachment 175077 [details] [review]
Bug 38136: Use a single table for all translations

We lose data integrity but we gain simplicity.
Automatic deletion of translations is handled by the DBIC
`cascade_delete` feature, so integrity should be fine as long as no
raw SQL update/delete operation is involved.
Comment 30 Julian Maurice 2024-12-03 14:02:04 UTC
(In reply to Julian Maurice from comment #29)
> Created attachment 175077 [details] [review] [review]
> Bug 38136: Use a single table for all translations
I added this patch alone so it's easy to see the changes but I will squash them all in a few minutes to ease testing/rebasing.
Comment 31 Julian Maurice 2024-12-03 14:18:47 UTC Comment hidden (obsolete)
Comment 32 Julian Maurice 2024-12-03 16:05:39 UTC Comment hidden (obsolete)
Comment 33 Julian Maurice 2024-12-03 16:19:53 UTC
Created attachment 175083 [details] [review]
Bug 38136: Refactor database translations (alternative)

This has the same goals of bug 24975 but with a different approach.

Bug 24975 tried the "POT/PO files as database tables" approach but
it appeared that is not what best fits our needs.

Instead of a "source text / translated text" mapping, we need
translations to be attached to a specific "object" (or table row), which
has the added benefit of keeping translations unaffected when the
original string changes. It may or may not be what you want but at least
this avoids the problem where fixing an error in the original string
forces users to re-translate everything.

We also need to be able to translate all translatable properties of a
particular entity.

The solution proposed here is to add a DBIC component that will add
several DBIC relations to the `localization` table:
* a relation named `localizations` that will return all translations for
  all translatable properties for all languages.
* for each translatable property:
  * a relation named `{$property}_localizations` that will return all
    translations for a given property, for all languages
  * a relation named `{$property}_localization` that will return the
    translation for a given property, for the current language

To enable translations for a particular entity, we will need to:
* add two method calls in the "result class" corresponding to the
  localizable object type
* in the admin interface, add a link to the the translation popup.
  Unlike bug 24975 there is not a page where you can translate
  everything. I don't know if it is really useful (probably better to
  translate itemtypes when you are on the itemtype page). It can be
  added later if needed.

To give an example, this is what needs to be added manually in
Koha/Schema/Result/Itemtype.pm:

    __PACKAGE__->load_components('+Koha::DBIx::Class::Localization');
    __PACKAGE__->localization_add_relationships(
        'itemtype', # the PK column
        'description' # a list of translatable columns
    );

(see POD in Koha/Schema/Component/Localization.pm for more information)

Final notes:
* I wanted this patch to have as few changes as possible so I kept
  methods like `search_with_localization`, `children_with_localization`
  even if I believe they can be removed (replaced by search/children)
  Localizations do not need to be prefetched/joined unless you want to
  sort on them.
  For the same reason, $itemtype->unblessed now always return a
  `translated_description` key.
  This can be fixed in followup patches
* There is cache involved (see
  Koha::Schema::Component::Localization::localization).
  Localizations in cache are grouped by object type and language (keys
  look like 'KOHA:localization:Itemtype:en')
* By keeping a single table for all translations of all entities, we
  cannot have data integrity at the RDBMS level, but automatic deletion
  of translations is handled by the DBIC `cascade_delete` feature, so
  integrity should be fine as long as no raw SQL update/delete operation
  is involved.
Comment 34 Katrin Fischer 2025-02-13 10:21:20 UTC
Is this something we could work on in Marseille? I know a lot of us would love the feature.
Comment 35 Julian Maurice 2025-02-13 12:41:12 UTC
Why wait ? It's ready to be signed off ! :-)
But I'll be around at Marseille if needed of course
Comment 36 Julian Maurice 2025-03-31 11:16:04 UTC
Created attachment 179978 [details] [review]
Bug 38136: Refactor database translations (alternative)

This has the same goals of bug 24975 but with a different approach.

Bug 24975 tried the "POT/PO files as database tables" approach but
it appeared that is not what best fits our needs.

Instead of a "source text / translated text" mapping, we need
translations to be attached to a specific "object" (or table row), which
has the added benefit of keeping translations unaffected when the
original string changes. It may or may not be what you want but at least
this avoids the problem where fixing an error in the original string
forces users to re-translate everything.

We also need to be able to translate all translatable properties of a
particular entity.

The solution proposed here is to add a DBIC component that will add
several DBIC relations to the `localization` table:
* a relation named `localizations` that will return all translations for
  all translatable properties for all languages.
* for each translatable property:
  * a relation named `{$property}_localizations` that will return all
    translations for a given property, for all languages
  * a relation named `{$property}_localization` that will return the
    translation for a given property, for the current language

To enable translations for a particular entity, we will need to:
* add two method calls in the "result class" corresponding to the
  localizable object type
* in the admin interface, add a link to the the translation popup.
  Unlike bug 24975 there is not a page where you can translate
  everything. I don't know if it is really useful (probably better to
  translate itemtypes when you are on the itemtype page). It can be
  added later if needed.

To give an example, this is what needs to be added manually in
Koha/Schema/Result/Itemtype.pm:

    __PACKAGE__->load_components('+Koha::DBIx::Class::Localization');
    __PACKAGE__->localization_add_relationships(
        'itemtype', # the PK column
        'description' # a list of translatable columns
    );

(see POD in Koha/Schema/Component/Localization.pm for more information)

Final notes:
* I wanted this patch to have as few changes as possible so I kept
  methods like `search_with_localization`, `children_with_localization`
  even if I believe they can be removed (replaced by search/children)
  Localizations do not need to be prefetched/joined unless you want to
  sort on them.
  For the same reason, $itemtype->unblessed now always return a
  `translated_description` key.
  This can be fixed in followup patches
* There is cache involved (see
  Koha::Schema::Component::Localization::localization).
  Localizations in cache are grouped by object type and language (keys
  look like 'KOHA:localization:Itemtype:en')
* By keeping a single table for all translations of all entities, we
  cannot have data integrity at the RDBMS level, but automatic deletion
  of translations is handled by the DBIC `cascade_delete` feature, so
  integrity should be fine as long as no raw SQL update/delete operation
  is involved.
Comment 37 Julian Maurice 2025-03-31 11:18:05 UTC
Patch rebased on main, ready to be tested !
Comment 38 Michaela Sieber 2025-04-01 08:15:47 UTC
Thanks! We would like to test, could you please provide a test plan?
Comment 39 Julian Maurice 2025-04-01 08:39:19 UTC
Created attachment 180096 [details] [review]
Bug 38136: Refactor database translations (alternative)

This has the same goals of bug 24975 but with a different approach.

Bug 24975 tried the "POT/PO files as database tables" approach but
it appeared that is not what best fits our needs.

Instead of a "source text / translated text" mapping, we need
translations to be attached to a specific "object" (or table row), which
has the added benefit of keeping translations unaffected when the
original string changes. It may or may not be what you want but at least
this avoids the problem where fixing an error in the original string
forces users to re-translate everything.

We also need to be able to translate all translatable properties of a
particular entity.

The solution proposed here is to add a DBIC component that will add
several DBIC relations to the `localization` table:
* a relation named `localizations` that will return all translations for
  all translatable properties for all languages.
* for each translatable property:
  * a relation named `{$property}_localizations` that will return all
    translations for a given property, for all languages
  * a relation named `{$property}_localization` that will return the
    translation for a given property, for the current language

To enable translations for a particular entity, we will need to:
* add two method calls in the "result class" corresponding to the
  localizable object type
* in the admin interface, add a link to the the translation popup.
  Unlike bug 24975 there is not a page where you can translate
  everything. I don't know if it is really useful (probably better to
  translate itemtypes when you are on the itemtype page). It can be
  added later if needed.

To give an example, this is what needs to be added manually in
Koha/Schema/Result/Itemtype.pm:

    __PACKAGE__->load_components('+Koha::DBIx::Class::Localization');
    __PACKAGE__->localization_add_relationships(
        'itemtype', # the PK column
        'description' # a list of translatable columns
    );

(see POD in Koha/Schema/Component/Localization.pm for more information)

Final notes:
* I wanted this patch to have as few changes as possible so I kept
  methods like `search_with_localization`, `children_with_localization`
  even if I believe they can be removed (replaced by search/children)
  Localizations do not need to be prefetched/joined unless you want to
  sort on them.
  For the same reason, $itemtype->unblessed now always return a
  `translated_description` key.
  This can be fixed in followup patches
* There is cache involved (see
  Koha::Schema::Component::Localization::localization).
  Localizations in cache are grouped by object type and language (keys
  look like 'KOHA:localization:Itemtype:en')
* By keeping a single table for all translations of all entities, we
  cannot have data integrity at the RDBMS level, but automatic deletion
  of translations is handled by the DBIC `cascade_delete` feature, so
  integrity should be fine as long as no raw SQL update/delete operation
  is involved.
Comment 40 Julian Maurice 2025-04-01 08:42:35 UTC
(In reply to Michaela Sieber from comment #38)
> Thanks! We would like to test, could you please provide a test plan?
As the patch is only refactoring code, there should not be any visible change. So the test plan would be to ensure item types localization interface still work, and that item types are correctly translated wherever they are displayed. If you find a place where they are not translated, please check if they were translated in the 'main' branch to confirm it's a regression caused by the patch.
Comment 41 Caroline Cyr La Rose 2025-04-01 12:06:59 UTC
Created attachment 180136 [details] [review]
Bug 38136: Refactor database translations (alternative)

This has the same goals of bug 24975 but with a different approach.

Bug 24975 tried the "POT/PO files as database tables" approach but
it appeared that is not what best fits our needs.

Instead of a "source text / translated text" mapping, we need
translations to be attached to a specific "object" (or table row), which
has the added benefit of keeping translations unaffected when the
original string changes. It may or may not be what you want but at least
this avoids the problem where fixing an error in the original string
forces users to re-translate everything.

We also need to be able to translate all translatable properties of a
particular entity.

The solution proposed here is to add a DBIC component that will add
several DBIC relations to the `localization` table:
* a relation named `localizations` that will return all translations for
  all translatable properties for all languages.
* for each translatable property:
  * a relation named `{$property}_localizations` that will return all
    translations for a given property, for all languages
  * a relation named `{$property}_localization` that will return the
    translation for a given property, for the current language

To enable translations for a particular entity, we will need to:
* add two method calls in the "result class" corresponding to the
  localizable object type
* in the admin interface, add a link to the the translation popup.
  Unlike bug 24975 there is not a page where you can translate
  everything. I don't know if it is really useful (probably better to
  translate itemtypes when you are on the itemtype page). It can be
  added later if needed.

To give an example, this is what needs to be added manually in
Koha/Schema/Result/Itemtype.pm:

    __PACKAGE__->load_components('+Koha::DBIx::Class::Localization');
    __PACKAGE__->localization_add_relationships(
        'itemtype', # the PK column
        'description' # a list of translatable columns
    );

(see POD in Koha/Schema/Component/Localization.pm for more information)

Final notes:
* I wanted this patch to have as few changes as possible so I kept
  methods like `search_with_localization`, `children_with_localization`
  even if I believe they can be removed (replaced by search/children)
  Localizations do not need to be prefetched/joined unless you want to
  sort on them.
  For the same reason, $itemtype->unblessed now always return a
  `translated_description` key.
  This can be fixed in followup patches
* There is cache involved (see
  Koha::Schema::Component::Localization::localization).
  Localizations in cache are grouped by object type and language (keys
  look like 'KOHA:localization:Itemtype:en')
* By keeping a single table for all translations of all entities, we
  cannot have data integrity at the RDBMS level, but automatic deletion
  of translations is handled by the DBIC `cascade_delete` feature, so
  integrity should be fine as long as no raw SQL update/delete operation
  is involved.

Signed-off-by: Caroline Cyr La Rose <caroline.cyr-la-rose@inlibro.com>
Comment 42 Caroline Cyr La Rose 2025-04-01 12:07:28 UTC
I don't remember all I did to make it work on KTD, but it involved the following commands

ktd --shell --root

dbic

reset_all

koha-translate --update fr-CA --dev kohadev

Then I activated the languages in system preferences. 

And then translated the itemtypes and finally, checked if they displayed in french in the french interface.

These are the pages I checked.

Intranet - OK
- advanced search
- results
- facets
- record details
- item details page
- item cataloging form
- item cataloging table
- item search form
- item search results
- item search csv export
- patron checkouts
- patron checkouts by itemtype
- record export tool
- holds queue form
- holds queue table
- holds to pull
- receiving orders
- catalog statistics
- circulation rules

Intranet - NOT OK (but was already NOT OK)
- report runtime parameter
- inventory tool
- adding course reserves
- add order from empty record
- serial subscription
- Batch modify due dates tool

OPAC - OK
- advanced search
- results
- facets
- record details
Comment 43 Michaela Sieber 2025-04-28 18:06:32 UTC
Ping :-) 
Volunteer for QA needed