[development] Translating database fields

[Gábor Hojtsy]

Didn't you ask to follow up on the issue? :D

On Wed, Sep 23, 2009 at 3:48 PM, Jeremy Andrews <lists at kerneltrap.org> 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