[translations] A couple of untranslated strings in 5.x core

[Cog Rusty]

On 8/4/07, Gabor Hojtsy <gabor at hojtsy.hu> wrote:
> Cog Rusty wrote:
> > I agree that it is not only hard but also ugly for translations to
> > have those strings split and constant, because it would not allow
> > using correct grammar.
> >
> > An easy solutions which would work for imported types, at least for
> > the permissions page is this: Whenever a type is inserted in the
> > database it could be always accompanied by a dummy function containing
> > t() strings, such as:
> >
> > system.install:
> > --------------------
> > function story_strings() {
> > t('create story content');
> > t('edit story content');
> > t('edit own story content');
> > return 0;
> > }
> >
> > These strings seem to work if they get into the po file. Not sure how,
> > probably it has to do with the $perms[] = 'edit own '. $name
> > .'content'; line in node.module.
>
> These kinds of special treatments are already in place for core stuff,
> but contributions are not covered for sure.
>
> > So, potx would catch them, and as soon they are in the translation
> > they seem to work. Perhaps this could be further standardized.
> >
> > For the user-defined types, the problem of the untranslated
> > surrounding text of the permissions remains unsolved, so this is not a
> > thorough solution. And a solution will be needed when the rest of the
> > core node types move out of the code as well.
> >
> > An idea for this is an additional tab in language setup which would
> > contain node type names and their related strings. This would probably
> > need some standardization of the language information of a node type.
>
> Lots of user defined stuff is still not translatable in Drupal 6 (menus,
> taxonomy, node types, aggregator stuff, profile fields and so on). These
> include the user defined content type permission names (altough
> admittedly we did not think about this as a serious case, it has its own
> place). These could have solutions in Drupal 7 soonest. In the meantime,
> contributed modules need to solve these problems.
>
> Gabor

Ok then... For now, would the release packaging system accept to
package an "other.po" file which does not have a corresponding
"other.pot", so that a translation team can solve some of the problems
which can be solved in this way? Preferably into the main po file, to
keep the import operation simple for the user. Or should I file an
issue?