https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38136 --- Comment #2 from Julian Maurice <julian.maurice@biblibre.com> --- Created attachment 172585 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=172585&action=edit 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. The solution proposed here is to store translations in separate tables, one table for each object type (so, one for itemtypes, another for authorised values, ...). While it may seem redundant and tedious to add another table with the same structure for each localizable object type, this has the benefit of being able to add foreign key constraints and thus having integrity checks "for free". Also this patch adds all the necessary tools so that the tedium of localizing a new object type is reduced to a minimum. In summary, we will only need to: * create the table structure (atomicupdate, kohastructure.sql) * 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( 'itemtypes_localizations', 'itemtype' => 'itemtype', 'description' ); (see POD in Koha/DBIx/Class/Localization.pm for more information) Final notes: * If having several localization tables is really a problem, I believe the current implementation can be changed easily to use a single table (just need to change the dbic relationship conditions) * 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::DBIx::Class::Localization::localization). Localizations in cache are grouped by object type and language (keys look like 'KOHA:localization:Itemtype:en') -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38136 --- Comment #3 from Julian Maurice <julian.maurice@biblibre.com> --- 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 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38136 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |m.de.rooy@rijksmuseum.nl --- Comment #4 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- (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. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38136 --- Comment #6 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- (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. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

* can we answer the need of translatability for plugins? Bug 37472 This would require Koha::Schema to include plugins' result classes. Can it do

* 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

...

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

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38136 --- Comment #8 from Julian Maurice <julian.maurice@biblibre.com> --- (In reply to Jonathan Druart from comment #7) that ? 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) translations>") -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38136 --- Comment #10 from Julian Maurice <julian.maurice@biblibre.com> --- Created attachment 172804 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=172804&action=edit Bug 38136: Fix call to search_with_localization with branchcode param It was the only place where this parameter was used -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38136 --- Comment #12 from Jonathan Druart <jonathan.druart@gmail.com> --- Created attachment 173196 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=173196&action=edit Bug 38136: Show item type when adding translations -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38136 --- Comment #14 from Jonathan Druart <jonathan.druart@gmail.com> --- (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) -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38136 --- Comment #16 from Jonathan Druart <jonathan.druart@gmail.com> --- It's C4::Biblio::GetAuthorisedValueDesc that needs adjustments. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38136 --- Comment #18 from Jonathan Druart <jonathan.druart@gmail.com> --- Created attachment 173198 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=173198&action=edit Bug 38136: Return '404 Not Found' when trying to delete a non-existent translation -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38136 --- Comment #19 from Jonathan Druart <jonathan.druart@gmail.com> --- 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) -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38136 --- Comment #21 from Julian Maurice <julian.maurice@biblibre.com> --- Created attachment 174578 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=174578&action=edit Bug 38136: Move DBIC component to Koha::Schema namespace -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38136 --- Comment #23 from Julian Maurice <julian.maurice@biblibre.com> --- Created attachment 174580 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=174580&action=edit Bug 38136: Fix cache not being cleared when updating a translation -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38136 Julian Maurice <julian.maurice@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Needs Signoff --- Comment #25 from Julian Maurice <julian.maurice@biblibre.com> ---

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

-- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38136 --- Comment #26 from Julian Maurice <julian.maurice@biblibre.com> --- Created attachment 174598 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=174598&action=edit Bug 38136: Fix localization cache -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38136 --- Comment #28 from Julian Maurice <julian.maurice@biblibre.com> --- (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

-- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38136 Julian Maurice <julian.maurice@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |ASSIGNED --- Comment #30 from Julian Maurice <julian.maurice@biblibre.com> --- (In reply to Julian Maurice from comment #29)

