https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38136
--- Comment #2 from Julian Maurice <[email protected]> --- 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. _______________________________________________ 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/
