[translations] A couple of untranslated strings in 5.x core
Cog Rusty
cog.rusty at gmail.com
Sat Aug 4 13:25:22 UTC 2007
On 8/3/07, Gabor Hojtsy <gabor at hojtsy.hu> wrote:
> Cog Rusty wrote:
> > On 8/1/07, Cog Rusty <cog.rusty at gmail.com> wrote:
> >> On 8/1/07, Cog Rusty <cog.rusty at gmail.com> wrote:
> >>> On 8/1/07, Konstantin Käfer <kkaefer at gmail.com> wrote:
> >>>> The permission names are generated programatically [[ t("create ".
> >>>> $type ." content") ]] from the content type name. There is no good
> >>>> solution for this problem. You can translate these strings in your
> >>>> Drupal site manually, though.
> >>>>
> >>>> Konstantin
> >>>
> >>> This is different. Not all node types have necessarily an "edit your
> >>> own" permission, so "edit your own" forum topics" is only defined in
> >>> the forum module and in no other module.
> >>
> >> Sorry, I replied too fast. There is "edit own " . $type in node module
> >> but it is not triggered except if a string for $type already exists in
> >> the database. And I was saying that it is possible to do that.
> >
> > To be even clearer, I don't mind that "story" is not translated but at
> > least the surrounding "edit own" should be translatable.
>
> OK, how much core change would it require. The permission names shown
> and stored in the database are the same, just when showing a permission
> it is translated in full. If you'd want a permission name translated and
> then filled with placeholders, that might need heavy API changes and
> database storage modifications. Or am I missing an easy fix?
>
> Gabor
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.
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.
More information about the translations
mailing list