Übersetzungen in Drupal sind so eine Sache und es gibt diverse Funktionen. Ich habe ja selber nicht gewusst, dass es neben t() auch noch tt() gibt und ich muss sagen tt() ist genial 🙂 Hier mal eine kleine Erklärung, welche ich dazu gefunden habe… sehr plausibel erklärt, warum t() nicht überall verwendet werden soll/darf.
Im folgenden ein Auszug aus der Drupal Mailing Liste.
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
Im Detail würde es dann so aussehen:
<!–?php
function mymodule_locale($op = 'groups', $group = NULL) {
switch ($op) {
case 'groups': return array('mygroup' => t('My Group')); }
}
function mymodule_somefunction() {
//…
tt('mygroup:the_location', $string);
//… }
?>
Weitere Ressourcen: