[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 #35 from Julian Maurice <julian.maurice at biblibre.com> ---
(In reply to Martin Renvoize from comment #28)
> What I'm also tempted to do is add a standardly named accessor be to objects
> with translatable fields.. ->translation_key which would produce the right
> key from the internal fields behind the scenes. So for itemtype it simply
> passes through itemtype, but for a it might pass $code_$interface for
> example.

That means Koha::Object(s) should be aware of the interface (opac/staff) ? :/

(In reply to Martin Renvoize from comment #34)
> My point is.. I've tried to make it flexible enough without introducing too
> much additional overhead/code complexity here. I suggest we should not
> second guess the level of translation requirements/granularity of different
> components here but rather defer that to each bug introducing additional
> translation options.
We have the same goal, just different opinions on how to achieve that. If we do
it right from the beginning, making more kind of objects translatable will be
easier. I think it's worth taking some time to think about it.

By using codes as translation key, it can work for MARC frameworks too, but it
will require to translate the same strings multiple times. To avoid that, we
would need to implement some kind of fallback mechanism.
By using descriptions as translation key, there is no need for fallback. Every
string have to be translated only once. However it doesn't allow to translate
the same string in different ways (like in comment 31). Doing that will also
require a fallback mechanism.

So, do we want to use a code as key (eg. "245a") and refine with other codes
("FW2"),
or do we want to use a description as key (eg. "Title") and refine with other
codes ("FW2", "245a") ?
I'd say the fallback for a description-based key is more likely to be accurate
("Kunto" is not very different in meaning from "Tila"), whereas a fallback for
a code-based key can be simply wrong if descriptions are different.

Now that I think about it, this refinement system could also include the group
("itemtype", "framework", ...) so we'd have to translate "Title" only once, and
it would be translated everywhere the same way, except if one add a different
translation for [framework, FW2, 245a] for instance.

That being said, I recognize that frameworks are a particular case, and it may
not be worth it to add all these translation features just for that. But having
a separate translation system for frameworks is not ideal either... It would be
simpler if all frameworks shared their descriptions :)

BTW, I really like the idea of "fuzzy" you've added

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