Node type name translated on node/add page
| Project: | Drupal |
| Version: | 6.x-dev |
| Component: | language system |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed |
Is it right, that when creating new content types, all fields/data (Name, Type, Description) must be given in the native language at first? If so, this should be mentioned somewhere on the create content type form.
Here is my current work flow for translating content type (meta data).
1. create a new content type by filling out all form fields in the native drupal language (English).
Example: I want to create a content type 'Holiday Flat'
- human-readable name: Holiday Flat
- machine-readable name: holiday_flat
- description: This content type can be used to create a page representing the information about a holiday flat.
- Title field label: Name
- Body field label: Detailed Description
2. Next I want to translate the human-readable name, the description, the title field label and the body field label to a second language (e.g. German). I go to /admin/build/translate/search to look for the strings I just entered when I created the content type. But no results are found! So I have to visit the page with the create form for the new content type at least once in the second language (/de/node/add/holiday-flat). Now I am able to supply the translations. But there are lots of places in Drupal where those translations do not work:
Here are the pages where translations are not working correctly, yet:
1. /de/admin/content/types (see screenshot attachment 1)
In the table which lists the content types, just the table headline is translated to German. The values of the existing content types for the three columns (Name, Type, Description) are not translated and still shown in English.
2. /de/node/add (see screenshot attachment 2)
On this overview page, the human-readable name is correctly shown in German, but the description is still shown in English, although there is a German translation for the description
3. /de/node/add/holiday-flat (see screenshot attachment 3)
The Title of the page is not translated. The field labels for Title and Body are not translated.
4. /de/admin/content/node (see screenshot attachment 4)
On this overview page, the content type is not translated in the table and in the filter selection box.
| Attachment | Size |
|---|---|
| translation1.jpg | 113.51 KB |
| translation2.jpg | 105.64 KB |
| translation3.jpg | 82.86 KB |
| translation4.jpg | 98.17 KB |
#1
The general mantra is that Drupal translates built-in interface text (you know when you go to the locale translation interface you searh in the 'built-in interface' group), and you know what you entered is definitely not built-in, so it should not be there. With this in mind:
1. Yes the table headlines and action links are part of the interface, what you entered is not.
2. If the content type name is translated there than *that* is a bug.
3. Expected, these are user provided data and not built-in.
4. Again, expected.
User provided data is not translated in Drupal 6, except posts with the content translation module. Menus, taxonomy, content type details, user profile field labels, etc. are not translatable.
So we have the (2) as a bug, where the node type name *is* translated. Retitling for that.
Looked into this bug and noticed that:
- node/add is hooked to node_add_page() in node.pages.inc
- node_add_page() gets the menu item and uses system_admin_menu_block() with that
- system_admin_menu_block() from system.module uses _menu_link_translate() on the links
- _menu_link_translate() calls the title callback for the menu item
- so back to node.module, which adds the menu items for all content types
- solution: node_menu() should tell the menu that no title callback should be invoked
I tried to look up nice looking examples about this in core, but could not find one.
#2
Actually, since this is user provided data, we should check_plain() it, as other menu item titles are check_plain()-ed. Committed this simple fix. Otherwise, as discussed this issue is 'by design'.
#3
It was my big hope, that this is finally possible with Drupal 6. Are there plans to implement this for Drupal 7? Or will it be possible to translate field labels with 3rd-Party localization modules (i18n, localizer)?
#4
Yes, locale module is ready to support translation of these kinds of strings with a contributed module. I have seen screenshots of i18n module for Drupal 6 using the "text groups" feature to translate these kinds of strings (you know it adds more text groups additionally to the built-in interface, so you can translate these strings). Although we tried to push hard in the D6 cycle to have this in core, we did not have a compelling solution to do it, and it was better not to screw this up, but postpone instead. There is plan to include this feature in Drupal 7.
#5
Is there a thread I can join to post my ideas?
#6
Sure, check out http://drupal.org/node/141461
#7
this fails on node/add/page (etc) with:
warning: Missing argument 1 for check_plain()#8
option #1 - we don't need any callback. This is fine because the page title is already set in the callback function:
http://api.drupal.org/api/function/node_add/6
#9
doh - this is actually a menu bug: http://drupal.org/node/206510
#10
Automatically closed -- issue fixed for two weeks with no activity.
#11
"Remember to remove duplicate entry at search result in Translate Interface".
I've already fixed this using no patch.