[George]

Cool, thanks for the update. Best of luck with your site!

— George

[George]

Hey Thierry,

I cannot specify a time or date but we are working very hard on approving as many translations as possible and it should not be more than a few days. We will broadcast when the translations are updated.

Thanks for your patience!
George

[George]

Hey Mark,

Apologies for the delayed response – your idea about adding additional conditionals to the is_404() check is exactly my thinking, too, and hopefully will work here.

Something like this might help:

if ( is_404() && ! tribe_is_month() && ! tribe_is_week() ) {

}

Now, this conditional might not look super neat and clean, but in theory it should work quite well. We have conditionals for all of the calendar views, in the same patterns as the Month- and Week-view conditionals shown above – you can see a list of them here: https://gist.github.com/jo-snips/2415009

Use as many of those conditionals as you need here in the same pattern as above, and it should work quite well. I’m sorry that this is the best solution that comes to mind, but it’s odd that your theme is handling this so stringently (as evidenced by the fact the 2015 did not…)

Let us know if adding conditionals helps at all!

Thanks, and thanks for your patience while we dug into this issue 🙂
George

[George]

Hey James,

I’m sorry that WooCommerce add-on didn’t work out, but I really appreciate your update here and for being cool and understanding about some of the software limitations we face right now. Hopefully over time our tickets add-ons only get more closely integrated with the eCommerce platforms that are their namesakes, but for now, I’m glad you’ve at least got a workable solution in place.

Thanks James, best of luck with your site. If other questions/comments/concerns arise, come back to the forums and open a new thread any time 🙂

Cheers!
George

[George]

Thanks Pascal.

For everyone on this thread, please stay tuned to this ticket while work on approving translations.

Thanks!
George

[George]

Thanks Pascal.

For everyone on this thread, please stay tuned to this ticket while work on approving translations.

Thanks!
George

[George]

Hi Rob,

This is a customization outside of the scope of support we can provide, and while I can relate to your frustrations with that, let me explain why this is a bigger customization to make than it seems.

I’ve understood your request well, and answered it accurately:

Unfortunately, there is little that can be done to change the PayPal.com purchase page screen itself.

Now, here are the reasons why this is the case:

1. The PayPal request at checkout is sent by WooCommerce, not our own plugin, so we’re confined by what information WooCommerce will accept to send to PayPal. In other words, if WooCommerce does not allow a way to send richer product descriptions to PayPal, then nothing about our desires to do so will change that.

2. PayPal itself only accepts certain data via its public API. So in the same way we are limited by WooCommerce, WooCommerce is limited by PayPal.

3. We don’t own PayPal, so if we want to enable richer data on the checkout pages on paypal.com, but they don’t provide it, we can’t do much – if anything – to change that.

These are all inherent limitations in the way things currently are, nothing personal about us trying to not help you or anything like that.

In fact, quite the opposite – we’re happy to help as much as we can here, and as an example of what little customization CAN be done for the PayPal checkout pages, I will walk you through some code here.

My comment about how we “don’t own PayPal” is a little obtuse, admittedly, but it truly is the limitation we cannot get around here. However, WooCommerce is a bit more flexible. We don’t own that either, but it’s open source code that you host yourself that we can edit a bit.

So let’s do that now.

To change the data that shows up in the section you highlighted on the paypal.com checkout screens, you’ll need to find where WooCommerce makes its API request to PayPal for purchasing the tickets.

You can find the specific line of code where this happens in a method called add_line_item() in this file within WooCommerce:

woocommerce/includes/gateways/paypal/includes/class-wc-gateway-paypal-request.php

In that method, there is a block of code like this:

$this->line_items[ 'item_name_' . $index ]   = html_entity_decode( wc_trim_string( $item_name, 127 ), ENT_NOQUOTES, 'UTF-8' );
$this->line_items[ 'quantity_' . $index ]    = $quantity;
$this->line_items[ 'amount_' . $index ]      = $amount;
$this->line_items[ 'item_number_' . $index ] = $item_number;

The “item_name_” item there is the one that dictates the text used in the area of the PayPal.com checkout page that you highlighted. This is a screenshot of those item names for me from my test site → https://cloudup.com/cpxLfhpuvLc.

If you change the value of that array item to something else, then that value will be used instead. As an example, if you try this:

$this->line_items[ 'item_name_' . $index ]   = 'Test!';

Then the names at checkout will read like this: https://cloudup.com/cYvj4yqHZdZ

Now, to actually make a customization to that value, do not make it right within that add_line_item() method. Head up to the prepare_line_items() method instead, and look for where add_line_item() is actually called from. It should look like this:

$this->add_line_item( $item['name'], 1, $item['line_total'] );

