I want to use Commons for a german site. But when the Locale module from core is enabled, the entries of the activity stream are empty, only showing the time (time ago).
I tested this with 3.0 and current dev, with a fresh install and the demo content. The only thing I did after install was to enable the Locale module.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

taraluktus’s picture

Priority: Major » Normal

Just wanted to add that this bug occurs with all activity streams, not only with the site activity stream.
I'm not seeing any warnings or notices from PHP.

VVS’s picture

Version: » 7.x-3.0

In Russian too.
If disable module Locale 7.20 - activity is OK.

Softovick’s picture

Exactly the same problem in Russian

taraluktus’s picture

Bug doesn't depend on language, just on enabling the Locale module (which is, of course, needed for non-English sites).
Maybe this should be major?

VVS’s picture

I suspect that all the same as in Commons2. You must custom translate these messages in /admin/structure/messages
But when enter in the editing message I do not even see the original English message, but there is a change of language.

Not major...

taraluktus’s picture

Yes, I am not able to translate the messages in admin/structures/messages. There is the drop down to change the field language, but no matter whether I choose English or German, the text fields where the token stuff should be (and actually is with Locale disabled) keep empty.

ezra-g’s picture

Priority: Normal » Major

Yes, I am not able to translate the messages in admin/structures/messages. There is the drop down to change the field language, but no matter whether I choose English or German, the text fields where the token stuff should be (and actually is with Locale disabled) keep empty.

If reproducible, this would be major in priority.

taraluktus’s picture

I was able to reproduce this issue with my local dev stack and commons-7.x-3.0-dev. Only the first view mode text field is showing at admin/structure/messages, and it is empty.

morphay’s picture

Assigned: Unassigned » morphay
FileSize
62.74 KB

if the module Loсal was not turned on even once, then the messages in admin/structure/messages are present.

morphay’s picture

Assigned: morphay » Unassigned
taraluktus’s picture

if the module Loсal was not turned on even once, then the messages in admin/structure/messages are present.

And they are back again when you turn off the Locale module when it previously was turned on.

slowflyer’s picture

My fields are empty as well as mentioned in #6.
But I can enter new messages and the translation is stored.
But as soon as a translated message is used...

... there seems to be another issue with the message module ...

Warning: array_flip() [function.array-flip]: Can only flip STRING and INTEGER values! in EntityAPIController->load() (line 219 of /srv/www/htdocs/commons3/profiles/commons/modules/contrib/entity/includes/entity.controller.inc).
Recoverable fatal error: Object of class Message could not be converted to string in DatabaseStatementBase->execute() (line 2139 of /srv/www/htdocs/commons3/includes/database/database.inc).

Seems to be a more generic issue of message module in an multilingual environment ...

ezra-g’s picture

Issue tags: +Commons 7.x-3.1 radar

Adding to our Commons 7.x-3.1 radar.

ezra-g’s picture

Assigned: Unassigned » japerry

japerry volunteered to triage.

japerry’s picture

After further debugging, I can reproduce this as well. Specifically it has to do with Message: Rendered Message inside views. The query works as designed, but it doesn't render the items correctly when locale is turned on.

It does appear to be an issue with the message module, and not commons. I'll open up a new issue there and reference this ticket.

taraluktus’s picture

Thank you!

japerry’s picture

Status: Active » Postponed

Okay the issue has been found. It has to do with how entity API renders content by default, and what it does with LANGUAGE_NONE content when locale is enabled.

There is a patch that does work, but as fago says here, http://drupal.org/node/1932530 -- this is not a patch that belongs in the entity api.

For now we will include this patch in commons so all entities will work when locale is enabled, but we need to have the message module optimally implement its own version of this patch.

Marking postponed until message fixes this. Then we can pull the patch out of the make file.

taraluktus’s picture

Your link points to this issue, wasn't able to find the post from fago. But nevertheless, good news ;-)
Edit: Ok, found it: #1782134: Translatable fields: Not overriding language-none values with empty default-language values

japerry’s picture

Committed the locale fix patch to the drupal-org make file:

http://drupalcode.org/project/commons.git/commit/c389385

ezra-g’s picture

hansfn’s picture

Related issue with work-around for translating activity stream - #1968238: Translation of activity stream / messages.

ezra-g’s picture

Adding this issue to the 3.4 radar.

japerry’s picture

Status: Postponed » Active

Re-marking active as part of the i18n push.

Devin Carlson’s picture

Marked #2075105: Cannot edit message type as a duplicate.

Devin Carlson’s picture

Version: 7.x-3.0 » 7.x-3.x-dev
Assigned: japerry » Unassigned

I haven't been able to duplicate some of earlier reports mentioned in #1935784: Message: Rendered Message does not render properly when locale is enabled so I believe the remaining issue here is #2006702: Support for undefined language unless something else turns up.

ezra-g’s picture

Since the best potential solution to #2006702: Support for undefined language is the patch at https://drupal.org/node/2006702#comment-7842259, I propose we add that to the Commons make file and mark this as fixed. @Devin Carlson: Any reason not to proceed that way?

Devin Carlson’s picture

Status: Active » Needs review
FileSize
660 bytes

@ezra-g I don't see any issues with simply including the patch in the make file since it does not modify any data and passes tests.

Devin Carlson’s picture

Status: Needs review » Fixed
slowflyer’s picture

Using a fresh install of Commons 3.3, enabling Locale, adding a second language, copying messages from UND to the enabled languages, modify the translation, creating a post, question or answer, still the message for UND is shown.

Doing the same on a site build on 3.2 and updated to 3.3...
Message Types included in 3.2 show up correct translated, message Types introduced with 3.3 show UND message strings.

ezra-g’s picture

Please let us know if you can reproduce with a fresh install of the latest dev of Drupal Commons.

Devin Carlson’s picture

@slowflyer did you add a filter to the activity stream view in order to restrict it to the current user's language?

slowflyer’s picture

#30 @ezra: It still happens with a fresh install of latest dev from 18th September

#31 @Devin: Neither in #29 first part nor in the fresh install now, the view was modified. For #29 second part the filter has been modified

greetings from Prague!

slowflyer’s picture

It still happens with a fresh install of latest dev from 2nd October

daniel.c’s picture

Status: Fixed » Active

Just want to confirm the same problem with a 3.3 installation. The #27 patch does allow us now to see/edit the UND message types in UI. But still the translated activity streams won't get displayed and currently the only way is override the UND message types.

Changing the status back to "active".

slowflyer’s picture

After one raining saturday ...

