Support

June 26, 2024 at 9:33 am

Hi there,

There is a new registration (or update) status “Not approved / Awaiting Review”. However there seems no translation for it. I already updated and synchronised the translation file, but cannot find this entry. See screenshot: https://pevaz.be/wp-content/uploads/2024-06-26_10h53_23.png

I’ve just updated our translations to make sure they are up to date.

Can you pull in the latest translation file from here:

https://translate.eventespresso.com/projects/event-espresso-4/

And let me know if that fixes it for you.

Second problem is that there seems to be an update on the date field…..

This I am currently investigating and will get back to you once we know more.

June 26, 2024 at 12:48 pm

I can obviously download the file from the repository above, but the problem is that this file is only translated for 79%

Earlier today the file was 99% translated, it’s now 79% because of new strings or amendments.

What file do you need to be able to update within Loco?

The latest POT file?

If you just update your current PO file with all of the latest changes within EE from the POT file you’ll find it will also drop to somewhere around 80%

Download it locally and test there using POEdit, you’ll see 🙂

I can sent you the POT file if you prefer to use that (A POT file is simply an empty translation file, it has all of the original strings and 0 translations, POEdit/Loco/Etc just read those strings and add/update them to your PO)

June 27, 2024 at 7:38 am

Loco translate automatically loads the latest version of the file.

What file? Where is Loco pulling the file from?

I do see that it updates to the version of yesterday, but also in this PO version only there is no translation string for “Not approved / Awaiting Review”

From where? GlotPress?

You manually updated to the version I sent you? Locotranslate will not automatically pull in that file.

Is it possible that you forget this string in the uploaded file?

Nope, its there 🙂

https://monosnap.com/file/wHRQ9zHun12sysi9Inq0L2nzjbrkI5

Thats just from me download the PO file from the GlotPress project and searching it within POEdit.

June 27, 2024 at 4:42 pm

Hello Tony, thanks for your help. I think it was a caching problem at my side. I have manually downloaded the PO file and now it’s ok.

Awesome! I’m glad it worked.

Would you already have an update on the second problem concerning the new date format?

We’ve found the issue causing it and currently working on a fix, as long as no issues are found from that fix we’ll push an update to fix this on Monday.

August 20, 2024 at 8:08 pm

Sorry to update this thread late.

We have EE update, have you tried if this issue is still existed on our latest update?

thanks

August 21, 2024 at 6:09 am

Awesome.. We will keep you updated with our testing and plugin update.

thanks

August 21, 2024 at 9:25 am

Hi Manuel,

Have you changed the date format in use on the site?

The problem you are running into right now is the date for that registration can be interpreted in different ways…. I’ll give you an example using a different value.

31/07/1975

Logically when we look at that value, we know it’s 31st of July, 1975.

However, PHP can’t work that out on its own and needs to know the date format its in, if we don’t pass a format PHP interprets ambiguous formats in the following ways:

/ separators may be interpreted as the American format m/d/Y, so 06/01/2000 will be parsed as June 1, 2000
- separators may be interpreted as the European format d-m-Y, so 06-01-2000 will be parsed as Jan 6, 2000

Knowing that, you can see that PHP is going to use 31/07/1975 as m/d/Y, 31st month isn’t valid and returns false when mean you see the dd/mm/yyyy placeholder.

—

Earlier on I asked what your sites date format is and you replied with:

The date format is set to belgium (dd/mm/jjjj).

But if that was/is the case then the new code we added to fix the datepicker input would have been able to work out the format, so has this changed? (I can see its not set to use that format currently).

To explain, what we do now is pull the value in form the Database and first try to process the value using the sites current date format (which with the date for that user and your current date format, will fail), then if that fails we try to process the date allowing PHP to work out the date (which, based on the above for this example will again fail) and eventually if all of that fails we return the original value set in the data (which is happening on your site but the date picker can’t process it… based on the format again.