https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24975 --- Comment #1 from Julian Maurice <julian.maurice@biblibre.com> --- Created attachment 101703 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=101703&action=edit Bug 24975: Refactor database translations This is an attempt to make the process of translating database strings (like itemtype descriptions) easier for developers and translators. For developers by reducing the amount of code needed to enable translations for a new kind of object (authorised values, letters, news, ...). For translators by providing a single entry point for all translatable strings Table `localization` is replaced by two new tables `l10n_source` and `l10n_target`. `l10n_source` contains the original text while `l10n_target` contains the corresponding translations `l10n_source` is automatically updated whenever an itemtype is inserted, updated, or deleted, so it is always up to date (this is done in Koha::Schema::Result::ItemType). It means that if you delete an itemtype, translations get deleted too. It also means that if you change an itemtype's description, translations are lost (not sure if this should be fixed, since if description changes, translations should probably be changed too) It adds a new subroutine in Koha::I18N, `db_t`, which returns the translation for a given context and string, according to the current language. Translations are stored in memcached (if enabled). So instead of having to declare a new subroutine Koha::ItemType::translated_description, you can write db_t('itemtype', $itemtype->description) In templates you can write [% ItemTypes.t(itemtype.description) %] There's also a new page, accessible from the administration main page, "Localization". It displays all translatable strings and allow to translate them for all enabled languages. Test plan: 1. Before applying the patch, make sure you have translated some itemtypes. Translations should be kept by the updatedatabase script. Before applying the updatedatabase you may want to comment the 'DROP TABLE localization' statement if you want to keep this table 2. Apply patch, run updatedatabase.pl, run update_dbix_class_files.pl and reload starman 3. Go to Admin » Localization, verify that you have your itemtypes and their translations. 4. Verify that the filter is working (it filters on the source column only). 5. Translate some strings by clicking on one of the 'Translate' link, entering some text and clicking on the 'Save' button. You can remove a translation by emptying the text box. 6. Add a new item type. Verify that it appears in the Localization page 7. Change the description of this item type. Verify that the new description appears in Localization page and that the old description is gone 8. Delete this item type and verify that its description no longer appears in Localization page 9. Navigate through Koha (intranet and opac) in multiple languages and verify that item types are translated (if not, please verify in master too, not all occurrences were translated) -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24975 --- Comment #2 from Jonathan Druart <jonathan.druart@bugs.koha-community.org> --- That looks like a great idea. What about the interface (for AVs)? -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24975 Julian Maurice <julian.maurice@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |24977 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24977 [Bug 24977] Enable translations for authorised values (POC) -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24975 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bgkriegel@gmail.com, | |martin.renvoize@ptfs-europe | |.com -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24975 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tomascohen@gmail.com -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24975 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #101703|0 |1 is obsolete| | --- Comment #5 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Created attachment 102387 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=102387&action=edit Bug 24975: Refactor database translations This is an attempt to make the process of translating database strings (like itemtype descriptions) easier for developers and translators. For developers by reducing the amount of code needed to enable translations for a new kind of object (authorised values, letters, news, ...). For translators by providing a single entry point for all translatable strings Table `localization` is replaced by two new tables `l10n_source` and `l10n_target`. `l10n_source` contains the original text while `l10n_target` contains the corresponding translations `l10n_source` is automatically updated whenever an itemtype is inserted, updated, or deleted, so it is always up to date (this is done in Koha::Schema::Result::ItemType). It means that if you delete an itemtype, translations get deleted too. It also means that if you change an itemtype's description, translations are lost (not sure if this should be fixed, since if description changes, translations should probably be changed too) It adds a new subroutine in Koha::I18N, `db_t`, which returns the translation for a given context and string, according to the current language. Translations are stored in memcached (if enabled). So instead of having to declare a new subroutine Koha::ItemType::translated_description, you can write db_t('itemtype', $itemtype->description) In templates you can write [% ItemTypes.t(itemtype.description) %] There's also a new page, accessible from the administration main page, "Localization". It displays all translatable strings and allow to translate them for all enabled languages. Test plan: 1. Before applying the patch, make sure you have translated some itemtypes. Translations should be kept by the updatedatabase script. Before applying the updatedatabase you may want to comment the 'DROP TABLE localization' statement if you want to keep this table 2. Apply patch, run updatedatabase.pl, run update_dbix_class_files.pl and reload starman 3. Go to Admin » Localization, verify that you have your itemtypes and their translations. 4. Verify that the filter is working (it filters on the source column only). 5. Translate some strings by clicking on one of the 'Translate' link, entering some text and clicking on the 'Save' button. You can remove a translation by emptying the text box. 6. Add a new item type. Verify that it appears in the Localization page 7. Change the description of this item type. Verify that the new description appears in Localization page and that the old description is gone 8. Delete this item type and verify that its description no longer appears in Localization page 9. Navigate through Koha (intranet and opac) in multiple languages and verify that item types are translated (if not, please verify in master too, not all occurrences were translated) Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24975 --- Comment #7 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- I like this, and it's working pretty well in testing.. few comments however 1/ The 'Localization' option appears in the admin home screen whether or not you have any translations installed.. if you then navigate into it you get an ajax request that fails for the datatable if there are no translations available. 2/ You switch from Koha::Object classes to plain DBIx ResultSets.. was that deliberate and if so can you explain why (I'm betting it was a performance perspective?) -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24975 --- Comment #9 from Julian Maurice <julian.maurice@biblibre.com> --- (In reply to Martin Renvoize from comment #7)