Using the latest dev of Entity API (https://drupal.org/project/entity) from 30th September solves this .... (insert what ever you like to) issue!

daniel.c’s picture

Thank you! The latest Entity API dev fixed it.

Devin Carlson’s picture

Status: Active » Postponed (maintainer needs more info)

@slowflyer and @daniel.c Commons now includes #2006702: Support for undefined language which gives admins the ability to modify messages with an undefined language, making me think that we shouldn't include #1782134: Translatable fields: Not overriding language-none values with empty default-language values anymore.

Updating to the latest -dev of Entity API would remove the patch from #1782134: Translatable fields: Not overriding language-none values with empty default-language values which sounds like what you are looking for. Are your issues solved by downloading the 7.x-1.2 stable release of Entity API and using it instead of the patched version of Entity API included with Commons?

slowflyer’s picture

Using the the stable 7.x-1.2 without the patch works as well.

In this case, the patch seems not to work correct, because I have translations in the different languages and in this case LANGUAGE_NONE texts should not be copied over.

function entity_metadata_field_get_language($entity_type, $entity, $field, $langcode = LANGUAGE_NONE, $fallback = FALSE) {
  // Try to figure out the default language used by the entity.
  // With Drupal >= 7.15 we can use entity_language().
  if (function_exists('entity_language')) {
    $default_langcode = entity_language($entity_type, $entity);
  }
  else {
    $default_langcode = !empty($entity->language) ? $entity->language : LANGUAGE_NONE;
  }

  // Determine the right language to use.
  if ($default_langcode != LANGUAGE_NONE && field_is_translatable($entity_type, $field)) {
    // If the field has a value under LANGUAGE_NONE and doesn't have a value
    // under the default language, don't force the default language.
    if (empty($entity->{$field['field_name']}[$default_langcode]) && !empty($entity->{$field['field_name']}[LANGUAGE_NONE])) {
      return LANGUAGE_NONE;
    }

    $langcode = ($langcode != LANGUAGE_NONE) ? field_valid_language($langcode, $default_langcode) : $default_langcode;
    if (!isset($entity->{$field['field_name']}[$langcode]) && $fallback) {
      $langcode = $default_langcode;
    }
    return $langcode;
  }
  else {
    return LANGUAGE_NONE;
  }
}

Looks like that the arriving entity has not a language defined...
This leads to an icorrect
$default_langcode = entity_language($entity_type, $entity);

and wrong language selection afterwards

daniel.c’s picture

Same here. Downloading and using the the stable 7.x-1.2 without the patch included in Commons 3.3 also solved the issue for me.

Devin Carlson’s picture

Status: Postponed (maintainer needs more info) » Needs review
FileSize
631 bytes

@slowflyer nice catch! I've posted an updated patch at #1782134-5: Translatable fields: Not overriding language-none values with empty default-language values for testing.

The attached patch updates the Commons make file to include the new patch.

Devin Carlson’s picture

As #1782134: Translatable fields: Not overriding language-none values with empty default-language values is a "won't fix" I think that we should document how to translate messages and remove the current patch to Entity API from the make file. For an easier setup we can look at Message integration in Lingotek #2097083: Message API messages are not translated or for Message to handle language fallback itself #1781884: If no text exists fallback to default language or LANGAUGE_NONE.

The attached patch removes the patch to Entity API from the make file.

Devin Carlson’s picture

Status: Needs review » Fixed

Automatically closed -- issue fixed for 2 weeks with no activity.

Anonymous’s picture

Issue summary: View changes

Added explanation, that I only enabled Locale module and nothing more.

mariusm’s picture

Issue summary: View changes

Hello.

Locale does not work again for 7.x-3.9 and dev.

Thanks

PS.

I change message for my language( admin/structure/messages )and it's work now

tanius’s picture

Some explanations for all of us who run into this issue in new Drupal Commons installations (like @mariusm in #44):

When starting with a non-localized Drupal installation, message types are created with LANGUAGE_NONE. When later enabling module locale, a default language (with empty field values) is added for message types. Because the default language is used as the only fallback, it causes messages to be rendered empty (everywhere: activity stream, notification e-mails etc.). This issue will be finally fixed via #1782134: Translatable fields: Not overriding language-none values with empty default-language values (here mentioned in #18), which will treat LANGUAGE_NONE as an additional fallback.

You can already install the patch provided in that issue, or alternatively use this workaround: use the message batch text copy feature ( admin/config/system/message/text-copy ) to copy over all text from the LANGUAGE_NONE version to your default language of message types. It seems to me that this is also the workaround solution that was automated in the Commerce Backoffice project [see], also affected by this issue.

For how to translate messages manually, see #1962586: How can I translate messages?.

webadpro’s picture

@tanius, Thank you very much for your workaround with admin/config/system/message/text-copy.

This sure did fix the issue I was having with different languages.

But I wish https://drupal.org/node/1782134 would be commited!

Chipie’s picture

On my site the messages are shown using the LANGUAGE_NONE settings. Does anyone know why the messages are not shown in the default language? If copy the text from my default language to LANGUAGE_NONE, the messages are shown, but if people with other languages login, the messages are not translated?

rubofvil’s picture

bdupls’s picture

Thanks the work around to copy messages from language neutral to your sites default language in my case English worked. Shouldn't there be a fix or warning to do this included in the code?