Make Profile entities translatable

[bugfolder]

Follow-on to #23. H/T @argiepiano.

There is a bigger issue with profile (inherited from D7): they are not translatable. See this. Adding the property will stop the warnings, but the schema of the profile entity does not store langcode, and therefore the entity is not translatable.

I believe in D7 they managed to make at least the Profile2 labels translatable (that is, the name of the profile type, as in "personal profile", "professional profile" etc). This was done, I believe, by depending on Entity API (Entity Plus in Backdrop) and adding metadata and callbacks in modules/profile2_i18n.module.

...in the long run, we should consider making profile entities translatable.

A PR from someone with translation experience would be most welcome!

[argiepiano]

@bugfolder I've done substantial work toward providing translation functionality for profile type labels. The PR I just submitted does the following:

1. Adds a "Translate" tab when you create/edit a profile type. This allows you to translate the label
2. Adds the user-created profile type labels to the database of translatable terms, so they are also available in the translation interface
3. Switches the label of the profile to the appropriate language when the user pages are viewed or edited in another language (this works both when "tabs" or "fieldsets" are selected for profile editing)

This PR does not provide a full profile translation - it's only the profile type label. In that regard it does exactly what the Profile2 D7 module does. When you combine this new capability with Field translation, you can also get translated profile Field API field labels.

Adding a full profile entity translation is a very different and very substantial endeavor, and it's been put on hold in D7. We can try that on a separate issue in the future perhaps.

Can you please test? This new module depends on i18n_string

There is one issue I've seen that I need to investigate - perhaps you can help me debug: when i18n_field or i18n_menu are enabled after enabling profile_i18n we get a fatal error on a class that belongs to the former modules. If profile_i18n is enabled after those two modules, there are no issues.

[argiepiano]

BTW to test, be sure to add a second language. Otherwise the translations won't do anything.

[bugfolder]

This is my first foray into i18n, so I'll be muddling along for a bit. But regarding the fatal error, the exception

Cannot use object of type stdClass as array

is getting thrown on line 50 of i18n_field.inc, which is the if statement in

  public function __construct($type, $key, $object) {
    parent::__construct($type, $key, $object);

    // If this is a field instance, get field info but add instance data too.
    // This instance data will be used to get the paths
    // to get the edit/translate path.
    if (isset($this->object['bundle']) && isset($this->object['entity_type'])) {
      $this->object = field_info_field($this->object['field_name']) + array('bundle' => $this->object['bundle'], 'entity_type' => $object['entity_type']);
    }
  }

It seems weird that a variable called "object" is being addressed with array syntax.

[argiepiano]

Yes, I noticed that. D7 does exactly the same, but it doesn't throw the error. My suspicion is that this is a problem with i18n_string.

[argiepiano]

LEt me know if you need other pointers to test what I have so far. As long as we enable profile_i18n after i18n_field and i18n_menu we'll be fine for testing.

[bugfolder]

When that function gets called for the body field, indeed, $this->object is an array.

[bugfolder]

The original code for i18n_object::load_object() said "Load real object or array," which suggests that subclasses should be prepared to accept either.

[argiepiano]

Thanks for looking into that, @bugfolder. I need to stop for a while today. In the meantime I pushed a couple of tweaks to the PR that are unrelated to that fatal error - the new stuff adds Translate to the dropdown button for profile types.

[bugfolder]

Let me know if you need other pointers to test what I have so far.

Sure. I've added Spanish language, and added a translation for the label. Where do I find the setting to make that language appear for me? (Setting my user account to "Spanish" doesn't do it, it seems.)

[argiepiano]

To see the Spanish translation add 'es' to any path, as in /es/user/1/edit

[argiepiano]

I just realized we need and update hook to update the profile type config files for existing installations. Will add thi later

[argiepiano]

@bugfolder just pushed a couple of changes including an update hook for existing installations. Without it (if you patched an existing site) you most likely could not make the functionality work. The update hook adds _config_translatables => array('label'); to the json files, so that the translation functionality from Config works properly.

Also fixed an oversight in the default main profile type config file.

[bugfolder]

To see the Spanish translation add 'es' to any path, as in /es/user/1/edit

Hmm, /es/user/1/edit gives "page not found".

[argiepiano]

Have you enabled URL detection at admin/config/regional/language/detection ?

[argiepiano]

@bugfolder I found the bug that was causing the fatal error. It was the profile's implementation of hook_i18n_string_objects - it needed to have a check for $type to match the type of string objects that profile uses, to avoid sending the list of profiles when other i18n modules are enabled.

I've fixed that in the last push, and the fatal error is gone!

[argiepiano]

BTW these are more detailed directions for testing:

1. Start with a vanilla install of Backdrop. Turn on "Error message display: All errors"
2. Enable Profile
3. Patch the profile module with this patch
4. Important: run update.php to run the update in this patch
5. Enable Language and Locale
6. Install Spanish or another language
7. Check admin/config/regional/language/detection to be sure URL detection is on
8. Enable Profile translation and all its dependent modules (Internationalization, String translation)
9. Add a field to the main profile at admin/structure/profiles/manage/main/fields
10. Visit admin/structure/profiles/manage/main and click the Translate tab. Enter a translation for the label (e.g. Perfil Principal)
11. Visit user/1/edit. You should see the Main PRofile fieldset with an English title
12. Now visit es/user/1/edit. The profile fieldset should have "Perfil Principal" as the fieldset title.

You can now enter some data in the profile. Then click on View to view the user page (in my case accounts/acremaschi as it's using an alias with the username). If you then visit es/accounts/acremaschi you should see the label of the profile in Spanish

[bugfolder]

Ah, `admin/config/regional/language/detection was what I was missing.

With that (and the latest PR, and running update.php) I can report that the translated profile label does appear on both the user view page and edit pages (and edit page for the individual profile).

Also that enabling Field Translation doesn't crash.

So this looks RTBC, functionality-wise. A few code comment typos, see the PR.

[bugfolder]

...And I see those changes, so fully RTBC!