On 8/3/07, Gabor Hojtsy gabor@hojtsy.hu wrote:
Cog Rusty wrote:
On 8/1/07, Cog Rusty cog.rusty@gmail.com wrote:
On 8/1/07, Cog Rusty cog.rusty@gmail.com wrote:
On 8/1/07, Konstantin Käfer kkaefer@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.