Node type information to be translatable

Peter, at this point, afaik, I cannot find a comprehensive methodology. The most well defined is by nedjo as he outlined here:
http://drupal.org/node/304002

There seems to have been consensus or common knowledge at one point by a few core developers, to not use t() for any text not written in code. That might have been sufficient in earlier drupal versions where there was either text in code, or user input text. Thus this excerpt from common.inc:

 * However tempting it is, custom data from user input or other non-code
 * sources should not be passed through t(). Doing so leads to the following
 * problems and errors:
 *  - The t() system doesn't support updates to existing strings. When user
 *    data is updated, the next time it's passed through t() a new record is
 *    created instead of an update. The database bloats over time and any
 *    existing translations are orphaned with each update.
 *  - The t() system assumes any data it receives is in English. User data may
 *    be in another language, producing translation errors.
 *  - The "Built-in interface" text group in the locale system is used to
 *    produce translations for storage in .po files. When non-code strings are
 *    passed through t(), they are added to this text group, which is rendered
 *    inaccurate since it is a mix of actual interface strings and various user
 *    input strings of uncertain origin.
 *
 * Incorrect:
 * @code
 *   $item = item_load();
 *   $output .= check_plain(t($item['title']));
 * @endcode
 *
 * Instead, translation of these data can be done through the locale system,
 * either directly or through helper functions provided by contributed
 * modules.
 * @see hook_locale()

At this point, though with the abundance of admin defined 'user input' strings, such as the names of content types, it doesn't quite fit into the category of 'user input' strings.

I would love to see the tt() function in core at some point, so that each module does not have to define its own tt()

I have submitted similar patches to a bunch of modules, and one of the patches which have been committed is by Jose Reyero, and he added a book page as well:
http://drupal.org/node/609364

I had a sort of similar idea in the user relationships issue http://drupal.org/node/471546

/**
 * provide a degrade path for function tt found in module i18nstrings
 */
if (! module_exists('i18nstrings')) {
  function tt($name, $string, $langcode = NULL, $update = FALSE) {
    return t($string, array(), $langcode);
  }
}

however after discussion with Kars-T in the issue, and Scott Reynolds on IRC, Scott explained to me, that my methodology might not be secure, as each module might implement the above code, and if another module implemented an insecure or poorly written tt(), all modules calling tt() would suffer.

Your code looks better, but it also does not guarantee that the tt() function comes from i18nstrings, and may have been defined by another module.

Now the chances of that happening may be small and insignificant, especially for developers like us who are in control of the code, but I'm just throwing stuff out there.

Audrey

true, look, I really don't know what is the best way.

Whatever, is done on the contrib module level will be not as clean, because this should really be in core. Also, this should really be discussed on a wider scale.

I know that whatever you choose to do will be more than fine and excellent.