Translate relationships (as 'friend')

Please post screenshots. Thanks.

Thats true. I'm not able to translate it as well:

F.ex.
"Become username's friend" in Relationship Actions Block is not translatable.

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.

Added some t() 's around the display of the relationship type.

Very nice, thank you!

Could you just also translate the plural names where given:

'%rel_plural_name' => $relationship_type->plural_name)

to

'%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.

That makes a lot of sense, to use a different group.

Will do.

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.

Great stuff, thank you!

Committed the following patch to branch DRUPAL-6--1

A few more missing tt()'s committed to cvs

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

/**
 * 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.

I like that this uses a static variable instead of calling module_exists('i18nstrings') and function_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?

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 :)

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

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;
  }
}

Great work, thanks for the patch and the reviews!

Committed to cvs DRUPAL-6--1, thanks to Kars-T, Scott Reynolds and Alex.K!

Kars-T, Scott, if you can pipe in on a related similar issue

http://drupal.org/node/606804

Thanks
Audrey

With RC3 the User Relationships PO is empty.

Existing strings are not there, new ones added just to try out the translation are not there either.

Dare I reopen this issue?

Translations have been reorganized by d.o translators into respective modules. So they are no longer all together in user_relationships_api. Can you confirm if that's the case for you?

Hi,

I'm trying to translate my 'friend' relationship to 'amigo' in Spanish. I was able to translate 'friends' (plural) to 'amigos', because it appeared in the list of the strings to be translated, however 'friend' (singular) does not appear when I search for it in the translation interface. How can I translate my relationship name ?

Thank you.

Hi,

Following http://drupal.org/node/789286, I created a patch which adds the user defined strings to the i18nstrings module using i18nstrings_update. So, if you want to translate your 'friend' or whatever relationship to another language:

1. Apply the attached patch to the UR module
2. Edit the relationship you want to translate (don't change anything to the data, simply click on the edit and then Submit button)
3. Go to the 'Translate interface' page and search for your relation name. It should be there and you should be able to translate it.

I have tested patch #25 and it is RTBC.

I had to implement this patch in a live system, because it is not possible to translate relationship names if you change the name of a relationship.

This patch fixes the missing functionality and enables you to translate the name of the relationship. String are updated.

Thanks for this patch!

Please bring this issue to an end and commit #25. Thanks.l

Refactored into a function to avoid duplication, committed in http://drupal.org/cvs?commit=420356. Thanks!

subscribing