User defined strings translation [#133745]

We need some generic mechanism to translate user defined strings. So here's a summary of related posts and options to start working on this feature.
The current localization system seems not to be a good solution for this as Gabor pointed out in his post String translation: why using t() for user specified text is evil?
Then we have this other post, outlining some idea, How to translate web configurable strings. A proposal.. This concept is currently in the works and there's some proof of concept of this in i18n's package i18nstrings.module, which implements a function like

function tt($stringid, $default_text, $language)

Also, localizer module has a solution that is more object-oriented instead of string-oriented, using a table like this:

CREATE TABLE  `localizertranslation` (
  `tid` int(10) unsigned NOT NULL auto_increment,
  `object_key` varchar(100) NOT NULL,
  `object_name` varchar(100) NOT NULL,
  `object_field` varchar(100) NOT NULL,
  `translation` text NOT NULL,
  `locale` varchar(10) NOT NULL,
  PRIMARY KEY  (`tid`),
  UNIQUE KEY `localizertranslation_idx1` (`object_key`,`object_name`,`object_field`,`locale`)
)

So, building on these latest two examples and what we have so far, what we need IMHO is some mix of all this:

Some simple to use api function, like the 'tt' idea
Some storage that also supports some object related data, more like localizer's solution
A single interface to translate all data, like current locale module string management pages. The rationale for this is that a 'translator' role is completely different to the 'administrator' role so we should have translators using a different interface than the site administration pages, ideally some uniform one for all these strings.
Keep in mind for whatever we do that this kind of thing may have some important performance impact that we should try to avoid for single language sites, so following the example of locale's t() function that has a negligible impact for single language English sites may not be a bad option.

The outstanding examples of this kind of strings that need translation currently in Drupal core are maybe user profile fields and content type names, help texts and descriptions, so I think we could get started with these two things maybe extending it later for some more strings.

So, comments, ideas, patches :-), anyone?

Comments

Comment #1

Roberto Gerola CreditAttribution: Roberto Gerola commented 17 April 2007 at 12:34

Your $stringid is a sort of key or the string to transalte, like in t() function ?

Comment #2

Roberto Gerola CreditAttribution: Roberto Gerola commented 17 April 2007 at 12:47

i would like that we agree on a formal definition of this function, so that we can begin
to use it starting from now and we can also inform the contrib modules developers,
so that they can begin to use it in their modules.

Such a function should be, I think, only declared in Drupal core and then implemented
by external modules. Like i18n_get_lang.

i like your proposal of tt as name, its more compact than tobject.

If we declare it as tt($stringid, $language, $default_text=NULL)
I could port my call from tobject to tt, i think, if $stringid could contains
something like (for example) : taxonomy-term-title-32 or taxonomy-vocabulary-description-12
(where the number is the id of the record table).

What do you think ?

Comment #3

Jose Reyero CreditAttribution: Jose Reyero commented 18 April 2007 at 12:21

Yes, I think something like that makes sense. Abt taxonomy, maybe we can add some specific mechanism for it, but if not, we can also use this mechanism eventually.

Maybe string ids could be something like
taxonomy_term:title:32
taxonomy_vocabulary:description:12
content_type:description:story
or
user_welcome_email
node_help:admin/content/search

By using some standard separator, we can use more than one search fields (object, name, id), while keeping the 'tt' function simple.
Also, for performance reasons, this function will need some smart caching, like i.e., pre-fetching all 'taxonomy_term:title' objects when the first one is requested.
By adding some logic into the function we can also act differently for known string types.

Another performance issue, is using a default value, so adapting existing code will be easy and it will run fast when the site is single language because we don't need to add language conditions and fields to every query.

Comment #4

Roberto Gerola CreditAttribution: Roberto Gerola commented 18 April 2007 at 17:25

> taxonomy_term:title:32
> taxonomy_vocabulary:description:12
> content_type:description:story

Right, also content-type.
For me is ok also ":" as sperator character.
We only should be sure that it isn't use in the fields that are composing
the key.

I think that the key should be composed by three sub-keys :
- type
- unique identifier
- field

For example for a variable :

variable:variable_name:title
variable:variable_name:description

Perhaps the order for menu and taxonomy should be different from what already proposed:

menu_item:12:title
menu_item:12:description

taxonomy_term:35:title
taxonomy_term:35:description

Most of the times you need to translate all the fields of an object (i mean, title and description for example)
So you make a call similar to this :
1. tt('menu_item:12:title').
2. First call for the object menu_item:12 -> retrieve all the fields from the db a cache in static array
3. Returns the title
4. tt('menu_item:12:description')
5. No db call. Picks the description from the cache and returns the description

>this function will need some smart caching, like i.e., pre-fetching all 'taxonomy_term:title' objects when the first one is requested
Yes. i have already something of similar

> Another performance issue, is using a default value
Yes, you are right, it is necessary for the users that are not using multilingual
support and to avoid useless db calls.

Perhaps should we make the language parameter optional ?
The current language is already presented in session :

function tt($key, $defaultvalue, $language=NUUL)