Translate relationships (as 'friend')
emi_bcn - May 24, 2009 - 15:56
| Project: | User Relationships |
| Version: | 6.x-1.0-rc2 |
| Component: | Code |
| Category: | support request |
| Priority: | normal |
| Assigned: | aufumy |
| Status: | closed |
Description
Hi there!!
I've been looking for relationship translation method and I was unable to find it anywhere. I mean, how do I translate the 'friend' string? It seems like it's not possible. May be some t() missing?
Thanks a lot!!
#1
Please post screenshots. Thanks.
#2
Thats true. I'm not able to translate it as well:
F.ex.
"Become username's friend" in Relationship Actions Block is not translatable.
#3
Hmm it sounds like 'friend' is what you have called your relationship type... in that case that is probably not translatable, you are right. The options are:
* If this is your only type defined, then translate "Become %name's %rel_name" which is used in
function theme_user_relationships_request_relationship_direct_link(&$relate_to, &$relationship_type)* If it isn't, override this function in your theme to output proper link titles...
This behavior is rooted pretty deeply in UR so ideas on how to apply translation across the board are welcome.
#4
Added some t() 's around the display of the relationship type.
#5
Very nice, thank you!
Could you just also translate the plural names where given:
<?php'%rel_plural_name' => $relationship_type->plural_name)
?>
to
<?php'%rel_plural_name' => t($relationship_type->plural_name))
?>
A parallel question, a reality check more than anything... would it make sense to use another text group for translating relationship names? Similarly to how menus, block titles, etc are different from the "built-in interface" text group. This will help disambiguate some names like 'parent' which can be seen as verbs or nouns out of context.
#6
That makes a lot of sense, to use a different group.
Will do.
#7
This patch:
* implements hook_locale() in user_relationships_ui.module to define a new group
* uses function tt() from i18nstrings module to get the translated strings from the right group
* implements a degrade path if i18nstrings module is not enabled.
#8
Great stuff, thank you!
#9
Committed the following patch to branch DRUPAL-6--1
#10
A few more missing tt()'s committed to cvs
#11
The patch itself is a great thing but please think about this:
+++ user_relationships_api/user_relationships_api.module 23 Sep 2009 00:35:26 -0000@@ -247,3 +247,12 @@ function user_relationships_api_user($ty
+
+/**
+ * provide a degrade path for function tt found in module i18nstrings
+ */
+if (! module_exists('i18nstrings')) {
+ function tt($name, $string, $langcode = NULL, $update = FALSE) {
+ return t($string, array(), $langcode);
+ }
+}
Even if this might be a good idea what will happen if all modules that want to use tt() do this?
I don't think it is wise to do this!
Maybe provide a real wrapper like
<?php
/**
* provide a degrade path for function tt found in module i18nstrings
*/
function ur_tt($name, $string, $langcode = NULL, $update = FALSE) {
static $i18nstrings;
if(!isset($i18nstrings)) {
$i18nstrings = module_exists('i18nstrings');
}
if ($i18nstrings) {
return tt($name, $string, $langcode, $update);
}
else {
return t($string, array(), $langcode);
}
}
?>
This review is powered by Dreditor.
#12
I like that this uses a static variable instead of calling
module_exists('i18nstrings')andfunction_exists('tt').However, if one uses
if (! module_exists('i18nstrings') && ! function_exists('tt')) {then the case that other modules may follow suit could be avoided.
What I like about using module_exists/function_exists way, is that when i18nstrings module is enabled, there is no extra layer of each module instantiating their own function, and each time contribmodule_tt() is called to go through the processing each time.
Thoughts?
#13
I think that
! function_exists('tt')is a good idea and less work if you don't want to add a real wrapper. Performance wise I don't think there will be a difference. I feel a wrapper is cleaner but just decide what you want to use :)#14
I like this approach. You do NOT need the static $i18nstrings as module_exists() already does a static cache for you.
This is helpful yet a little short...
http://drupal.org/node/304002
#15
Alright, I see the light now. If there is a poorly written tt() function from a contrib module with a lower weight, this would cause problems for every other contrib module that calls tt() when i18nstrings is not enabled.
/*** Wrapper function for tt() if i18nstrings enabled.
*/
function ur_tt($name, $string, $langcode = NULL, $update = FALSE) {
if (module_exists('i18nstrings')) {
return tt($name, $string, $langcode, $update);
}
else {
return $string;
}
}
#16
#17
Great work, thanks for the patch and the reviews!
#18
Committed to cvs DRUPAL-6--1, thanks to Kars-T, Scott Reynolds and Alex.K!
#19
#20
Automatically closed -- issue fixed for 2 weeks with no activity.
#21
Kars-T, Scott, if you can pipe in on a related similar issue
http://drupal.org/node/606804
Thanks
Audrey