2/ You switch from Koha::Object classes to plain DBIx ResultSets.. was that deliberate and if so can you explain why (I'm betting it was a performance perspective?)

(pasting my answer on IRC here for reference:) I had performance in mind (but i did not measure it), but also, some parts of Koha use DBIx::Class directly, so by putting the code at DBIX::Class level it should work whether you use dbix::class or koha::objects. Thanks for testing :) -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24975 Jonathan Druart <jonathan.druart@bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #102387|0 |1 is obsolete| | --- Comment #10 from Jonathan Druart <jonathan.druart@bugs.koha-community.org> --- Created attachment 102513 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=102513&action=edit Bug 24975: Refactor database translations This is an attempt to make the process of translating database strings (like itemtype descriptions) easier for developers and translators. For developers by reducing the amount of code needed to enable translations for a new kind of object (authorised values, letters, news, ...). For translators by providing a single entry point for all translatable strings Table `localization` is replaced by two new tables `l10n_source` and `l10n_target`. `l10n_source` contains the original text while `l10n_target` contains the corresponding translations `l10n_source` is automatically updated whenever an itemtype is inserted, updated, or deleted, so it is always up to date (this is done in Koha::Schema::Result::ItemType). It means that if you delete an itemtype, translations get deleted too. It also means that if you change an itemtype's description, translations are lost (not sure if this should be fixed, since if description changes, translations should probably be changed too) It adds a new subroutine in Koha::I18N, `db_t`, which returns the translation for a given context and string, according to the current language. Translations are stored in memcached (if enabled). So instead of having to declare a new subroutine Koha::ItemType::translated_description, you can write db_t('itemtype', $itemtype->description) In templates you can write [% ItemTypes.t(itemtype.description) %] There's also a new page, accessible from the administration main page, "Localization". It displays all translatable strings and allow to translate them for all enabled languages. Test plan: 1. Before applying the patch, make sure you have translated some itemtypes. Translations should be kept by the updatedatabase script. Before applying the updatedatabase you may want to comment the 'DROP TABLE localization' statement if you want to keep this table 2. Apply patch, run updatedatabase.pl, run update_dbix_class_files.pl and reload starman 3. Go to Admin » Localization, verify that you have your itemtypes and their translations. 4. Verify that the filter is working (it filters on the source column only). 5. Translate some strings by clicking on one of the 'Translate' link, entering some text and clicking on the 'Save' button. You can remove a translation by emptying the text box. 6. Add a new item type. Verify that it appears in the Localization page 7. Change the description of this item type. Verify that the new description appears in Localization page and that the old description is gone 8. Delete this item type and verify that its description no longer appears in Localization page 9. Navigate through Koha (intranet and opac) in multiple languages and verify that item types are translated (if not, please verify in master too, not all occurrences were translated) Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24975 Jonathan Druart <jonathan.druart@bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Failed QA --- Comment #12 from Jonathan Druart <jonathan.druart@bugs.koha-community.org> --- It does not work for me. The table does not load on admin/localization.pl DBIx::Class::Storage::DBI::_dbh_execute(): Unknown column 'me.context' in 'field list' at /kohadevbox/koha/svc/localization line 35 I rebased the patches because of conflicts with bug 4944. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24975 --- Comment #14 from Julian Maurice <julian.maurice@biblibre.com> --- Created attachment 102688 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=102688&action=edit Bug 24975: Fix l10n_source definition in kohastructure.sql -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24975 Jonathan Druart <jonathan.druart@bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Failed QA --- Comment #16 from Jonathan Druart <jonathan.druart@bugs.koha-community.org> --- I've talked a bit with Julian, and there is something that is not correct IMO. The translation for the item type "BK/Books" is picked using its description, "Books". Which means that if we have another itemtype with the same description "BK2/Books", its translation string will be used for BK. For instance: BK/Books translated in fr-FR => "Livre" BK2/Books translated in fr-FR => "Autre livre" Item type BK will be display "Autre livre" in French. I should also note that the collation for the 2 new tables is utf8mb4_bin (instead of the usual utf8mb4_unicode_ci), to differentiate "Book" and "book". But I have tried: BK/Books translated in fr-FR => "Livre" BK2/books translated in fr-FR => "Autre livre" An I still see "Autre livre" for "BK/Books". I know it does not make a lot a sense in a real-life situation, but I think we hit a design issue. This problem might be highlighted even more for AV, when we will need to take into account the "interface". I think we should rethink this a bit and have (add back) a method at Koha::ItemType level to retrieve the translated string. That will give us more flexibility for future changes (now we need to update all the occurrences of db_t). I still think this implementation is better than the original one, but it still need a bit of tuning to be ready IMO. Failing QA/In Discussion. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24975 --- Comment #18 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Are you hoping to continue here Julian.. it's looking so promising :) -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24975 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |rel_20_11_target -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24975 --- Comment #21 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- (In reply to Julian Maurice from comment #20)

