https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29602
Victor Grousset/tuxayo <vic...@tuxayo.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |vic...@tuxayo.net --- Comment #16 from Victor Grousset/tuxayo <vic...@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. _______________________________________________ Koha-bugs mailing list Koha-bugs@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/