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