I've been rethinking about this.

If we fetch a translation using a key like "itemtype-BK", or "authorisedvalue-CCODE-FIC-OPAC" it might work well for these two type of entities, because there would be a 1:1 relationship between every string and its translation, and there should not be too much duplicated translations. But what if we want to make MARC frameworks translatable too ? Say I have 10 frameworks that share 95% of their field/subfield descriptions, I'll have to translate each of these strings 10 times, because there would be a translation for "framework-FW1-245a-OPAC" and another for "framework-FW2-245a-OPAC" and so on. Waste of time and DB space.

So I think it would be better to fetch a translation using the text, for instance "framework-Title". That way every field/subfield description in a MARC framework that is "Title" would be translated the same way and the translator would need to translate it only once. Bonus: if you create a new framework it will already be translated.

Now there is still a design issue with the current implementation (comment 16) where Koha allows to give multiple translations to the same original text, but only one of those will be picked and the others will never show up. I think it can be solved by using a different db schema, but before going into more details I would like to hear what people think about the "key vs text" topic.

By the way, I think the collation issue in comment 16 was in fact a cache issue. The cache is not always cleared when it should be, and I tested the exact same example and it worked for me.

I'm confused.. you seem to suggest shifting from code based keys to description based keys and then revert again in the next paragraph. I feel like we should be using code based keys for flexability/reliability but allow for a fallback chain for cases like frameworks.. so for example 'framework-FW2-245a-OPAC' could fallback to a 'framework-*-245a-OPAC' for a case where the FW2 specific case doesn't exist? I need to look at the code again to really get to grips with that suggestion so please feel free to cast it aside if it's non-sense. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24975 --- Comment #23 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- I'm coming back around to keying on the original text now rather than a definitive unique key. However, I think we should allow for the key to be passed in additional and perhaps other variables too eventually. My thinking behind this is all the various options we have now for plural forms and the likes in the rest of the translation system. It's those cases I could see requiring additional options to refine which version of a translation to 'pick'. So.. my thinking is along the lines db_t($itype->itemtype, $itype->description, { key => $itype->code, count => $x }); Where the first two params are required, but the hashref or additional arguments is optional depending on the situation. This way, we can key on the description text and allow for passing the code as an option to allow for more specific selection it it exists but fallback to just description as the key if it does not. Something similar to the way we allow falling back through rules in the circ rules system.. if the more specific case doesn't exist we trap the less specific case. I'll have a little play with the code but I think this could end up flexible enough to support future expansions and allow for more and less specific cases in translation as required. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24975 --- Comment #25 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Code speaks more than words.. I've been having a play with a couple of followups to use a 'key' rather than rely on the string as the key for lookup, adding 'fuzzy' support and re-introducing an accessor method on the Koha::ItemType object: https://gitlab.com/mrenvoize/Koha/-/commits/bug_24975 Still a work in progress but would love some feedback as to whether this might be a route to adopt. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24975 --- Comment #26 from Julian Maurice <julian.maurice@biblibre.com> --- (In reply to Martin Renvoize from comment #25)

Code speaks more than words.. I've been having a play with a couple of followups to use a 'key' rather than rely on the string as the key for lookup, adding 'fuzzy' support and re-introducing an accessor method on the Koha::ItemType object:

https://gitlab.com/mrenvoize/Koha/-/commits/bug_24975

Still a work in progress but would love some feedback as to whether this might be a route to adopt.

Does it solve the problem we mentioned with framework translations ? -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24975 --- Comment #28 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- What I'm also tempted to do is add a standardly named accessor be to objects with translatable fields.. ->translation_key which would produce the right key from the internal fields behind the scenes. So for itemtype it simply passes through itemtype, but for a it might pass $code_$interface for example. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24975 --- Comment #30 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- (In reply to Julian Maurice from comment #29)

