[Koha-bugs] [Bug 29602] We must be nicer with translators

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

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

Victor Grousset/tuxayo <victor at tuxayo.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |victor at tuxayo.net

--- Comment #16 from Victor Grousset/tuxayo <victor at tuxayo.net> ---
Hi, thanks Jonathan for the approach on the SWITCH-es only. It seems to be the
biggest pain in our strings.

Would a good solution be to surround same strings as this patch with t()
instead of <span> ?

The only worry about progressive use of t() is performance, right?
About the discussion on bug 26392 of t("Koha online catalogue") vs
t("opac.homepage.title"), the current approach (1st) doesn't close the door for
the 2nd (token based) since the strings would already be wrapped in calls. So
it's not closing this door assuming the token based approach is chosen in the
end.

So about performance:
Here are results of the benchmarks of bug 15395 on my laptop with a 2012 CPU
(i5-3320M @3.3GHz on mono thread loads)

Summary
Average for 10 strings without translation:     0.0001145 seconds
Average for 100 strings without translation:    0.0001114 seconds
Average for 200 strings without translation:    9.82e-05 seconds
Average for 500 strings without translation:    0.0001932 seconds
Average for 10 strings with translation:        0.0014077 seconds
Average for 100 strings with translation:       0.0076227 seconds
Average for 200 strings with translation:       0.0120828 seconds
Average for 500 strings with translation:       0.0306117 seconds

The same PC has a median time of 0.350 sec to generate the untranslated HTML
for this page:
/cgi-bin/koha/admin/preferences.pl?tab=circulation
(using browser network devtools)
There are 200 sysprefs shown there. So it's surely one the of the pages with
the most translatable strings we have.
(Well, searching "a" in sysprefs yields 740 of them ^^" in more than 0.950 sec)

git grep "circulation.pref#"  misc/translator/po/bg-Cyrl-pref.po | wc -l
=> 633
So it seems we have 633 strings in our circulation sysprefs.
if 500 strings took 0.031 sec in the benchmark
then 633 strings => 0.039 sec
0.039 is 11% of 0.350
So we should expected that using t() on all string on this page should add 11%
response time to 0.350 sec.

Would there be another case where the overhead could be the more perceptible
than this? (it's not really perceptible)
Is the methodology valid?

If so then we shouldn't expect issues about performance.

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