Profile2: how to make the translate tabs appear

As of now, I'm just trying to make the profile2 type appear on admin/config/regional/entity_translation.

I implemented this :

function profile2_translation_info($types = NULL) {
  $info['profile2'] = array(
    'translation' => array(
      'translation' => array(
        'class' => 'EntityTranslationProfile2Handler',
        'base path' => 'profile2/%profile2',
        'access callback' => 'translation_profile2_tab_access',
        'access arguments' => array(1),
        'edit form' => TRUE,
      ),
    ),
  );
  return $info;
}

... in profile2.module (translation_profile2_tab_access returns TRUE) and this :

class EntityTranslationProfile2Handler extends EntityTranslationDefaultHandler {

  public function __construct($entity_type, $entity_info, $entity, $entity_id) {
    parent::__construct('profile2', $entity_info, $entity, $entity_id);
  }

//  public function isRevision() {
//    return !empty($this->entity->revision);
//  }

  public function getLanguage() {
    return $this->entity->language;
  }

//  public function getAccess($op) {
//    return node_access($op, $this->entity);
//  }

  protected function getStatus() {
    return (boolean) $this->entity->status;
  }
}

... which I know won't be functional but just I'm just starting.

Nothing happened on the page yet, so if anybody can point me to what I'm missing ...

Well, in fact it was already there and I feel really stupid.

So I guess it's a matter of providing the correct info to ET to give the correct paths to edit the translations.

Anyway, any info about this is also welcome.

Thanks a lot for this answer.

The paths are managed in a very special way in profile2 and I guess that's why I have such a hard time implementing at least a basic working thing.

In profile2, the actual entity is never accessible directly, but through the user pages, so finding the right menu path is not easy.

Am I right thinking the end path should be /profile2/pid/translate, just like nodes ?

Also, I'm not sure if all the node code should be implemented or if things are supposed to work as is.

OK, my ego feels better ;-).

I'll have a look at this issue after I have finished to implement my ugly temporary hack for my use case.

Did some tests : as soon as I define a base path (even with only one wildcard) in profile2_translation_info, I cannot access profile information in user/xxx/edit/main anymore : the form displays empty values.

As of now, providing any base path leads to problems, even without any wildcard.

Another note : the access callback seems mandotary, otherwise it throws a notice saying

Notice : Undefined index: access callback in entity_translation_menu() (ligne 171

I don't think so. The faulty line is this one :

        'access arguments' => array_merge(array($entity_type, $entity_position, $language_position, $item['access callback']), $item['access arguments']),

It's simply a direct reference to an inexisting index so nothing to write home about. I don't define the access callback, ET tells me so, period.

I went a bit further : I set a fake path like this :
'base path' => 'user/7/edit/main/7'

and tried to access user/7/edit/main/7/translate.

This error came out :

Fatal error: Call to a member function label() on a non-object in /srv/sites/web59/web/sites/all/modules/entity/entity.module on line 724

Trying to follow the track up to the faulty call.

Backtracing, I came to

  $handler = entity_translation_get_handler($entity_type, $entity);
  // Initialize translations if they are empty.
  $translations = $handler->getTranslations();

  if (empty($translations->original)) {
    $handler->initTranslations();
    $handler->saveTranslations();
  }

... in entity_translation.admin.inc where $translations seems to be empty even after the 'if' statement.

I thought giving as much feedback as possible could be useful. But well ...

I turn this into a bug report, as I don't need the feature so much now.

I was trying to help on good intent. I thought the steps could be useful for you to debug your module. I understand they're not so I won't do it again.

No bad feelings : just a little overreaction after a hard day of work.

See you.

Back to business, but not with very much success.

One thing (among many others) I don't understand, and I hope you'll agree to help me about :

This code :

      $items["$path/translate"] = array(
        'title' => 'Translate',
        'page callback' => 'entity_translation_overview',
        'page arguments' => array($entity_type, $entity_position),
        'type' => MENU_LOCAL_TASK,
        'weight' => 2,
      ) + $item;

... passes two arguments from the URL to the entity_translation_overview function.

This function then treats the second argument, and actually succeeds, as an entity object.

I cannot understand how a numeric argument can become a class instance between the menu entry and the actual function code. Is there some Drupal magic I'm not aware of going on here ?

It works for node entities but all my tries with profile entities lead up to errors because the numeric argument stays so and never becomes a class which the entity_translation_overview can handle.

Maybe I just need some rest ...

Thanks for your answer. I thought I had understood this system, but obviously I don't.

So the value holded by the wildcard must be passed to a loader function isn't it ? Because the URL just holds an id, not an object. I saw there is a function called entity_translation_menu_entity_load but it doesn't seem to get called at any time.

Okay, now that I have a better understanding of the process, I managed to provide an arbitrary path and got the translation form loaded with a profile2 entity. The loader indeed exists in profile2 code. The menu callback has to be implemented like that :

function profile2_menu() {
  $items['arbitrarypath/%profile2'] = array(
    'title' => 'Profile translation',
    'description' => 'Provide arbitrary base path for profile2 entity translations',
    'page callback' => 'entity_translation_overview',
    'page arguments' => array('profile2', 1),
    'access arguments' => array(TRUE),
    'file path' => drupal_get_path('module', 'entity_translation'),
    'file' => 'entity_translation.admin.inc',
   );

Of course, it doesn't fit with profile2 architecture and only fulfills testing purposes but I think it can be useful to some.

With a usable base path, all the ET stuff works like a charm : you can add translatable fields, add translations to them and see the translated version appear on the other languages pages.

So the problem problem boils down, as you said before, to providing a real path, consistent with profile2 paths, which is not possible at the time being due to the aforementioned issue : #1092332: Support arbitrary base paths.

I think the ET part of the present issue is, if not solved, reduced to its root elements, so maybe you can close this but it's of course up to you.

Thanks for your patience.

My, you're right. I was really off big time on this one. Will try to do better next time.