Didn't you ask to follow up on the issue? :D On Wed, Sep 23, 2009 at 3:48 PM, Jeremy Andrews <[email protected]> wrote: > So you're suggesting that currently the "correct" way to make text > stored in the database translatable is to use tt()?
I don't know of a better way. We tried to get people to review approaches for this in core for Drupal 6, but nobody showed up at that time, so no such solution got into Drupal 6 consequently. Given lack of interest it did not get into Drupal 7 either as it seems. > 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()? I did not look into the current implementation (tt() is using some abstractions :), but the idea is that unlike t(), you provide tt() with more detailed meta information on the "location" of the string, so you tell it that "this is status label number 3 from mymodule", so when the status label 3 is updated, the string to translate can be updated without leaving orphan strings behind. With t() you lack this metainformation on the string (even in Drupal 7, unless you abuse the context system to hell which is however not supposed to used in this granularity given that it makes translation sharing impossible). > Doesn't tt() still > have the same problem when the database text gets changes to non-english > language? It segments this problem to at least the non-default textgroup. There is obviously no way we can tell whether a string is English or not and it is pointless to keep trying to get users to enter English text at all times on a localized site. That would be crazy. > Is what this is really solving is avoiding a misnomer, > avoiding putting "database defined text" into the "code defined text" > locale group? The Drupal 6 textgroup system lets you segment strings and as implemented with tt(), it also lets you use the location information to update and look up strings based on the objects they relate to. These are all unavailable if you use t(). Also, t() has some other niceties, like caching short strings for easy lookup. Now if we'd tell people to translate things like taxonomy with t() itself, then you can easily end up with a huge cache of short strings (including all your taxonomy terms) loaded up on every page. Pretty useless and resource consuming. We could say you might still somewhat safely use t() in some user input cases, but it would still go with the leftover stale strings, mixing up the English and non-English text in the database and on the translation UI, etc. Textgroups and tt() exploiting them with the location information attempts to solve these problems as well as not letting user input go to the t() cache loaded on every page. which is designed with the UI text mass in mind. > 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? As said, while technically t() might look like it solves your problems, I'd advise against it. See above. Gábor
