t() function concept/bug/patch proposal
there have been enough recent posts referring to the t() function that I'd like to draw attention to my previous bug report/patch again: http://drupal.org/node/74181 In summary - the current concept of t() is officially that it only supports fixed, module defined strings, not 'user-defined' (which means anything else, e.g., a title, a taxonomy term, etc.). In particular, when given an empty string as an argument, it wastes an expensive sql lookup (and really bombs if those are in an init function before the db caching is started). Nevertheless, I see a number of recent posts that are using t() for lookups of arbitrary user strings, a kind of hopeful translation mechanism, instead of the rigorous one originally intended for it. I'd like to propose an official change to the concept of the t() function that it accepts any arguments, including dynamically generated ones, since that seems to be the common usage, and in that light accept the simple patch proposed above, all in the name of simple performance for a wide range of sites/modules. -- Alan Dixon, Web Developer http://alan.g.dixon.googlepages.com/
In summary - the current concept of t() is officially that it only supports fixed, module defined strings, not 'user-defined' (which means anything else, e.g., a title, a taxonomy term, etc.). In particular, when given an empty string as an argument, it wastes an expensive sql lookup (and really bombs if those are in an init function before the db caching is started).
i support that ... one way to move this along is to make a patch (it is really simple) and get it reviewed and into the cvs commit queue. then a decision is needed. otherwise, you are seeking a policy change with no effects and that merits little time.
On Thu, 7 Sep 2006, Moshe Weitzman wrote:
In summary - the current concept of t() is officially that it only supports fixed, module defined strings, not 'user-defined' (which means anything else, e.g., a title, a taxonomy term, etc.). In particular, when given an empty string as an argument, it wastes an expensive sql lookup (and really bombs if those are in an init function before the db caching is started).
i support that ... one way to move this along is to make a patch (it is really simple) and get it reviewed and into the cvs commit queue. then a decision is needed. otherwise, you are seeking a policy change with no effects and that merits little time.
Where is the line if you support t()-ing user specified content? Long descriptions? Site missions? Node bodies? The problem with extending t() this way is that we should have different interfaces and APIs directly for content translation in Drupal. If you modify your site mission (say fix up some grammar), you have this workflow to change other language versions (or pair them again with your new site mission, if they don't need fixing): - modify site mission on settings interface - go to the locale admin page - click on search local task - search for the old mission text (and keep this tab open in your browser) - search for the new mission text in another tab, and copy over all translations for all languages one by one manually, modify them as needed - save your new translation by submitting - remove your old mission translations manually Moshe, is this what you support? The above reasoning presented by the start of this thread is about taxonomy term descriptions. The same issue as with site missions, just that you have a lot more discriptions and lot more possibility to change them (ie. more people have permission to do so, not just the super admins as with site missions). If the interface is not laying itself for the task, maybe we could think that the db storage is right for this kind of solution. Well, as far as I see, it is not. Variables like the mission statement are preloaded to Drupal for quick access. You don't know which translations are variables in the database, so you need to first fetch 'original' variables, then t() them all one-by-one (nice DB hammering), then store them in memory. Same for taxonomy descriptions. It is also not desirable to translate these texts in PO files, and especially not mix interface strings with site content. IMHO there are a lot of conceptual and performance problems with allowing t() usage with arbitrary user defined content. The fact that there is no solution in core for this task and t() seems to be an easy fit (at first sight without thinking about it deeply) does not mean we should do this. Unfortunately there was very little interest in our i18n2core effort, which is headed by Jose, but it does try to offer "better" (depends on how you evaluate them) solutions for these problems. Look into those, discuss, improve, suggest better ways. IMHO we should focus on that instead of pushing a user interface and database nightmare on our users throat. Issue is here, and will obviously have merit once HEAD is open for development: http://drupal.org/node/77866 Jose also has a session on i18n in Brussels. Go discuss! Unfortunately I will not be able to be there. Gabor
Moshe, is this what you support?
well, i was too vague. i support the strict issue only for now - "performance: exit t() if $string is empty". gabor makes some good points about the problems associated with overuse/misuse of t(). still, the workflow he describes is better than simply being unable to localize taxonomy terms, for example. sometimes sucky is better than impossible. thanks for the link to the i18n patch. i didn't know about it.
On Thu, 7 Sep 2006, Moshe Weitzman wrote:
Moshe, is this what you support?
well, i was too vague. i support the strict issue only for now - "performance: exit t() if $string is empty".
gabor makes some good points about the problems associated with overuse/misuse of t(). still, the workflow he describes is better than simply being unable to localize taxonomy terms, for example. sometimes sucky is better than impossible.
thanks for the link to the i18n patch. i didn't know about it.
i18n (the contrib module) is a lot less sucky already without that patch, taxonomy_dhtml (which was mentioned as a module using t($term)) should collaborate with that module IMHO. Gabor
Moshe Weitzman wrote:
In summary - the current concept of t() is officially that it only supports fixed, module defined strings, not 'user-defined' (which means anything else, e.g., a title, a taxonomy term, etc.). In particular, when given an empty string as an argument, it wastes an expensive sql lookup (and really bombs if those are in an init function before the db caching is started).
i support that ...
What? I didn't see a proposal. :p
one way to move this along is to make a patch (it is really simple) and get it reviewed and into the cvs commit queue. then a decision is needed. otherwise, you are seeking a policy change with no effects and that merits little time.
If you only want to exit t() if there is no argument, you have my ok, even if I think that this case shouldn't happen. If you want to use t() for user supplied strings, then not. t() has already not the best performance. Drupal comes with 1200 strings nowadays. All strings below 75 characters are stored in the locale cache. That is quite a bit of data. For a rather incomplete de cache I have 130kB which is loaded per page view. Cheers, Gerhard
If you want to use t() for user supplied strings, then not. t() has
Hi, what do you propose? What is *NOW* best way to handle multilanguage sites with taxonomies? Jakub P.S.: I originally proposed this patch during development of site with 6 languages. It's based on 4.6 and takes 1-1.5s to load
Jakub, have you looked at i18n? It has a taxonomy translation feature. The approach taken there (or a refined or redone one) will get into core sooner or later. Most probably t() will not get extended this way. The fact that you did not experience performance problems might be a single case. Do you have a few hundred taxonomy terms, like if you start to offer free tagging, or tagging based on products or anything similar? Gabor On Thu, 7 Sep 2006, Jakub Suchy wrote:
If you want to use t() for user supplied strings, then not. t() has
Hi, what do you propose? What is *NOW* best way to handle multilanguage sites with taxonomies?
Jakub P.S.: I originally proposed this patch during development of site with 6 languages. It's based on 4.6 and takes 1-1.5s to load
Thanks for your feedbacks. I've followed up on the issue with a simple patch to locale.module, intended to rescue drupal's performance in case of improper or unexpected use of t(), with no change to core policy intended. On 9/7/06, Gabor Hojtsy <gabor@hojtsy.hu> wrote:
Jakub, have you looked at i18n? It has a taxonomy translation feature. The approach taken there (or a refined or redone one) will get into core sooner or later. Most probably t() will not get extended this way.
Taxonomy translation is difficult - this feature works for some use cases, but not all, in my experience.
The fact that you did not experience performance problems might be a single case. Do you have a few hundred taxonomy terms, like if you start to offer free tagging, or tagging based on products or anything similar?
No, I think it was a case of a number of issues getting combined to cause the problem to become noticeable. I don't think everyone will have such drastic performance problems, but I imagine it could happen relatively easily again, and I think the patch will alleviate the worst cases. -- Alan Dixon, Web Developer http://alan.g.dixon.googlepages.com/
participants (5)
-
Alan Dixon -
Gabor Hojtsy -
Gerhard Killesreiter -
Jakub Suchy -
Moshe Weitzman