On Wed, 2009-09-23 at 15:17 +0200, Gábor Hojtsy wrote: > On Wed, Sep 23, 2009 at 3:10 PM, Ken Winters <[email protected]> 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. Thanks, -Jeremy
