https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24975
Jonathan Druart <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Failed QA --- Comment #16 from Jonathan Druart <[email protected]> --- 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. _______________________________________________ Koha-bugs mailing list [email protected] https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
