[Koha-bugs] [Bug 24975] Refactor database translations
bugzilla-daemon at bugs.koha-community.org
bugzilla-daemon at bugs.koha-community.org
Fri Apr 10 14:33:46 CEST 2020
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24975
Jonathan Druart <jonathan.druart at bugs.koha-community.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|Signed Off |Failed QA
--- Comment #16 from Jonathan Druart <jonathan.druart at 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.
More information about the Koha-bugs
mailing list