[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 #22 from Julian Maurice <julian.maurice at biblibre.com> ---
(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.