Message API messages are not translated

Hi Ezra, Team,

Explanations for each of these gaps in translation are below:

#1 - The Spanish translation for "Posts" in this case is also "Posts". When I translate to another language, Arabic for example, "Posts" is translated to an Arabic string correctly.

#2 - This string is not prepared in the code for translation (ie. not using a t-function). In the commons code in "profiles/commons/modules/contrib/commons_wikis/commons_wikis.features.inc":

"value" : "\u003Ca href=\u0022[message:user:url:absolute]\u0022\u003E[message:user:name]\u003C\/a\u003E has updated the \u003Ca href=\u0022[message:field-target-nodes:0:url]\u0022\u003E[message:field-target-nodes:0:title]\u003C\/a\u003E wiki page",

Notice the string begins to be translated after "wiki page". This is something that could be patched by the commons_wikis maintainers.

#3 - The Events tab is a special tab, governed by the commons_events module. The translation of the tab's string can happen as a menu_link, but the steps Commons is taking to display that tab does not seem to include honoring the localization. If I step through the Commons code and update the display-related strings of "'Events'" to use the t-function "t('Events')", and if I play with the translation settings in the menu_link, then I can get the localization to show up. But this will not happen by default for that tab in its current state.

#4 - This "TODO(S)" menu item contains some HTML; so on the initial translation pass coming from the l10n_update module, it excludes it from being used. This note which I think is related appears in the recent-log report: "Disallowed HTML detected. String not imported: ".
A second pass through the Lingotek "Sync" page should pick up this missing string and provide the translation. (It did on my test of the commons distro.)

I'll try to answer any additional questions you have on this too. Thanks for the input!
--Rob

A patch to take care of #1, #3 and #4 by changing commons_bw_generate_group_widget() to no longer run variables through t() and by customizing the Events menu item as i18n menu will not translate menu items that are not marked as customized*.

*Note that there can be some weirdness around translating exported menu links so you might have to rebuild the menu string text group in order for them to show up for translation.

To translate messages the user must use the Message module's built in translation functionality (the translated sections are caused by token substitution).

As a follow-up to conversations we've had on the topic of Message API translation, here is the current plan for handling Message API:

Lingotek is working on a new way to handle translations of all entities. This will take the place of the current content type and comment translation paths, and we are targeting translation of Message-API-related entities too. Message API translation may be more complex than basic entities and could include some additional processing, but we are postponing adding support for Message API translation until the completion of the new way of translating entities.

Under Lingotek 7.x-5.x, I am able to get messages translated as separate entities with a little data tweaking. I'm attaching an image showing the translations. These translations are a combination of three processes:

1. The token fields are translated based on existing title-field translation. (worked originally)
2. The group references are translated as built-in strings from a t() function. (worked originally)
3. The additional wording in the message fields are now translated using field translation on entities of type 'message_type' (new)

The data tweaking I did was to set all languages for message types to be the site's default language (English in this case). I am not sure yet why the 'language' field in the message_type table was empty originally, but it needs to be set in order to know the source language to use for the translations.

Would it be possible for Commons to set the language on the message types that are created automatically at install time? If not, I think I could write a utility function to set those at the time the Lingotek module is enabled; but it would be cleaner if the message_type entries were fully built out to include language.

Let me know if this looks like the right direction. Thanks!

Messages appears to be translating correctly based on what I see when installing Commons and stepping through the Lingotek install process. The only extra step is to set a language for the messages that are auto-generated during installation, as the language is not set for these out of the box in Commons. Please review.