Skip to:
Content
Pages
Categories
Search
Top
Bottom

Regarding 2.7.5

  • Avatar of chestnut_jp
    chestnut_jp
    Member

    @chestnut_jp

    @dwenaus

    Continued from the topic:
    http://buddypress.org/community/groups/buddypress-group-email-subscription/forum/topic/japanese-translation-ready-and-some-customization-for-1-2-7/

    Though I said new changes are essential, the plugin seems to work fine after upgrading to 2.7.5 without any new changes. So, I would like to test the plugin as it is.

    However, there is just one point I must say, that some part of the plugin cannot be translated due to “global $bp”.

    For instance, notifications page remains in English, due to “global $bp” in “function ass_admin_notice_form” in bp-activity-subscription-functions.php, and, as I mentioned somewhere before, “Email Options” also does due to “global $bp” in “function group_activity_subscription” in bp-activity-subscription-main.php.

    As for “Email Options”, I had changed the original as following:
    [ Original ]
    $this->name = “Email Options”;

    [ Changed ]
    $this->name = __(‘Email Options’, ‘buddypress’);

    Perhaps, this is the reason why @lovesaif said before that “Email Options” is not translated , and not included in the pot file. I had no choice…

    Well, as to notifications page, all words can be translated if we add translation to the language file for “BuddyPress”, just like “Email Options”, however, it is not the correct manner.

    So, someone please tell me how to specify language file within global $bp. It is very much important for the plugin to work.

    Of course, I also am thinking about the good solution.

