Forum Replies Created

Viewing 15 replies - 1 through 15 (of 19 total)
  • Thread Starter fgirard

    (@fgirard)

    Thanks a lot! Do you want me to send you the French translation files?

    Thread Starter fgirard

    (@fgirard)

    Moreover, you need to add the following in function plugin_init() of woo-paypal-pro.php.. if not, the strings will not show up to be translated and will be ignored:

    load_plugin_textdomain('woocommerce', false, dirname(plugin_basename(__FILE__)) . '/languages/');

    This assumes that the language files will be added to “languages” subfolder.

    Once those changes are done, I will create the French translation files.. I will gladly send them to you if you want to include them in your plugin, may attract more usage.

    Please advise.

    Thread Starter fgirard

    (@fgirard)

    Hi there,

    Thanks for looking into this. Looks good. However, you do not have provision to translate the payment title, which is configured in the admin… Does it really need to be configurable?

    This is the fix that I came up with for now, but you may want to think about it….
    In the constructor of woo-paypal-pro-gateway-class.php:

    // Title needs to be static if we want to translate it (unless we want to add a field per language or have table or comma delimitted array in that one field)
    // If the field is populated, it will grab the value from there and will not be translated.  If it is empty, it will use the default and translate that value
    $this->title = strlen($this->settings['title']) > 0 ? $this->settings['title'] : __('Credit Card Payment', 'woocommerce');

    What do you think? To me, translation supersedes configuration, but, I may be biased by my use case ??

    Please advise

    Thread Starter fgirard

    (@fgirard)

    Any updates? This would benefit the author od this support thread:
    link

    Hi NadGu, I myself translated it for French as per this thread – link

    All you would need to do is add an MO file for Spanish. However,I am still waiting to hear back from the authors of the plugin to see if they want to incorporate my changes in the official plugin… starting to run out of hope.

    Thread Starter fgirard

    (@fgirard)

    Any update on this?

    Thread Starter fgirard

    (@fgirard)

    Alright so it turns out that this change is a little more involved as we do not want to interfere with the woocommerce language files. I have translated the whole plugin to be in both English and French and made the appropriate code changes. I was not too sure as to what strategy you guys would be confortable with for the Option title as it is dynamically set in the admin plugin option…

    For now, I made it backward compatible and code it as per below:

    // Title needs to be static if we want to translate it (unless we want to add a field per language or have table or comma delimitted array in that one field)
    // If the field is populated, it will grab the value from there and will not be translated.  If it is empty, it will use the default and translate that value
    $this->title = strlen($this->settings['title']) > 0 ? $this->settings['title'] : __('Credit Card Payment', 'woocommerce-paypal-pro-payment-gateway');

    I suggest that I zip up my version of the plugin and send it to you guys via email. You can then use a text compare (like Beyond Compare) to evaluate my changes and decide if you want to include them in your plugin. It would add alot of value to me as I do not really want to re-apply my changes everytime you guys release a new version…

    Thanks and looking forward to hear back from you!

    Thread Starter fgirard

    (@fgirard)

    FYI – flush_rewrite_rules() at the very least twice by request by the following plugin -> Hyyan WooCommerce Polylang Integration

    Will contact their support…Thought I would let you know as this plugin was written around PolyLang….

    New topic -> https://www.ads-software.com/support/topic/flush_rewrite_rules-being-called-on-every-request

    Thread Starter fgirard

    (@fgirard)

    Marking this as resolved

    Thread Starter fgirard

    (@fgirard)

    Thanks a lot for your help Chrystl, appreciate it. I will look that those rewrite rules refreshes.

    Thanks again!

    Fred

    Thread Starter fgirard

    (@fgirard)

    Hi there, I removed the translation of course to cours from the PO file and it seemed to have done the trick. I no longer have 404s. However, I feel a little dirty leaving this like that not knowing exactly why it gives random 404s only when PolyLang is activated… When polylang is not activated, my links are generated as https://www.wformation.com/cours/apprenez-a-creer-vos-tisanes-therapeutiques-ebook/ and when Polylang is activated, they are generated as https://www.wformation.com/course/apprenez-a-creer-vos-tisanes-therapeutiques-ebook/.

    So it seemes that PolyLang is preventing the post types from being translated in the links and rewrite rules, but that it randomly fails doing so.

    Thread Starter fgirard

    (@fgirard)

    Alright,I have more info. I temporarily altered class-wp.php to dump the rewrite rules when there is a 404 (handle_404 method). The issue is that the post type is not translated in the rewrite rules..

    When we get a 404, we have the below in the rewrite rules (sorry for the repeated rule0, forgot to increment the counter :S and was too lazy to do it again ?? ):
    [18-Jan-2016 06:30:32 UTC] rule0: cours/[^/]+/attachment/([^/]+)/?$ rewrite: index.php?attachment=$matches[1]
    [18-Jan-2016 06:30:32 UTC] rule0: cours/[^/]+/attachment/([^/]+)/trackback/?$ rewrite: index.php?attachment=$matches[1]&tb=1
    [18-Jan-2016 06:30:32 UTC] rule0: cours/[^/]+/attachment/([^/]+)/feed/(feed|rdf|rss|rss2|atom)/?$ rewrite: index.php?attachment=$matches[1]&feed=$matches[2]
    [18-Jan-2016 06:30:32 UTC] rule0: cours/[^/]+/attachment/([^/]+)/(feed|rdf|rss|rss2|atom)/?$ rewrite: index.php?attachment=$matches[1]&feed=$matches[2]
    [18-Jan-2016 06:30:32 UTC] rule0: cours/[^/]+/attachment/([^/]+)/comment-page-([0-9]{1,})/?$ rewrite: index.php?attachment=$matches[1]&cpage=$matches[2]
    [18-Jan-2016 06:30:32 UTC] rule0: cours/([^/]+)/trackback/?$ rewrite: index.php?course=$matches[1]&tb=1
    [18-Jan-2016 06:30:32 UTC] rule0: cours/([^/]+)/page/?([0-9]{1,})/?$ rewrite: index.php?course=$matches[1]&paged=$matches[2]
    [18-Jan-2016 06:30:32 UTC] rule0: cours/([^/]+)/comment-page-([0-9]{1,})/?$ rewrite: index.php?course=$matches[1]&cpage=$matches[2]
    [18-Jan-2016 06:30:32 UTC] rule0: cours/([^/]+)/wc-api(/(.*))?/?$ rewrite: index.php?course=$matches[1]&wc-api=$matches[3]
    [18-Jan-2016 06:30:32 UTC] rule0: cours/[^/]+/([^/]+)/wc-api(/(.*))?/?$ rewrite: index.php?attachment=$matches[1]&wc-api=$matches[3]
    [18-Jan-2016 06:30:32 UTC] rule0: cours/[^/]+/attachment/([^/]+)/wc-api(/(.*))?/?$ rewrite: index.php?attachment=$matches[1]&wc-api=$matches[3]
    [18-Jan-2016 06:30:32 UTC] rule0: cours/([^/]+)(/[0-9]+)?/?$ rewrite: index.php?course=$matches[1]&page=$matches[2]
    [18-Jan-2016 06:30:32 UTC] rule0: cours/[^/]+/([^/]+)/?$ rewrite: index.php?attachment=$matches[1]
    [18-Jan-2016 06:30:32 UTC] rule0: cours/[^/]+/([^/]+)/trackback/?$ rewrite: index.php?attachment=$matches[1]&tb=1
    [18-Jan-2016 06:30:32 UTC] rule0: cours/[^/]+/([^/]+)/feed/(feed|rdf|rss|rss2|atom)/?$ rewrite: index.php?attachment=$matches[1]&feed=$matches[2]
    [18-Jan-2016 06:30:32 UTC] rule0: cours/[^/]+/([^/]+)/(feed|rdf|rss|rss2|atom)/?$ rewrite: index.php?attachment=$matches[1]&feed=$matches[2]
    [18-Jan-2016 06:30:32 UTC] rule0: cours/[^/]+/([^/]+)/comment-page-([0-9]{1,})/?$ rewrite: index.php?attachment=$matches[1]&cpage=$matches[2]

    Where the rule is “cours”, it should say “course”.. I really think that the translation part is not forced to happen in the proper sequence…

    Any ideas?

    Thanks, Fred

    Thread Starter fgirard

    (@fgirard)

    Hi Chrystl,

    Could it be that some of the Polylang filters / action do not always get triggered at the same time.. ie.. if the priority is not set right, could it be that sometimes, it gets triggered out of sequence with something else using that filter/action? That would be the only thing that makes sense to me… Do you have any suggestions as to where/what debug logs I could put to help troubleshoot this?

    Please advise and thanks for your help.

    Thread Starter fgirard

    (@fgirard)

    No

    Thread Starter fgirard

    (@fgirard)

    Hi Chrystl,

    #.VpkKIl7OWR4/ was actually not a noonce code, but a tracking url code used by the AddThis plugin. I removed the below 2 lines from one of my php file and the code is no longer showing, thanks for pointing this out! However, the 404s are still happening without that code…

    <script type="text/javascript">var addthis_config = {"data_track_addressbar": true};</script>
                <script type="text/javascript" src="//s7.addthis.com/js/300/addthis_widget.js#pubid=ra-53449bcc28225d70"></script>
                <!-- AddThis Button END -->
Viewing 15 replies - 1 through 15 (of 19 total)