Instead of $item[‘name’], this is where you can add whatever you want. You can dive into this code and var_dump( $item ); to see what attributes you have on $item itself, or you can use something custom altogether there and use any info you need. As a final quick example, to make the same modification that displays ‘Test!’ text, you’d add that to the function like so:

$this->add_line_item( 'Test!', 1, $item['line_total'] );

The result: https://cloudup.com/cYvj4yqHZdZ

Hopefully this helps. I would not recommend making core code edits to WooCommerce like this, since you will lose the code after the next time you update it and have to re-add the customization, but this is how to do it.

— George

[George]

Hey Everyone,

I’m glad that you’ve found temporary solutions here – unfortunately, however, we tried very very hard to recreate these problems on our testing sites, and failed.

I’m sorry to bear that news, but we tried many ways to produce this problem with no luck and even ran the plugin on a German translation to see if that was a factor.

If you’re happy with your solutions for now, that’s fine, but if you’re interested in diving even deeper with this problem, we’d love to hear what you find if you run through the troubleshooting steps outlined here and then try to recreate your problems → https://theeventscalendar.com/knowledgebase/testing-for-conflicts/

This seems like it is ultimately a theme or plugin conflict. I hope your temporary solutions work well for now, regardless.

Thank you!
George

[George]

Sounds good Steffen, thanks for the update!

Best of luck with your project,
George

[George]

Glad to hear it Alex!

Best of luck with your site 🙂
— George

[George]

The file names are indeed okay Pascal, I know I’ve already mentioned but just to say it again – we are working to approve translation submissions as fast as possible, so if you still problems with .mo and .po files from the translations site itself, it’s just a temporary problem while the translation is being brought up to speed.

Thank you for your patience with us and with this process,
George

[George]

Hi,

Translations may still be broken for a specific language because it has not been fully translated yet. We are approving translation submissions as fast as possible.

In general, however, yes you can just export .mo and .po files directly from http://translations.theeventscalendar.com and replace the pre-existing files for that language in your plugins /lang folder.

Thank you all for your patience while we receive translation submissions and work through the approval process for them one at a time. Thank you!

[George]

Hey @pedarthe,

I’ve been very vocal in that thread helping you and we are not being quiet about this. We are working very hard to bring every one up-to-speed here!

Let’s all review the problem as it stands right now – all of your collective patience is greatly appreciated, but hopefully the following review of things will give us all a better sense of the changes here and how we are trying very very hard to help:

Translations Break on Every Update

This is a known problem with any plugin or theme update, and even WordPress Core updates. When code changes, that means the strings within the code change, too. This renders translations that were made before the update unusable, or at least with problems like having only some words translated while other words remain in English.

Our New Translation System Solves this Faster

Yes, it has been a bit of time since the 3.10 update and we’re still working on bringing translations up-to-date. But this is still faster than with our original methods – we have to rely on community members to help with translations, since we don’t speak every language here at Modern Tribe, so regardless of the method we have to accept translations from the community to include them in the plugin.

The old method required everyone who wanted to submit a translation to translate every string in the language, then submit manually via the forum, then have us review the entire translation one at a time and then make other updates to the plugin to share them with others!

Now, you can contribute just a word or two, and once translations are approved, people can just go to the translations site and export .mo and .po files any time they want.

Translation files are broken for you because the translation is out of date

If the files you’re using don’t seem to translate everything, then it’s just because of the problem I mentioned above: updates break translations, and your language has not been fully converted yet.

We’re manually approving translations to ensure that your language is converted

To address the problem of broken translation files, we’re accepting translations. We are receiving many and have to manually approve them to ensure quality and prevent common sources of breakage.

---

Hopefully this breakdown gives everyone a better sense of where things stand. If your language’s translation files aren’t working, it’s because they’re out of date still, at this time. We are working to approve submissions for each language as fast as possible. It’s better than the old system, faster too, but I understand all of your frustrations with the delays. We take your time and your websites seriously and are working on approving translations as fast as possible.

Thank you immensely for your patience with us as we update everything!

George

[George]

Hi,

If the .po files do not work in po-edit, it is because the translations are not properly coded. This is the reason we have to manually approve submissions, which we are working to do as fast as possible!

Until the new translation submissions are approved, the exported files from the Translations site will not work or include the new translations. We are working as fast as possible to update the translations so they work.

Thank you all for your patience, this is not something we’re taking lightly and are receiving many translation submissions. We need to approve the right ones.

Thank you,
George

[George]

Hey Darkey,

The strings will be approved as soon as possible by one of us on the support team. We are working through translations and bringing everything up-to-date as fast as possible.

Thank you for your patience,
George

[Author]

Posts