[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 #21 from Martin Renvoize <martin.renvoize at ptfs-europe.com> ---
(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.

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?

I need to look at the code again to really get to grips with that suggestion so
please feel free to cast it aside if it's non-sense.

-- 
You are receiving this mail because:
You are watching all bug changes.