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.