[development] t() function concept/bug/patch proposal
gabor at hojtsy.hu
Thu Sep 7 19:13:34 UTC 2006
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
- 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:
Jose also has a session on i18n in Brussels. Go discuss! Unfortunately I
will not be able to be there.
More information about the development