Translate node types
neochief - February 3, 2009 - 13:49
| Project: | Content Profile |
| Version: | 6.x-1.x-dev |
| Component: | Base module |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs review |
Description
Hello
If you have a multilang site, there's no any posibility to translate a profile title on user's page. I made a patch to fix this.
| Attachment | Size |
|---|---|
| content_profile.theme_.patch | 555 bytes |

#1
My solution wasn't complete.
1) Profile tabs can not be localized
2) I noticed that there are no "Translate" tab on profile pages, if you're using multilang. I've added it.
Here's a complete patch.
#2
Why can't we reuse the callbacks from the translation module?
>1) Profile tabs can not be localized
We can't run them through t(), only fixed texts should be run through t(). For this there is tt() from the i18n module, so we would need to integrate with that. Probably best is to add a wrapper for tt() that checks whether i18n is active...
#3
>+ 'title' => 'Translate '. check_plain(drupal_ucfirst($type_name)),
This should be run through t() correctly using placeholders.
#4
Yes, I agree that this looks a bit hacky. Just wanted to get some feedback.
We can't reuse translation callbacks, because we're loosing all tabs from user scope.
As for tt()... well, I didn't know about it until today :) I supose it bring dependency to i18n?
#5
@dependency for localisation:
>Probably best is to add a wrapper for tt() that checks whether i18n is active...
We should do that wrapper which checks for i18n and if not available just passes the string through. This way we can avoid the dependency. Then we should run all node type names through it.
@profile translation:
I'm a bit unsure if we should put that in the "base" module, as it should be kept as small and simple as possible. However as of now the patch is rather small and I don't think we need later more to support profile translation? Opinions?
Also I wonder if the translation tab should just beside of the usual tab or it would make sense to create sub-tabs?
@patch:
I think it also misses a check whether the node type is translatable. Does the translation overview work right even there is no node yet? Does it make sense to show it if there is none?
Quite some questions, so perhaps we start with the localisation task first, which is more important in my eyes.
#6
Thank you for the patch.. I applied the patch in #1, and the content profile title on user's page is indeed translated, but only when the link is placed as a tab. When the link is placed as a sub tab of the used edit tab, the title remains untranslated... I have tried placing the t() function on different places without success...
Any help will be appreciated...
P.S. I have also changed the following:
$text = t($element['#admin'] ? "Create the user's @profile_node." : "Create your @profile_node.", array('@profile_node' => node_get_types('name', $type)));
TO
$text = t($element['#admin'] ? "Create the user's @profile_node." : "Create your @profile_node.", array('@profile_node' => t(node_get_types('name', $type))));
Which will make the "Create your @profile_node" string, translatable (Maybe not the best way to do it, but it worked)
#7
#8
Really don't know why my comment wasn't inserted along with the attach... :(
#9
It's a bug of d.org
#10
@neochief: thanks, i hope it is solved soon :) it is a little bit frustrating to loose your comments
@#5
1. @dependency for localisation: i added the function cp_tt. it checks for the existence of function 'tt' and then proceeds accordingly
2. @profile translation: my opinion is that we should move it into another module and maybe have subtabs.
3. @"it also misses a check whether the node type is translatable." - i did not take care of this yet
I'll attach the patch soon.
#11
#12
How about a different approach?
Since the tabs and edit tabs do not follow the normal pattern within Drupal, your average user might not look for a profile tab in the right place anyway, no matter where you put it.
Show a tab at the user's page
Show a secondary tab below the user's edit tab
What if you created a regular menu item for the navigation menu called "My profile" right after "My account". Menus can be easily translated and the profile display would have a normal edit tab. Us non-programmers can't do it because we can't supply a path that includes the user number into the D6 menu system.
#13
if you are looking to change content type titles then enable i18ncontent module and work with translations through
tt("nodetype:type:$type:title"for having this fixed it would be enough to change the
.tplappending a conditional before
print $title<?php if (module_exists('i18ncontent')) $title = tt("nodetype:type:$type:name", $title); ?><?php print $title; ?>
this will work for users needing this
nevertheless, it should be done right in the preprocess function
but as you can see, there is no need for such a complicated patch on this
#14
in the preprocess function it would be
<?php$title = node_get_types('name', $node->type);
if (module_exists('i18ncontent')) $title = tt("nodetype:type:$type:name", $title);
$variables['title'] = check_plain($title);
?>
#15
NOTE: only apply ONE of these solutions #13 OR #14, but not both of them at the same time
ALSO NOTE: if your site has been running with different default languages you might find some others problems, I'm working on a patch to attempt some support on this, but I don't promise anything, since switching default language shouldn't be done
EDIT:#582438: improve content types UI support#16
BTW my comments are with respect the original issue
since there is another issue dealing with the more general solution #461262: Content profile can't handle translated profiles
#17
Thanks @arhak, I applyed the changes you suggest in comment #13 and works fine! Thank you very much.
#18
This patch is similar to #11, in that it has a wrapper for tt(), and uses it for translating node types.
Some differences
* does not have the other hook_menu item content_profile_translation_node_overview
* the wrapper function uses module_exists(), no need for static variable, as module_exists() already does this
#19
Fixed small typo.