Viewing 11 replies - 1 through 11 (of 11 total)
  • Avatar of chestnut_jp
    chestnut_jp
    Member

    @chestnut_jp

    @dwenaus

    As I am exhaused, just post the new plugin packaged by me.
    This package has important changes.
    Please save backup first and replace the whole plugin with my package, and verify how it works.

    I will post “what’s new” here or in a new topic tomorrow.

    The new package, named “buddypress-group-email-subscription-2.7.5.1.zip” is avaiiable at:
    http://staff.blog.bng.net/downloads/buddypress-group-email-subscription-2.7.5.1.zip

    @lovesaif
    This new package can translate “Email Options” and “notification pages” when you have language file. The language file is changed from “buddypress-group-email-subscription-$local.mo” to “bp-ass-$local.mo”. Names of the pot file, along with Japanese translation, stored in this package are changed accordingly.

    Avatar of Dwenaus
    Dwenaus
    Participant

    @dwenaus

    the problem is that the translated file is using ‘buddypress’ and it should be using ‘bp-ass’

    I’ve also changed ‘To disable these notifications please log in and go to: %s’ to bp-ass as well as ‘Group Forum’, ‘Yes’ and ‘No’ so add those to your new file as well.

    I also recreated the pot file i’ll email it if you give me your email address.

    Avatar of chestnut_jp
    chestnut_jp
    Member

    @chestnut_jp

    Note: this is moved to http://buddypress.org/community/groups/buddypress-group-email-subscription/forum/topic/regarding-2-7-6/

    Please do not reply to this topic but the above, thank you.

    @dwenaus
    Thanks for releasing the new version.
    Though I am still searching the reason, because sometimes “cache” cause something wrong, updated to the new version doesn’t show Japanese any more.

    Looking at your-made pot file, some words seems to be deleted from my original pot, ex: “yes”, “no”, or “Yes”, “No”, all of which you mentioned, were already in my pot file, but they are disappeared.

    Some words were using “buddypress” because they were not translated, for unknown reason or maybe due to the definition of “global $bp”, or they are existing buddypress.

    As for “date_default_timezone_set”, it might affect other plugin or BP settings.
    Setting the “date_default_timezone_set(‘America/New_York’);” in the “bp-activity-subscription-digest.php” may not affect, while setting it to “date_default_timezone_set(‘Asia/Tokyo’);” may result in that the time displayed in activity stream shows “sometime ago” instead of “0 second ago” or “10 minutes ago” unless that activity passes a long time, due to the time zone difference from UTC.

    This happens because, in bp-core.php file, the time displayed in the activity stream was decided by “$since = $newer_date – $older_date;”, and the older_date goes bigger than newer_date accoring to the setting of “date_default_timezone_set” in this plugin.

    This is not only this plugin but some other plugins appear to have the same problem.

    Because I first did not notice the reason why the time displayed “sometime ago”, which is not this plugin’s fault but others that are already disabled, I reported it as buddypress bug. Nevertheless, the reason is not buddypress but plugins.

    I will send you my email address via email.

    Please once again review my new customized package available at:
    http://staff.blog.bng.net/downloads/buddypress-group-email-subscription-2.7.5.1.zip

    This package is not included cron bug fixed, though.

    I will continue to verify your new version.

    P.S.:
    Your made pot file has some error due to \r\n, which should be \n only.
    So, please continut using my pot file.

    I will add or change after comparing with your pot file.

    Avatar of Dwenaus
    Dwenaus
    Participant

    @dwenaus

    about the timezone issue – this is not an issue with the plugin, it is a wordpress/PHP issue. so just set this at the top of your wp-config.php file.
    `date_default_timezone_set(‘America/Chicago’);`
    or
    `date_default_timezone_set(‘UTC’);`
    see this post for more info http://wordpress.org/support/topic/php-530-amp-wp-28-it-is-not-safe-to-rely-on-the-systems-timezone?replies=33 (see otto’s post)

    but chestnut_jp insists that you ignore this message. read below for more info.

    Avatar of chestnut_jp
    chestnut_jp
    Member

    @chestnut_jp

    @dwenaus
    Yes, it is a PHP issue, but all of you have misunderstood.

    I told about the reason why we had to set date_default_timezone_set in the plugin script when I first released my customized version.

    Look at around line 32 of wp-settings.php, located in root place of WP installation.
    It reads:
    `// Set default timezone in PHP 5.
    if ( function_exists( ‘date_default_timezone_set’ ) )
    date_default_timezone_set( ‘UTC’ );`

    This means that even if you set date_default_timezone_set in php.ini or so, WP ignores it and set it to UTC as default.

    As you know, wp-settings.php is not subject to customization, and this setting is added “perhaps” when WP went 3.0, I think this is not WP bug but something meaningful.

    In fact, some plugins, including buddypress, use UTC as default and when I change UTC that WP set as default to “Asia/Tokyo”, such plugins show wrong time.

    For example, though I am not yet reporting to the author, the plugin “vistor matps” which I appreciated very much, changes somehow the timezone from UTC to local one as default, and buddypress shows wrong time. This is why I stopped using this plugin along with buddypress, but with only blogs.

    Adding “date_default_timezone_set” into wp-config.php or functions.php is, yes, one of ways to show the right timezone.
    However, concidering the fact that even when we set timezone in php.ini, WP changes it to UTC, I do not think it is the good solution to add date_default_timezone_set to wp-config.php that has influence overall the site.

    If you dare to let date_default_timzone_set you set in php.ini or some other place, to prevail over the site or network, the only way and the best way is deliting the setting of wp-settings.php as following:

    `// Set default timezone in PHP 5.
    //if ( function_exists( ‘date_default_timezone_set’ ) )
    // date_default_timezone_set( ‘UTC’ );`

    And if this is correct fix, this setting of wp-settings.php must be a buf in WP.

    For these reason, I have concluded that each plugin provides the way to show the right localtime zone as needed.

    Since the global function has a power just within function clause, my fix does not have any influence on all over the site but only the plugin itself.

    In my 2.7.5.2, I already fixed the bug that selecting daily delivery time at backend is not set to the right time, and I added “digest_schedule_print()” in “ass_digest_fire_test()” in order to see if users set really right time and “Scheduled:”, “Until:” and “hours” have become subject to translation.

    But, as it is not polite to force users write their own timezone directly in the script, I am now preparing the backend admin control to make my 2.7.7.1.

    It will take some more time as I still am testing the original 2.7.7 to see if there are potential bugs.

    I hope you will now understand why I repeatedly claim that date_default_timezone_set must be in the plugin.

    Please also refer to the php document:

    http://php.net/manual/en/function.date-default-timezone-set.php

    Avatar of Dwenaus
    Dwenaus
    Participant

    @dwenaus

    we should add an action hook in the plugin so people like yourself can hook into it. and others can ignore it. It should go inside a function.

    Avatar of chestnut_jp
    chestnut_jp
    Member

    @chestnut_jp

    @dwenaus
    Sounds nice!
    As I have been busy, it may take some time for me to proceed.
    Well, I tried adding “date_default_timezone_set” to wp-config.php, but in vain.
    It does not work as I expected.
    Is it really working for you?

    Anyway, it is very good news that you will make hook for persons like me.

    Avatar of Dwenaus
    Dwenaus
    Participant

    @dwenaus

    i am ignoring this totally, and everything works fine.

    Avatar of chestnut_jp
    chestnut_jp
    Member

    @chestnut_jp

    @dwenaus

    Oh, I see.

    In the latest plugin, you warn that if date_default_timezone_set is needed, it should be added to wp-config.php. This is completely misguiding users. Please delete it.

    And people who do not mind calculating the delivery time, comparing local timezone to UTC, just like you, do not care how local timezone is ignored even when it is defined in php.ini.

    But, as the plugin shows server timezone, which is forced to change to UTC by wp-settings.php, people like me very much care the reason why my local timezone setting disappears and are eagerly wanting to fix it.

    Calculating delivery time based on UTC, sometimes make users set it to the wrong time.

    That is why I added “Next Scheduled Time” in the preview mode.

    I would like to let you know the truth.

    Discussions at http://wordpress.org/support/topic/php-530-amp-wp-28-it-is-not-safe-to-rely-on-the-systems-timezone?replies=33, you put above, is wrong in point that adding “date_default_timezone_set” to the top of wp-config.php.

    Because it can not work!!!

    Please look into wp-config.php once again.

    When I tried as Otto said, though I have long been saying that it is not the polite way to set “date_default_timezone_set” in wp-config.php, timezone was not changed to my local timezone.

    This is because wp-settings.php, which force to change “date_default_timezone_set” to UTC, is called at the end of wp-config.php.

    For this reason, adding “date_default_timezone_set” to the top of wp-config.php has no power.

    Adding it to the end of the file? Yes, it makes it! However, it is below the line saying “That’s all, stop editing!”, and it should be natural that timezone is changed to local timezone after wp-settings.php changes it to UTC, as it is the same as you do like following in wp-settings.php:

    `// Set default timezone in PHP 5.
    //if ( function_exists( ‘date_default_timezone_set’ ) )
    // date_default_timezone_set( ‘UTC’ );`

    After verifying the latest version, I would like to make my customized version based on it. After testing mine for some days, I will post it here like before.

    I am soory if my repetition irritates you, and I hope you will try mine to see how the plugin works conveniently.

    Avatar of Dwenaus
    Dwenaus
    Participant

    @dwenaus

    hi, i’ve edited the message telling people that you think it should be ignored. I’m sorry, I don’t have time to understand these complex issues about time zones that don’t affect my installation whatsoever. If you would like me to alter the plugin in a way that is beneficial, please just provide the code and ensure that it works without bugs – I will then put it in. If you’d like me to work with you in more detail to understand and fix the issue then I am available for paid work. email me at deryk@bluemandala.com. cheers. :)

    also, if you are only making small changes please don’t make a full new customized version – it is too much work for me to integrate into the main code base. Only do that if you make many many changes – like before. If you only make small changes please just make a diff file. or explain the changes. thanks.

    Avatar of chestnut_jp
    chestnut_jp
    Member

    @chestnut_jp

    @dwenaus

    Thank you for your kind reply.
    Yes, as always, I myself first make codes, then post what I changes, and then put the link to my customized package, which you can easily find where I change by searching the word “chestnut_jp”.

    As you point out, I will next time make two zips, one is just compressed customized files and the other is a full one. Of course, I will post what I changes here as ever.

    Timezone issue is such a confusing thing as long as we live on the earth…

Viewing 11 replies - 1 through 11 (of 11 total)

You must be logged in to reply to this topic.