Created attachment 175077 [details] [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.

-- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38136 Julian Maurice <julian.maurice@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38136 Julian Maurice <julian.maurice@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #175082|0 |1 is obsolete| | --- Comment #33 from Julian Maurice <julian.maurice@biblibre.com> --- Created attachment 175083 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=175083&action=edit 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. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38136 --- Comment #34 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Is this something we could work on in Marseille? I know a lot of us would love the feature. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38136 Julian Maurice <julian.maurice@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Patch doesn't apply -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38136 Julian Maurice <julian.maurice@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Patch doesn't apply |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38136 Michaela Sieber <michaela.sieber@kit.edu> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |michaela.sieber@kit.edu --- Comment #38 from Michaela Sieber <michaela.sieber@kit.edu> --- Thanks! We would like to test, could you please provide a test plan? -- You are receiving this mail because: You are watching all bug changes.

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

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38136 --- Comment #40 from Julian Maurice <julian.maurice@biblibre.com> --- (In reply to Michaela Sieber from comment #38) translated in the 'main' branch to confirm it's a regression caused by the patch. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38136 Caroline Cyr La Rose <caroline.cyr-la-rose@inlibro.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #180096|0 |1 is obsolete| | --- Comment #41 from Caroline Cyr La Rose <caroline.cyr-la-rose@inlibro.com> --- Created attachment 180136 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=180136&action=edit 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> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38136 --- Comment #43 from Michaela Sieber <michaela.sieber@kit.edu> --- Ping :-) Volunteer for QA needed -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38136 Michaela Sieber <michaela.sieber@kit.edu> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |clemens.tubach@kit.edu, | |katrin.fischer@bsz-bw.de -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38136 Julian Maurice <julian.maurice@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #180136|0 |1 is obsolete| | --- Comment #44 from Julian Maurice <julian.maurice@biblibre.com> --- Created attachment 185846 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=185846&action=edit 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> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38136 Jonathan Druart <jonathan.druart@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Failed QA --- Comment #45 from Jonathan Druart <jonathan.druart@gmail.com> --- I've tried to rebase this patch, but I get the following error when accessing admin/itemtypes.pl Template process failed: undef error - DBIx::Class::ResultSource::_resolve_relationship_condition(): The join-free condition returned for relationship 'description_localizations' on source 'Itemtype' may only contain keys that are fully qualified column names of the corresponding source (it returned 'me.property') at /kohadevbox/koha/Koha/ItemType.pm line 63 https://gitlab.com/joubu/Koha/-/commits/bug_38136-rebased I am not confident in the rebase, there were several conflicts in the template. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38136 --- Comment #46 from Julian Maurice <julian.maurice@biblibre.com> --- Created attachment 191065 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=191065&action=edit 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> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38136 Julian Maurice <julian.maurice@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Patch doesn't apply --- Comment #48 from Julian Maurice <julian.maurice@biblibre.com> --- Patch does not apply -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38136 --- Comment #49 from Julian Maurice <julian.maurice@biblibre.com> --- Created attachment 195768 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=195768&action=edit 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> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38136 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |42187 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42187 [Bug 42187] Elasticsearch: Item type translations broken for facet descriptions -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38136 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Passed QA Patch complexity|--- |Medium patch -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38136 --- Comment #52 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Created attachment 196205 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=196205&action=edit 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> Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38136 --- Comment #54 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Created attachment 196207 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=196207&action=edit Bug 38136: Tidy Feel free to squash. Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38136 Lucas Gass (lukeg) <lucas@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Version(s)| |26.05.00 released in| | Status|Passed QA |Pushed to main -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38136 Lucas Gass (lukeg) <lucas@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords|RM_priority | -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38136 Lucas Gass (lukeg) <lucas@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |additional_work_needed --- Comment #58 from Lucas Gass (lukeg) <lucas@bywatersolutions.com> --- t/db_dependent/api/v1/items.t is failing now with this patch: not ok 3 - get() tests # Failed test 'get() tests' # at /kohadevbox/koha/t/db_dependent/api/v1/items.t line 372. DBIx::Class::Storage::DBI::_dbh_execute(): DBI Exception: DBD::mysql::st execute failed: Field 'property' doesn't have a default value at /kohadevbox/koha/t/db_dependent/api/v1/items.t line 361 ok 4 - no warnings # Looks like your test exited with 2 just after 4. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38136 --- Comment #60 from Lucas Gass (lukeg) <lucas@bywatersolutions.com> --- My followup isn't quite right. With it applied the tests pass on the first run but fail on all subsequent runs. Not sure why, something isn't rolling back properly? -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38136 --- Comment #62 from Jonathan Druart <jonathan.druart@gmail.com> --- Created attachment 197679 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=197679&action=edit Bug 38136: Clear localization cache before testing itemtype localization Patch from commit 9855b2d -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38136 Jacob O'Mara <jacob.omara@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Pushed to main |Needs documenting --- Comment #64 from Jacob O'Mara <jacob.omara@openfifth.co.uk> --- This will not be backported to 25.11.x due to it being deemed an enhancement or a dependancy not being met -- You are receiving this mail because: You are watching all bug changes.