(In reply to Martin Renvoize from comment #27)

...

We key on new 'key' field. So it leaves it up to the person whome implements the next translatable feature to pick an appropriate key.

For frameworks I would suggest a group of 'framework' and a key of 'marc field'.. thus allowing to translate at the default framework level but keep marc fields distinct for the cases as mentioned by Jonas on IRC.

I'm confused. Do you mean something like db_t('framework', 'marc field', { marc_field => '245a', type => 'opac' }) or db_t('framework', '245a-opac') or db_t('framework-FW1', '245a-opac') or something else ?

I could not find what Jonas mentioned on IRC, that probably doesn't help me to understand :) Can you paste it or summarize it here ?

db_t('framework', '245a'); or if you need it at an interface level too db_t('framework', '245a-opac'); i.e. We leave defining the granularity of the key to the developer adding the translation option to the component and we discus that granularity there. What I've not done is any form of fallback system.. i.e. if we wanted to allow one to optionally define translations at a more granular level, for per framework for example. example db_t('framework', 'FA-245a');.. fall back to just '245a' if the 'FA-' translation doesn't exist. I felt that was out of scope for here.. and perhaps not really required. I'll go dig out the IRC log. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24975 --- Comment #32 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- To add detail to that.. it's two different translations for the single word 'Status' in English for the Finnish translation. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24975 --- Comment #34 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- My point is.. I've tried to make it flexible enough without introducing too much additional overhead/code complexity here. I suggest we should not second guess the level of translation requirements/granularity of different components here but rather defer that to each bug introducing additional translation options. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24975 Jonathan Druart <jonathan.druart@bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- QA Contact|jonathan.druart@bugs.koha-c | |ommunity.org | Keywords|rel_20_11_target |rel_21_05_candidate --- Comment #36 from Jonathan Druart <jonathan.druart@bugs.koha-community.org> --- Could we get a work team on this one and target 21.05? -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24975 --- Comment #37 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Also very interested in this, can provide testing and QA. A quick discussion on how to approach this would be nice! -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24975 Jonathan Druart <jonathan.druart+koha@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords|rel_21_05_candidate |rel_21_11_candidate -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24975 Marjorie Barry-Vila <marjorie.barry-vila@collecto.ca> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |marjorie.barry-vila@collect | |o.ca -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24975 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks|23681 | Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23681 [Bug 23681] Patron restrictions should be user definable -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24975 --- Comment #39 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- I think my branch contained the latest in progress work.. but it needs a non-trivial rebase. My hope is to catc Jonathan and Julian at Hackfest to work through the final details... it feels so close! -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24975 --- Comment #41 from Jonathan Druart <jonathan.druart+koha@gmail.com> --- This patch fixes 3 500 errors, to apply on top of Martin's remote branch. I translated Books to "Livres" in fr-FR, install templates for fr-FR but there is nothing displayed. At least on the item table of the catalogue/detail.pl page. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24975 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #102514|0 |1 is obsolete| | --- Comment #43 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Created attachment 132509 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=132509&action=edit Bug 24975: Keep the translations, prevent duplicates, and other fixes Translations are no longer lost when you change an itemtype's description, thanks to a new `l10n_source.key` column which must be unique within it's "text group" ('itemtype' is a text group) This also prevent duplicate entries in l10n_source Columns were renamed to better match their purpose: * context -> group * source -> text Use Koha::Cache::Memory::Lite if other caching systems are not available Prepend 'l10n:' to the cache key to avoid conflicts Test plan: 1. DROP TABLE IF EXISTS l10n_target, l10n_source 2. Follow the test plan from previous patch Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> https://bugs.koha-community.org/show_bug.cgi?id=24875 -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24975 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #102701|0 |1 is obsolete| | --- Comment #45 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Created attachment 132511 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=132511&action=edit Bug 24975: Fix syntax issues https://bugs.koha-community.org/show_bug.cgi?id=24875 -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24975 --- Comment #47 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Created attachment 132513 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=132513&action=edit Bug 24975: Use 'key' for translation lookup This patch switches from using the original text as a key for translations to using a dedicated 'key' field. We also add in a 'fuzzy' flag to denote when the source text has changed and as such the pre-existing translations may be incorrect. ToDo: 1/ Expose 'Fuzzy' on the 'Localization' admin page 2/ Add a 'translation_key' method to Koha::Itemtype to encourage the adoption of a standardly names accessor to get the 'translation_key' from a Koha::Object derived class. https://bugs.koha-community.org/show_bug.cgi?id=24875 -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24975 --- Comment #49 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Created attachment 132515 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=132515&action=edit Bug 24975: Add translation_key method example https://bugs.koha-community.org/show_bug.cgi?id=24875 -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24975 --- Comment #51 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Created attachment 132517 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=132517&action=edit Bug 24975: Add to Koha::UI::Form::Builder::Item https://bugs.koha-community.org/show_bug.cgi?id=24875 -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24975 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #132388|0 |1 is obsolete| | --- Comment #53 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Created attachment 132519 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=132519&action=edit Bug 24975: Fix bugs https://bugs.koha-community.org/show_bug.cgi?id=24875 -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24975 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #132508|0 |1 is obsolete| | --- Comment #55 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Created attachment 132521 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=132521&action=edit Bug 24975: Refactor database translations This is an attempt to make the process of translating database strings (like itemtype descriptions) easier for developers and translators. For developers by reducing the amount of code needed to enable translations for a new kind of object (authorised values, letters, news, ...). For translators by providing a single entry point for all translatable strings Table `localization` is replaced by two new tables `l10n_source` and `l10n_target`. `l10n_source` contains the original text while `l10n_target` contains the corresponding translations `l10n_source` is automatically updated whenever an itemtype is inserted, updated, or deleted, so it is always up to date (this is done in Koha::Schema::Result::ItemType). It means that if you delete an itemtype, translations get deleted too. It also means that if you change an itemtype's description, translations are lost (not sure if this should be fixed, since if description changes, translations should probably be changed too) It adds a new subroutine in Koha::I18N, `db_t`, which returns the translation for a given context and string, according to the current language. Translations are stored in memcached (if enabled). So instead of having to declare a new subroutine Koha::ItemType::translated_description, you can write db_t('itemtype', $itemtype->description) In templates you can write [% ItemTypes.t(itemtype.description) %] There's also a new page, accessible from the administration main page, "Localization". It displays all translatable strings and allow to translate them for all enabled languages. Test plan: 1. Before applying the patch, make sure you have translated some itemtypes. Translations should be kept by the updatedatabase script. Before applying the updatedatabase you may want to comment the 'DROP TABLE localization' statement if you want to keep this table 2. Apply patch, run updatedatabase.pl, run update_dbix_class_files.pl and reload starman 3. Go to Admin » Localization, verify that you have your itemtypes and their translations. 4. Verify that the filter is working (it filters on the source column only). 5. Translate some strings by clicking on one of the 'Translate' link, entering some text and clicking on the 'Save' button. You can remove a translation by emptying the text box. 6. Add a new item type. Verify that it appears in the Localization page 7. Change the description of this item type. Verify that the new description appears in Localization page and that the old description is gone 8. Delete this item type and verify that its description no longer appears in Localization page 9. Navigate through Koha (intranet and opac) in multiple languages and verify that item types are translated (if not, please verify in master too, not all occurrences were translated) Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24975 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #132510|0 |1 is obsolete| | --- Comment #57 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Created attachment 132523 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=132523&action=edit Bug 24975: Fix l10n_source definition in kohastructure.sql -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24975 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #132512|0 |1 is obsolete| | --- Comment #59 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Created attachment 132525 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=132525&action=edit Bug 24975: (follow-up) Rebase for bug 21946 -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24975 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #132514|0 |1 is obsolete| | --- Comment #61 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Created attachment 132527 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=132527&action=edit Bug 24975: Re-introduce translated_description accessor method -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24975 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #132516|0 |1 is obsolete| | --- Comment #63 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Created attachment 132529 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=132529&action=edit Bug 24975: Use translation_key in preference to description -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24975 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #132518|0 |1 is obsolete| | --- Comment #65 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Created attachment 132531 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=132531&action=edit Bug 24975: DBIC Build -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24975 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #132520|0 |1 is obsolete| | --- Comment #67 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Created attachment 132533 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=132533&action=edit Bug 24975: Pass transation_key in GetItemsInfo -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24975 --- Comment #69 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Created attachment 132546 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=132546&action=edit Bug 24975: Fix bug -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24975 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #132522|0 |1 is obsolete| | --- Comment #71 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Created attachment 132563 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=132563&action=edit Bug 24975: Keep the translations, prevent duplicates, and other fixes Translations are no longer lost when you change an itemtype's description, thanks to a new `l10n_source.key` column which must be unique within it's "text group" ('itemtype' is a text group) This also prevent duplicate entries in l10n_source Columns were renamed to better match their purpose: * context -> group * source -> text Use Koha::Cache::Memory::Lite if other caching systems are not available Prepend 'l10n:' to the cache key to avoid conflicts Test plan: 1. DROP TABLE IF EXISTS l10n_target, l10n_source 2. Follow the test plan from previous patch Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24975 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #132524|0 |1 is obsolete| | --- Comment #73 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Created attachment 132565 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=132565&action=edit Bug 24975: Fix syntax issues -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24975 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #132526|0 |1 is obsolete| | --- Comment #75 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Created attachment 132567 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=132567&action=edit Bug 24975: Use 'key' for translation lookup This patch switches from using the original text as a key for translations to using a dedicated 'key' field. We also add in a 'fuzzy' flag to denote when the source text has changed and as such the pre-existing translations may be incorrect. ToDo: 1/ Expose 'Fuzzy' on the 'Localization' admin page 2/ Add a 'translation_key' method to Koha::Itemtype to encourage the adoption of a standardly names accessor to get the 'translation_key' from a Koha::Object derived class. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24975 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #132528|0 |1 is obsolete| | --- Comment #77 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Created attachment 132569 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=132569&action=edit Bug 24975: Add translation_key method example -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24975 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #132530|0 |1 is obsolete| | --- Comment #79 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Created attachment 132571 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=132571&action=edit Bug 24975: Add to Koha::UI::Form::Builder::Item -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24975 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #132533|0 |1 is obsolete| | --- Comment #81 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Created attachment 132573 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=132573&action=edit Bug 24975: Pass transation_key in GetItemsInfo -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24975 --- Comment #83 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Created attachment 132575 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=132575&action=edit Bug 24975: Fix db_t The query here is difficult.. I wanted to return FULL LEFT JOIN, but filtering on the joined data (l10n_targets.language) means we drop the l10n_source rows where there are no corresponding l10n_targets with language code. I tried setting `l10n_targets.language => [ $language, undef ]` to include null values, but that doesn't work either. I then tried coming up with a correlate subquery instead of the join and couldn't get dbic to play nicely there either. As such, I've fallen back to multiple queries over the relationship.. I'm sure we can do better... but this works for now. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24975 Joonas Kylmälä <joonas.kylmala@iki.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |joonas.kylmala@iki.fi Status|Needs Signoff |Patch doesn't apply --- Comment #85 from Joonas Kylmälä <joonas.kylmala@iki.fi> --- (In reply to Martin Renvoize from comment #84)

Ready for testing..

Martin, I assume the patches attached to this bug report from you are the latest. They don't apply anymore. Could you do a rebase? -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24975 Lauren Denny <lauren_denny@sil.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lauren_denny@sil.org -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24975 Jonathan Druart <jonathan.druart+koha@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #132546|0 |1 is obsolete| | Attachment #132562|0 |1 is obsolete| | Attachment #132563|0 |1 is obsolete| | Attachment #132564|0 |1 is obsolete| | Attachment #132565|0 |1 is obsolete| | Attachment #132566|0 |1 is obsolete| | Attachment #132567|0 |1 is obsolete| | Attachment #132568|0 |1 is obsolete| | Attachment #132569|0 |1 is obsolete| | Attachment #132570|0 |1 is obsolete| | Attachment #132571|0 |1 is obsolete| | Attachment #132572|0 |1 is obsolete| | Attachment #132573|0 |1 is obsolete| | Attachment #132574|0 |1 is obsolete| | Attachment #132575|0 |1 is obsolete| | --- Comment #87 from Jonathan Druart <jonathan.druart+koha@gmail.com> --- Created attachment 149941 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=149941&action=edit Bug 24975: Refactor database translations This is an attempt to make the process of translating database strings (like itemtype descriptions) easier for developers and translators. For developers by reducing the amount of code needed to enable translations for a new kind of object (authorised values, letters, news, ...). For translators by providing a single entry point for all translatable strings Table `localization` is replaced by two new tables `l10n_source` and `l10n_target`. `l10n_source` contains the original text while `l10n_target` contains the corresponding translations `l10n_source` is automatically updated whenever an itemtype is inserted, updated, or deleted, so it is always up to date (this is done in Koha::Schema::Result::ItemType). It means that if you delete an itemtype, translations get deleted too. It also means that if you change an itemtype's description, translations are lost (not sure if this should be fixed, since if description changes, translations should probably be changed too) It adds a new subroutine in Koha::I18N, `db_t`, which returns the translation for a given context and string, according to the current language. Translations are stored in memcached (if enabled). So instead of having to declare a new subroutine Koha::ItemType::translated_description, you can write db_t('itemtype', $itemtype->description) In templates you can write [% ItemTypes.t(itemtype.description) %] There's also a new page, accessible from the administration main page, "Localization". It displays all translatable strings and allow to translate them for all enabled languages. Test plan: 1. Before applying the patch, make sure you have translated some itemtypes. Translations should be kept by the updatedatabase script. Before applying the updatedatabase you may want to comment the 'DROP TABLE localization' statement if you want to keep this table 2. Apply patch, run updatedatabase.pl, run update_dbix_class_files.pl and reload starman 3. Go to Admin » Localization, verify that you have your itemtypes and their translations. 4. Verify that the filter is working (it filters on the source column only). 5. Translate some strings by clicking on one of the 'Translate' link, entering some text and clicking on the 'Save' button. You can remove a translation by emptying the text box. 6. Add a new item type. Verify that it appears in the Localization page 7. Change the description of this item type. Verify that the new description appears in Localization page and that the old description is gone 8. Delete this item type and verify that its description no longer appears in Localization page 9. Navigate through Koha (intranet and opac) in multiple languages and verify that item types are translated (if not, please verify in master too, not all occurrences were translated) Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24975 --- Comment #89 from Jonathan Druart <jonathan.druart+koha@gmail.com> --- Created attachment 149943 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=149943&action=edit Bug 24975: Fix l10n_source definition in kohastructure.sql -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24975 --- Comment #91 from Jonathan Druart <jonathan.druart+koha@gmail.com> --- Created attachment 149945 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=149945&action=edit Bug 24975: (follow-up) Rebase for bug 21946 -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24975 --- Comment #93 from Jonathan Druart <jonathan.druart+koha@gmail.com> --- Created attachment 149947 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=149947&action=edit Bug 24975: Re-introduce translated_description accessor method -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24975 --- Comment #95 from Jonathan Druart <jonathan.druart+koha@gmail.com> --- Created attachment 149949 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=149949&action=edit Bug 24975: Use translation_key in preference to description -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24975 --- Comment #97 from Jonathan Druart <jonathan.druart+koha@gmail.com> --- Created attachment 149951 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=149951&action=edit Bug 24975: Fix bugs -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24975 --- Comment #99 from Jonathan Druart <jonathan.druart+koha@gmail.com> --- Created attachment 149953 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=149953&action=edit Bug 24975: Fix db_t The query here is difficult.. I wanted to return FULL LEFT JOIN, but filtering on the joined data (l10n_targets.language) means we drop the l10n_source rows where there are no corresponding l10n_targets with language code. I tried setting `l10n_targets.language => [ $language, undef ]` to include null values, but that doesn't work either. I then tried coming up with a correlate subquery instead of the join and couldn't get dbic to play nicely there either. As such, I've fallen back to multiple queries over the relationship.. I'm sure we can do better... but this works for now. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24975 Jonathan Druart <jonathan.druart+koha@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|julian.maurice@biblibre.com |jonathan.druart+koha@gmail. | |com --- Comment #101 from Jonathan Druart <jonathan.druart+koha@gmail.com> --- Patches rebased, not without troubles... IMO there are inconsistencies in the way we deal with itemtypes, and we should correct that in this patch set. We should always either call db_t in the script and pass the translated version to the template, or pass the object and let the template deals with it. Ready for testing (spoiler: it is full of bugs). Remote branch pushed to https://gitlab.com/joubu/Koha/-/commits/bug_24975 -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24975 --- Comment #103 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Created attachment 149956 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=149956&action=edit Bug 24975: (follow-up) Fix dbrev -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24975 --- Comment #105 from Jonathan Druart <jonathan.druart+koha@gmail.com> --- Created attachment 149957 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=149957&action=edit Bug 24975: WIP remove db_t from controllers This is not done yet, for discussion. I don't think we should call db_t in controllers, or we do it better, but now it's confusing. This patch may impact performances, as we are not caching the itemtype object. Ideas? -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24975 --- Comment #107 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Will post some more comments tomorrow. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24975 --- Comment #109 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- There is still something confusing in the table design: select * from l10n_source; +----------------+----------+-----+------------------------+ | l10n_source_id | group | key | text | +----------------+----------+-----+------------------------+ | 1 | itemtype | BK | Books | | 2 | itemtype | BKS | Books | | 3 | itemtype | CF | Computer Files | select * from l10n_target; +----------------+----------------+----------+-----------------+-------+ | l10n_target_id | l10n_source_id | language | translation | fuzzy | +----------------+----------------+----------+-----------------+-------+ | 2 | 1 | nl-NL | Boek | 0 | | 3 | 2 | en | BKS_EN | 0 | | 4 | 2 | nl-NL | Boek | 0 | The source seems to be the English text. But I can translate it into EN again via target. Easiest seems to be: prevent having EN in the target table. Shouldnt we check if we are calling db_t btw for an English translation? We should not be looking for the English translation of itemtype if we have the description already in our object. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24975 Jonathan Druart <jonathan.druart+koha@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |ASSIGNED -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24975 --- Comment #112 from Jonathan Druart <jonathan.druart+koha@gmail.com> --- (In reply to Jonathan Druart from comment #111)

...

Bug 24975: Add translation_key method example

This breaks the whole logic. If there is no translation we are displaying the code instead of the non-translated description.

Forget that, that's not correct. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24975 Jonathan Druart <jonathan.druart+koha@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #149954|0 |1 is obsolete| | Attachment #149956|0 |1 is obsolete| | Attachment #149957|0 |1 is obsolete| | --- Comment #114 from Jonathan Druart <jonathan.druart+koha@gmail.com> --- Created attachment 150015 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=150015&action=edit Bug 24975: Simplify and uniform calls to get the translation This patch add a caching mecanism for ItemType objects. We are also caching the result of the image location and the translation key so that we can retrieve from the cache and pass them to the temmplate. We should avoid call to db_t in the controller scripts, and prefer to pass the itemtype object and let the template does what it needs (retrieve the translated description, display the image) Note that the new Koha::Template::Plugin::ItemTypes->GetSorted should certainly be used in other places, for instance in * catalogue/search.pl sub prepare_adv_search_types * opac/opac-search.pl but those 2 occurrences are tricky and we would like to prevent regressions (as much as possible...) A major change is the modification of the prototype of search_compat, I am not sure this patch is updating all the template when the result of the search is passed. Note that Koha::SearchEngine::Elasticsearch::Search could use Koha::ItemTypes->get_from_cache, and certainly other places as well(?) -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24975 --- Comment #116 from Jonathan Druart <jonathan.druart+koha@gmail.com> --- TODO: * Add the entries into l10n_* tables when a new item type is created. * Remove them when the item type is deleted? * What to do when the description of an item type is modified? -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24975 Jonathan Druart <jonathan.druart+koha@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #150033|0 |1 is obsolete| | --- Comment #118 from Jonathan Druart <jonathan.druart+koha@gmail.com> --- Created attachment 150034 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=150034&action=edit Bug 24975: to squash - fix search.pl -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24975 --- Comment #120 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- (In reply to Jonathan Druart from comment #116)

TODO: * Add the entries into l10n_* tables when a new item type is created.

Does this mean there have to be entries even if you don't translate? (sorry, I should maybe know from the rest of the patch/bug)

* Remove them when the item type is deleted?

Removing translations when the itemtype is deleted makes sense to me.

* What to do when the description of an item type is modified?

I think, when an itemtype description is modified, this should not change the translations or remove them. Libraries will take care of it and a typo fix or modification should not cause any changes. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24975 --- Comment #122 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- (In reply to Jonathan Druart from comment #121)

See previous comment, that's not relevant.

(In reply to Katrin Fischer from comment #120)

...

...

* What to do when the description of an item type is modified?

I think, when an itemtype description is modified, this should not change the translations or remove them. Libraries will take care of it and a typo fix or modification should not cause any changes.

This will need to be confirmed however.

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

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24975 Caroline Cyr La Rose <caroline.cyr-la-rose@inlibro.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=35200 -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24975 Koha collecto <koha@collecto.ca> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |koha@collecto.ca -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24975 --- Comment #124 from Julian Maurice <julian.maurice@biblibre.com> --- => bug 38136 -- 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=24975 --- Comment #125 from Jonathan Druart <jonathan.druart@gmail.com> --- (In reply to Jonathan Druart from comment #114)

Created attachment 150015 [details] [review] Bug 24975: Simplify and uniform calls to get the translation

This patch add a caching mecanism for ItemType objects. We are also caching the result of the image location and the translation key so that we can retrieve from the cache and pass them to the temmplate.

We should avoid call to db_t in the controller scripts, and prefer to pass the itemtype object and let the template does what it needs (retrieve the translated description, display the image)

Note that the new Koha::Template::Plugin::ItemTypes->GetSorted should certainly be used in other places, for instance in * catalogue/search.pl sub prepare_adv_search_types * opac/opac-search.pl but those 2 occurrences are tricky and we would like to prevent regressions (as much as possible...)

A major change is the modification of the prototype of search_compat, I am not sure this patch is updating all the template when the result of the search is passed.

Note that Koha::SearchEngine::Elasticsearch::Search could use Koha::ItemTypes->get_from_cache, and certainly other places as well(?)

This patch was quite good. Will move it to a separate bug. -- 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=24975 Julian Maurice <julian.maurice@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #127 from Julian Maurice <julian.maurice@biblibre.com> --- Yes. I'm closing it And I'll also close bug 24977 because it is replaced by bug 38460 *** This bug has been marked as a duplicate of bug 38136 *** -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.