A couple of untranslated strings in 5.x core
Hello people, I've noticed a couple of untranslated strings in Drupal 5.1. Here's the procedure I've followed: 1) Installed a fresh Drupal 5.1. 2) Enabled all modules. 3) Added the greek language as a secondary language in Localization settings page. 4) Imported the translated .po file for greek [the translation is 100% complete, the Localization settings page reports 2431/2431 (100%)]. 5) Changed the site's default language to greek. In the navigation menu in left, under Create content, the names and the descriptions for the Page and Story content types are untranslated and remain in English. Is this a bug? Should I open an issue about this? -- # Vasileios Lourdas, # Informatics Engineer, Thessaloniki (Greece) # http://www.lourdas.name
This is a known issue. Here is why this happens: On installation time, the content types are created and insert into the database (starting with Drupal 5, we don't have hardcoded content types as default setting). Unfortunately, the language pack was not installed on install time, so the translation was not available. This will change in Drupal 6. Konstantin Käfer On 17.07.2007, at 00:06, Vasileios Lourdas wrote:
Hello people,
I've noticed a couple of untranslated strings in Drupal 5.1. Here's the procedure I've followed:
1) Installed a fresh Drupal 5.1. 2) Enabled all modules. 3) Added the greek language as a secondary language in Localization settings page. 4) Imported the translated .po file for greek [the translation is 100% complete, the Localization settings page reports 2431/2431 (100%)]. 5) Changed the site's default language to greek.
In the navigation menu in left, under Create content, the names and the descriptions for the Page and Story content types are untranslated and remain in English.
Is this a bug? Should I open an issue about this? -- # Vasileios Lourdas, # Informatics Engineer, Thessaloniki (Greece) # http://www.lourdas.name _______________________________________________ translations mailing list translations@drupal.org http://lists.drupal.org/mailman/listinfo/translations
On Tuesday 17 July 2007 01:17:22 Konstantin Käfer wrote:
This is a known issue.
Here is why this happens:
On installation time, the content types are created and insert into the database (starting with Drupal 5, we don't have hardcoded content types as default setting). Unfortunately, the language pack was not installed on install time, so the translation was not available.
This will change in Drupal 6.
Konstantin Käfer
Thanks for your reply. Is there a workaround for this? -- # Vasileios Lourdas, # Informatics Engineer, Thessaloniki (Greece) # http://www.lourdas.name
On 17.07.2007, at 00:18, Vasileios Lourdas wrote:
Is there a workaround for this?
There are two ways: - Install Drupal directly in your language. For this to work, you need to copy the file "installer.po" into /profiles/default and rename it to "el.po" (or whatever your language code is) - Rename the content types manually at Administer > Content management > Content types Konstantin Käfer – http://kkaefer.com/
Konstantin Käfer wrote:
This is a known issue.
Here is why this happens:
On installation time, the content types are created and insert into the database (starting with Drupal 5, we don't have hardcoded content types as default setting). Unfortunately, the language pack was not installed on install time, so the translation was not available.
This will change in Drupal 6.
To be precize, the behavior is very similar in Drupal 6, just that it starts off with a screen asking the user to download a language pack, if English is not the desired target language. Content type names are not translatable beyond the installer still (unfortunately). Gabor
On Tuesday 17 July 2007 09:08:17 Gabor Hojtsy wrote:
if English is not the desired target language. Content type names are not translatable beyond the installer still (unfortunately).
Gabor
Why is this an issue? Is it some kind of a technical issue? Surely, I'm not familiar with the inner workings of Drupal, but this behaviour seems a bit strange to me. Ok, so let's say, that I start the Drupal installation using another language pack. Then, would the opposite apply, that is, will I have these two content types translated in my language and untranslated in English? -- # Vasileios Lourdas, # Informatics Engineer, Thessaloniki (Greece) # http://www.lourdas.name
Vasileios Lourdas wrote:
On Tuesday 17 July 2007 09:08:17 Gabor Hojtsy wrote:
if English is not the desired target language. Content type names are not translatable beyond the installer still (unfortunately).
Why is this an issue? Is it some kind of a technical issue? Surely, I'm not familiar with the inner workings of Drupal, but this behaviour seems a bit strange to me.
Ok, so let's say, that I start the Drupal installation using another language pack. Then, would the opposite apply, that is, will I have these two content types translated in my language and untranslated in English?
Content type names, site settings (site name, slogan, footer text, etc), aggregator categories and feed titles, profile field labels, user defined menus and taxonomy terms are all single-language objects in Drupal 6 still. This is due to technical issues, which are not yet solved (there was not enough manpower working on this task quite unfortunately). We have gone a long way in Drupal 6, but it is not yet a complete multilingual system. What is translatable with built-in functions: - built-in menu items (provided by modules) - all of the built in interface (help texts, the installer, forms, etc) - every string in JavaScript code - log messages - content (posts) You can notice that only the posts are user defined data here, while all the elements I listed above as being single-language are user defined. You will need to use some contributed module with Drupal 6 too (like i18n or localizer) to get these translated. Drupal 5 does not provide JavaScript translation, proper log message localization and content translation. Gabor
Hello, Following this thread, although it's a bit different issue this time, there are six strings that do not get translated after importing a language gettext file (e.g. Greek as in my case). These strings are: 1) create page content 2) create story content 3) edit own page content 4) edit own story content 5) edit page content 6) edit story content which are role permissions and appear in the administration pages. These strings *do not* appear in the template files (.pot), however they appear in the Manage strings section of the Localization settings page (if you search using the right parameters). Since the Manage strings section provides me the ability to translate them in my language, I tried manually to insert those strings to a new .po file and translated them using my regular gettext file editor. Then I imported the merged file from all translations by all core modules and of course this procedure worked. The above make me wonder if there is a bug in Drupal 5.x core (I haven't checked 6-dev, though I will do so) that prevents potx from extracting these specific six strings to the template files, or there's something else that needs a bit of looking into. -- # Vasileios Lourdas, # Informatics Engineer, Thessaloniki (Greece) # http://www.lourdas.name
On 8/1/07, Vasileios Lourdas <lourdas_v@yahoo.gr> wrote:
Hello,
Following this thread, although it's a bit different issue this time, there are six strings that do not get translated after importing a language gettext file (e.g. Greek as in my case). These strings are:
1) create page content 2) create story content 3) edit own page content 4) edit own story content 5) edit page content 6) edit story content
which are role permissions and appear in the administration pages. These strings *do not* appear in the template files (.pot), however they appear in the Manage strings section of the Localization settings page (if you search using the right parameters).
Since the Manage strings section provides me the ability to translate them in my language, I tried manually to insert those strings to a new .po file and translated them using my regular gettext file editor. Then I imported the merged file from all translations by all core modules and of course this procedure worked.
The above make me wonder if there is a bug in Drupal 5.x core (I haven't checked 6-dev, though I will do so) that prevents potx from extracting these specific six strings to the template files, or there's something else that needs a bit of looking into.
I wanted to add that unlike the general "story" and "page" problem, it seems that maybe this one can be solved, because they are translated if a translation exists.. The forum, blog and book modules contain their corresponding strings, so perhaps these strings could be added in system.install where these node types are defined, in dummy t() code, so that potx can get them.
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 On 31.07.2007, at 23:18, Vasileios Lourdas wrote:
Hello,
Following this thread, although it's a bit different issue this time, there are six strings that do not get translated after importing a language gettext file (e.g. Greek as in my case). These strings are:
1) create page content 2) create story content 3) edit own page content 4) edit own story content 5) edit page content 6) edit story content
which are role permissions and appear in the administration pages. These strings *do not* appear in the template files (.pot), however they appear in the Manage strings section of the Localization settings page (if you search using the right parameters).
Since the Manage strings section provides me the ability to translate them in my language, I tried manually to insert those strings to a new .po file and translated them using my regular gettext file editor. Then I imported the merged file from all translations by all core modules and of course this procedure worked.
The above make me wonder if there is a bug in Drupal 5.x core (I haven't checked 6-dev, though I will do so) that prevents potx from extracting these specific six strings to the template files, or there's something else that needs a bit of looking into. -- # Vasileios Lourdas, # Informatics Engineer, Thessaloniki (Greece) # http://www.lourdas.name _______________________________________________ translations mailing list translations@drupal.org http://lists.drupal.org/mailman/listinfo/translations
Konstantin Käfer — http://kkaefer.com/
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.
On 31.07.2007, at 23:18, Vasileios Lourdas wrote:
Hello,
Following this thread, although it's a bit different issue this time, there are six strings that do not get translated after importing a language gettext file (e.g. Greek as in my case). These strings are:
1) create page content 2) create story content 3) edit own page content 4) edit own story content 5) edit page content 6) edit story content
which are role permissions and appear in the administration pages. These strings *do not* appear in the template files (.pot), however they appear in the Manage strings section of the Localization settings page (if you search using the right parameters).
Since the Manage strings section provides me the ability to translate them in my language, I tried manually to insert those strings to a new .po file and translated them using my regular gettext file editor. Then I imported the merged file from all translations by all core modules and of course this procedure worked.
The above make me wonder if there is a bug in Drupal 5.x core (I haven't checked 6-dev, though I will do so) that prevents potx from extracting these specific six strings to the template files, or there's something else that needs a bit of looking into. -- # Vasileios Lourdas, # Informatics Engineer, Thessaloniki (Greece) # http://www.lourdas.name _______________________________________________ translations mailing list translations@drupal.org http://lists.drupal.org/mailman/listinfo/translations
Konstantin Käfer — http://kkaefer.com/
_______________________________________________ translations mailing list translations@drupal.org http://lists.drupal.org/mailman/listinfo/translations
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.
On 31.07.2007, at 23:18, Vasileios Lourdas wrote:
Hello,
Following this thread, although it's a bit different issue this time, there are six strings that do not get translated after importing a language gettext file (e.g. Greek as in my case). These strings are:
1) create page content 2) create story content 3) edit own page content 4) edit own story content 5) edit page content 6) edit story content
which are role permissions and appear in the administration pages. These strings *do not* appear in the template files (.pot), however they appear in the Manage strings section of the Localization settings page (if you search using the right parameters).
Since the Manage strings section provides me the ability to translate them in my language, I tried manually to insert those strings to a new .po file and translated them using my regular gettext file editor. Then I imported the merged file from all translations by all core modules and of course this procedure worked.
The above make me wonder if there is a bug in Drupal 5.x core (I haven't checked 6-dev, though I will do so) that prevents potx from extracting these specific six strings to the template files, or there's something else that needs a bit of looking into. -- # Vasileios Lourdas, # Informatics Engineer, Thessaloniki (Greece) # http://www.lourdas.name _______________________________________________ translations mailing list translations@drupal.org http://lists.drupal.org/mailman/listinfo/translations
Konstantin Käfer — http://kkaefer.com/
_______________________________________________ translations mailing list translations@drupal.org http://lists.drupal.org/mailman/listinfo/translations
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.
On 31.07.2007, at 23:18, Vasileios Lourdas wrote:
Hello,
Following this thread, although it's a bit different issue this time, there are six strings that do not get translated after importing a language gettext file (e.g. Greek as in my case). These strings are:
1) create page content 2) create story content 3) edit own page content 4) edit own story content 5) edit page content 6) edit story content
which are role permissions and appear in the administration pages. These strings *do not* appear in the template files (.pot), however they appear in the Manage strings section of the Localization settings page (if you search using the right parameters).
Since the Manage strings section provides me the ability to translate them in my language, I tried manually to insert those strings to a new .po file and translated them using my regular gettext file editor. Then I imported the merged file from all translations by all core modules and of course this procedure worked.
The above make me wonder if there is a bug in Drupal 5.x core (I haven't checked 6-dev, though I will do so) that prevents potx from extracting these specific six strings to the template files, or there's something else that needs a bit of looking into. -- # Vasileios Lourdas, # Informatics Engineer, Thessaloniki (Greece) # http://www.lourdas.name _______________________________________________ translations mailing list translations@drupal.org http://lists.drupal.org/mailman/listinfo/translations
Konstantin Käfer — http://kkaefer.com/
_______________________________________________ translations mailing list translations@drupal.org http://lists.drupal.org/mailman/listinfo/translations
Question: While trying to understand better the problem with the /admin/user/access page where strings like "edit your own [type] content" appear completely untranslated for imported or user-defined types if a translation for them has not been imported, I stumbled into the following: Apparently the translation is performed in user.module, line 1823: $form['permission'][$perm] = array('#value' => t($perm)); This displays the translation of the *whole* permission string IFF it already exists. So far so good. However the existing string "edit own book pages", which is included in book-module.pot, does not have a t() in book.module. How does potx find it and extract it?
Cog Rusty wrote:
Question: While trying to understand better the problem with the /admin/user/access page where strings like "edit your own [type] content" appear completely untranslated for imported or user-defined types if a translation for them has not been imported, I stumbled into the following:
Apparently the translation is performed in user.module, line 1823:
$form['permission'][$perm] = array('#value' => t($perm));
This displays the translation of the *whole* permission string IFF it already exists. So far so good. However the existing string "edit own book pages", which is included in book-module.pot, does not have a t() in book.module. How does potx find it and extract it?
t() is designed to translate literal (written in code, *not* user defined) strings. All literal permission names are collected from hook_perm() implementations by the extractor. Gabor
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
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.
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
On 8/4/07, Gabor Hojtsy <gabor@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?
Cog Rusty wrote:
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?
You mean an 'other.po' for core translations? If you have an exact list of missing default string, we can add them in to the default templates, no need for an other.po file. Gabor
On 8/4/07, Gabor Hojtsy <gabor@hojtsy.hu> wrote:
Cog Rusty wrote:
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?
You mean an 'other.po' for core translations? If you have an exact list of missing default string, we can add them in to the default templates, no need for an other.po file.
Gabor
I meant the 6 strings reported in http://lists.drupal.org/pipermail/translations/2007-July/000422.html create page content create story content edit own page content edit own story content edit page content edit story content because importing them seems to solve the particular problem. Then I tried to generalize a bit and find ways, but the problem at hand is those 6 strings.
Not creating a new thread, the following is related to the initial thread. I noticed that the days in dates, eg. 1st, 2nd, ... 31st, etc. are not translated. Even though the month is, the day remains as is and you end up with a date like this (in Greek): Posted Ιούλιος 31st, 2007 Also, "Posted" (as appears in blog entries) and the "in" string that shows the categories an entry belongs, eg. Posted .... in Drupal, Greek, 5.x are not translated either. I understand that these are difficult terms, because they appear in multiple contexts, especially "in". Solutions for this? The date part is especially ugly, as can be illustrated above. "Posted" and "in" are translatable from the Manage strings admin page. -- # Vasileios Lourdas, # Informatics Engineer, Thessaloniki (Greece) # http://www.lourdas.name
What files are these defined in? I guess in some theme. Gabor Vasileios Lourdas wrote:
Not creating a new thread, the following is related to the initial thread.
I noticed that the days in dates, eg. 1st, 2nd, ... 31st, etc. are not translated. Even though the month is, the day remains as is and you end up with a date like this (in Greek):
Posted Ιούλιος 31st, 2007
Also, "Posted" (as appears in blog entries) and the "in" string that shows the categories an entry belongs, eg.
Posted .... in Drupal, Greek, 5.x
are not translated either. I understand that these are difficult terms, because they appear in multiple contexts, especially "in".
Solutions for this? The date part is especially ugly, as can be illustrated above. "Posted" and "in" are translatable from the Manage strings admin page.
On Thursday 09 August 2007 17:14:53 Gabor Hojtsy wrote:
What files are these defined in? I guess in some theme.
Gabor
You 're right! I'm using the Aberdeen theme, where node.tpl.php contains the following lines: <?php if ($submitted): ?> <span class="submitted"><?php print t('Posted ') . format_date($node->created, 'custom', "F jS, Y") . t(' by ') . th eme('username', $node); ?></span> <?php endif; ?> <?php if (count($taxonomy)): ?> <div class="taxonomy"><?php print t(' in ') . $terms ?></div> <?php endif; ?> Thanks for the tip. Next time, I'll look into the theme first. -- # Vasileios Lourdas, # Informatics Engineer, Thessaloniki (Greece) # http://www.lourdas.name
participants (4)
-
Cog Rusty -
Gabor Hojtsy -
Konstantin Käfer -
Vasileios Lourdas