Mal wieder eine frage 😀
Years ago I did a bit of work on Drupal. Once of the slowdowns in their code is that there is a huge number of functions that needed to translate strings in a chosen language. This was a real pain in the A** to be honest, used a lot of cpu/memory.
These days servers are faster but when I look at the code I wonder if there should at least be a default language that does not need to be translated since it already has all the strings in the wanted language.
Why did friendica choose to do it this way too? Imho a small function and database tables per language would be a lot faster.
Curious about the choice. Anyone?
Friendica Support reshared this.
Hypolite Petovan
•The performance footprint of the translation system in #Friendica is actually quite small. The translation itself is performed by humans in the Transifex project page at https://transifex.com/friendica (requires a free account), but then we manually convert the resulting translations into a native PHP array. The translation system then is mostly a simple file loading and array lookups which aren't costly.
Now, the base translation strings are in English, mostly. The problem is that many were written by people whose primary language isn't English. So some people created American English and British English translations to fix the quirks of the base translation strings with regard to the respective local language.
From then on, the base translation strings have become little more than mere identifiers, generally improper to be displayed as is, and enhanced by the translated str
... show moreThe performance footprint of the translation system in #Friendica is actually quite small. The translation itself is performed by humans in the Transifex project page at https://transifex.com/friendica (requires a free account), but then we manually convert the resulting translations into a native PHP array. The translation system then is mostly a simple file loading and array lookups which aren't costly.
Now, the base translation strings are in English, mostly. The problem is that many were written by people whose primary language isn't English. So some people created American English and British English translations to fix the quirks of the base translation strings with regard to the respective local language.
From then on, the base translation strings have become little more than mere identifiers, generally improper to be displayed as is, and enhanced by the translated strings in either English languages.
However, even if these base translation strings could have been used on their own, the performance gain from not having a translated string array to load in memory and look up would be minimal.
Hans Wolters likes this.
Hans Wolters
•Hypolite Petovan
•Hans Wolters
•From my experience it is good to have the translations in a database with some simple queries. So not t("a very long sentence with lots of chars", $lang); since it has a bad performance. I only looked at the code for now and it does look like Drupal a bit.
I think it is doable to find a better solution but that should only be done after xdebug sessions 😀
Hypolite Petovan
•/networkcall, the translation functionDI::l10n()->t()is called around 1,500 times for a total processing time of 12ms. Meanwhile, there are about 150SELECTdatabase queries totaling 72ms.xy@libranet.de likes this.
Hypolite Petovan
•view/langfolder, and if you do, please tell me the performances gains in CPU/memory, I'm curious.