https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24975
--- Comment #22 from Julian Maurice <[email protected]> --- (In reply to Martin Renvoize from comment #21) > (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. Sorry for the confusion... where did I lost you exactly ? :) Just to be clear, I suggest description based keys. > 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? But what if the description of 245a for FW2 is different from the 245a of default framework ? Won't we have a wrong translation ? -- 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/
