Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
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.
Comments
Comment #1
taraluktus CreditAttribution: taraluktus commentedJust 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.
Comment #2
VVS CreditAttribution: VVS commentedIn Russian too.
If disable module Locale 7.20 - activity is OK.
Comment #3
Softovick CreditAttribution: Softovick commentedExactly the same problem in Russian
Comment #4
taraluktus CreditAttribution: taraluktus commentedBug 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?
Comment #5
VVS CreditAttribution: VVS commentedI 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...
Comment #6
taraluktus CreditAttribution: taraluktus commentedYes, 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.
Comment #7
ezra-g CreditAttribution: ezra-g commentedIf reproducible, this would be major in priority.
Comment #8
taraluktus CreditAttribution: taraluktus commentedI 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.
Comment #9
morphay CreditAttribution: morphay commentedif the module Loсal was not turned on even once, then the messages in admin/structure/messages are present.
Comment #10
morphay CreditAttribution: morphay commentedComment #11
taraluktus CreditAttribution: taraluktus commentedAnd they are back again when you turn off the Locale module when it previously was turned on.
Comment #12
slowflyer CreditAttribution: slowflyer commentedMy 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 ...
Comment #13
ezra-g CreditAttribution: ezra-g commentedAdding to our Commons 7.x-3.1 radar.
Comment #14
ezra-g CreditAttribution: ezra-g commentedjaperry volunteered to triage.
Comment #15
japerryAfter 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.
Comment #16
taraluktus CreditAttribution: taraluktus commentedThank you!
Comment #17
japerryOkay 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.
Comment #18
taraluktus CreditAttribution: taraluktus commentedYour 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
Comment #19
japerryCommitted the locale fix patch to the drupal-org make file:
http://drupalcode.org/project/commons.git/commit/c389385
Comment #20
ezra-g CreditAttribution: ezra-g commentedRe #18, the referenced Message module issue is #1935784: Message: Rendered Message does not render properly when locale is enabled and the related Entity API issue is #1782134: Translatable fields: Not overriding language-none values with empty default-language values.
Comment #21
hansfn CreditAttribution: hansfn commentedRelated issue with work-around for translating activity stream - #1968238: Translation of activity stream / messages.
Comment #22
ezra-g CreditAttribution: ezra-g commentedAdding this issue to the 3.4 radar.
Comment #23
japerryRe-marking active as part of the i18n push.
Comment #24
Devin Carlson CreditAttribution: Devin Carlson commentedMarked #2075105: Cannot edit message type as a duplicate.
Comment #25
Devin Carlson CreditAttribution: Devin Carlson commentedI 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.
Comment #26
ezra-g CreditAttribution: ezra-g commentedSince 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?
Comment #27
Devin Carlson CreditAttribution: Devin Carlson commented@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.
Comment #28
Devin Carlson CreditAttribution: Devin Carlson commentedCommitted #27 to Commons 7.x-3.x.
http://drupalcode.org/project/commons.git/commit/4265836
Comment #29
slowflyer CreditAttribution: slowflyer commentedUsing 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.
Comment #30
ezra-g CreditAttribution: ezra-g commentedPlease let us know if you can reproduce with a fresh install of the latest dev of Drupal Commons.
Comment #31
Devin Carlson CreditAttribution: Devin Carlson commented@slowflyer did you add a filter to the activity stream view in order to restrict it to the current user's language?
Comment #32
slowflyer CreditAttribution: slowflyer commented#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!
Comment #33
slowflyer CreditAttribution: slowflyer commentedIt still happens with a fresh install of latest dev from 2nd October
Comment #34
daniel.c CreditAttribution: daniel.c commentedJust 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".
Comment #35
slowflyer CreditAttribution: slowflyer commentedAfter 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!
Comment #36
daniel.c CreditAttribution: daniel.c commentedThank you! The latest Entity API dev fixed it.
Comment #37
Devin Carlson CreditAttribution: Devin Carlson commented@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?
Comment #38
slowflyer CreditAttribution: slowflyer commentedUsing 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.
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
Comment #39
daniel.c CreditAttribution: daniel.c commentedSame 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.
Comment #40
Devin Carlson CreditAttribution: Devin Carlson commented@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.
Comment #41
Devin Carlson CreditAttribution: Devin Carlson commentedAs #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.
Comment #42
Devin Carlson CreditAttribution: Devin Carlson commentedCommitted #41 to Commons 7.x-3.x.
http://drupalcode.org/project/commons.git/commit/d568689
Comment #43.0
(not verified) CreditAttribution: commentedAdded explanation, that I only enabled Locale module and nothing more.
Comment #44
mariusm CreditAttribution: mariusm commentedHello.
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
Comment #45
tanius CreditAttribution: tanius commentedSome 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?.
Comment #46
webadpro CreditAttribution: webadpro commented@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!
Comment #47
Chipie CreditAttribution: Chipie commentedOn 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?
Comment #48
rubofvil CreditAttribution: rubofvil commentedCopied the patch(https://www.drupal.org/files/entity-translatable_fields_not_overriding_u...) to work in the module entity "7.x-1.5".(Commons 3.12)
Comment #49
bdupls CreditAttribution: bdupls commentedThanks 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?