Translation of User Interface: not working on og-module (feature-request)

[schoenid]

While working on a german translated environment, I've realized that the most of og-module terms will not be translated and do not provide a field for ui translation on admin/config/regional/translate/translate.

This is as example on

account settings accounts/%user: "Group membership:" group nodes:

Bearbeiten (Edit): Group visibility Public - accessible to all site users Private - accessible only to group members

Gruppe (Group):

[Add people](group/node/%ID/admin/people/add-user) Add group members.

[People](group/node/%ID/admin/people) Manage the group members.

[Permissions (read-only)](group/node/%ID/admin/permissions) View the group permissions.

[Roles (read-only)](group/node/%ID/admin/roles) View the group roles.

Group content nodes:

Bearbeiten (Edit): Groups audience Your groups

  `OTHER GROUPS`

Group content visibility Use group defaults Public - accessible to all site users Private - accessible only to group members

There are also a few terms, showing up on on admin/config/regional/translate/translate, but the translation is not visible on the group nodes or group content nodes:

Group visibility Group content visibility Groups audience

Some terms are showing up and are working, like:

Are you sure you want to join the group %title? Join Anything with 'subscribe' ...

[argiepiano]

Yes, much of it is happening because the authors of OG did not wrap UI text in t(). Take for example the visibility text in og_access_og_fields_info():

  $allowed_values = array(
    0 => 'Public - accessible to all site users',
    1 =>  'Private - accessible only to group members',
  );

So, what needs to happen is for someone to wrap those in t() so that they can be translated in the UI. Would you be willing to give this a try? It should look like:

  $allowed_values = array(
    0 => t('Public - accessible to all site users'),
    1 =>  t('Private - accessible only to group members'),
  );

[schoenid]

Yes, I've tried it, but with no success.

File: backdrop/modules/og-1.x-2.x/og_access/og_access.module

...
function og_access_og_fields_info() {
  $allowed_values = array(
    0 => t('Public - accessible to all site users'),
    1 => t('Private - accessible only to group members'),
  );
...
  $allowed_values = array(
    0 => t('Use group defaults'),
    1 => t('Public - accessible to all site users'),
    2 => t('Private - accessible only to group members'),
  );
...

• The entries are still visible in the nodes edit forms, so it seems that it does not create problems.
• The terms do still not show up in the translation form, even after refreshing the cache. So it seems that there is something else necessary to add or change in the code.

[argiepiano]

Yes, the issue is that you have to make these code changes BEFORE you enable the og_access.module and add the access fields to the group. OTherwise the changes come too late - in your case I suspect the fields had already been created.

If you want want to try this, be sure to remove any and all og access fields from your content types, uninstall og_access, change the code, reinstall, and re-add the fields. (You may also need to visit the page in the other language, as in /es/node/1/edit)

See image of that string appearing in the translation interface at the bottom of the table:

[argiepiano]

PR #88.

I've added a bunch of t() all over the place. @schoenid it'd be great if you could test on your end. To do so, be sure to patch your local version of OG with the PR, as it hasn't been merged yet.

[argiepiano]

@schoenid I've done a bit more digging into this. In fact the problem was not that there were some missing t(). Those strings are mostly in select fields, and adding the t() there will not make any difference.

So, this is what I needed to do for the translated options to be shown both in the node form, and in the node display:

1. Be sure to enable Field Translation, which is part of Internationalization. And of course be sure to enable Language and Locale
2. Add the OG fields to the group node, etc. This includes OG access fields, etc. You then may need to refresh strings (admin/config/regional/translate/i18n_string)
3. Visit the second language node add form - the string will shown unstranslated
4. Go to the translation UI. When you look for any of the field texts (e.g. "Private - accessible only to group members") you should now see it appear with a special context (group_access:#allowed_values:1) meaning that you are actually translating the field options there
5. Enter the translation string
6. Go to Manage display for the group node and be sure to select "Default translated" in Format for the specific fields
7. Then visit the display or form for the group node. You should see the translated string

I hope this helps! I'll be glad to keep troubleshooting this.

[schoenid]

Thank you.

I'm not sure about:

1. Be sure to enable Field Translation, which is part of Internationalization. And of course be sure to enable Language and Locale

Is it "Content Translation"?

I've configured OG fields: All fields except "Group roles and permissions".

In the groups content type settings I have to disable "Group visibility" and "Group".

These are used in views and layouts:

This gives me as result:

Ohhhh ...

After editing the view, the strings do appear in the transtation!

No save, no changement, just open the view for a screenshot. I've checked the appearance of the string "Public - accessible to all site users" after every step above ... All other strings from the note above are also available. I don't know, what's happened ... !!!

So there must have been a problem with something else in the system. I will check that on the other installations where I have the same problem.

[schoenid]

There I have still the old problem:

But I will try, to reproduce all the steps I've done above ...

No. On the other two sites it's not working.

Now I've got:

• one site with working translation
• two sites without working translation

But I have realized, that I could enter the translated string directly in the node types field setting - if used only for one language.

[argiepiano]

Is it "Content Translation"?

No, it's not Content Translation. Be sure to install the module "Internationalization" first, then you'll see a submodule called "Field Translation

After you install, please follow the steps and try again. I can work with you if this is not working.

[olafgrabienski]

Ohhhh ... After editing the view, the strings do appear in the transtation!

Hm, that sounds familiar to me! I don't know the technical details, but sometimes the translation system needs a string to be viewed before it shows up on the Interface translation page.

[schoenid]

Thank you!

Yes, this works ;)

Conclusion: this is not an og issue, but an issue in the core ... with "Field translation" as workaround ...

[argiepiano]

Thanks @schoenid. I think it would be helpful to have a central page (perhaps someone in backdropcms.org) that outlines all the translation-related functionality, both in core and contrib. Right now the information is scattered all over the place. And the Internationalization module doesn't really have an explanation of each submodule - I had to search the Drupal counterpart module for explanations.

I don't do a lot of translated sites (though my first language is Spanish). But perhaps you and @olafgrabienski may want to propose such a page in the Backdrop Ops? https://github.com/backdrop-ops/docs.backdropcms.org/issues

[schoenid]

My first attention for the moment is on Organic Groups. If possible, I would concentrate my work on documentation there.

I'm not the specialist for translated web pages, just my users want all in german. Every single word in english seems to be too much. (For me, it doesn't matter. But I'm looking to use a correct configuration. I don't like to tinker ...)

I'm doing this on a nonpaid base for non-profit groups in my free time. So my capacity is limited, altough my intention is always, to bring to an end, what I have started.

[olafgrabienski]

I think it would be helpful to have a central page (perhaps someone in backdropcms.org) that outlines all the translation-related functionality, both in core and contrib. (...) perhaps you and olafgrabienski may want to propose such a page in the Backdrop Ops?

Such a page would be helpful, indeed. I won't have time to work on it in the near future. When that changes, I can make that suggestion, if nobody beats me to it.