[Koha-bugs] [Bug 24975] Refactor database translations

[bugzilla-daemon at bugs.koha-community.org]

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24975

--- Comment #30 from Martin Renvoize <martin.renvoize at 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.