[development] Translating database fields

Jeremy Andrews lists at kerneltrap.org
Wed Sep 23 13:48:59 UTC 2009

On Wed, 2009-09-23 at 15:17 +0200, Gábor Hojtsy wrote:
> On Wed, Sep 23, 2009 at 3:10 PM, Ken Winters <kwinters at coalmarch.com> wrote:
> > Hmm, tt() doesn't seem very developer friendly.
> >
> > If you're developing a module that is translatable, you can't realistically
> > require i18n, and checking for the module / function in 100 places would be
> > unpleasant (assuming that it is normally used the same way as t() in the
> > code).
> >
> > Other than making a wrapper function in the module that passes to tt() if it
> > exists, do you have any suggestions to make this cleaner?
> You definitely should not require i18n if your module just provides
> optional translation support. You'll need to define tt() yourself
> conditionally I guess. There is no way in Drupal (I know of) to
> invoke_if_exists_otherwise_return_the_args_to_me(), even
> module_invoke() skips returning you stuff if the hook was not defined.

So you're suggesting that currently the "correct" way to make text
stored in the database translatable is to use tt()?  Why is tt() more
correct than t()?  Isn't tt() going to end up orphaning the translations
if the database text gets changed, the same as t()?  Doesn't tt() still
have the same problem when the database text gets changes to non-english
language?  Is what this is really solving is avoiding a misnomer,
avoiding putting "database defined text" into the "code defined text"
locale group?

What about Mike's suggestion to create a support.locale.php file whose
sole purpose is to expose default database strings?  Is that practice
frowned upon?  At this time it seems like the simplest solution, though
if someone decides to add their own custom states and/or priorities they
won't be translatable without also hacking the support.locale.php file.
How is this solved?  What is the proper way to be sure that any text
stored in the database is exposed to the translation system, even text
that may be added later by the user?

Sorry, it seems I'm still confused as to the proper solution.


More information about the development mailing list