[development] t() function concept/bug/patch proposal

[Gabor Hojtsy]

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