https://www.dropbox.com/scl/fi/q86d92ujzr5dtvvdon4ho/s2member_it_IT.mo?rlkey=cftsvknwoe2q0ra8rv93dflq8&dl=0

In wordpress/settings/general I can only choose between English and Italian, I can’t see if Italian is coded exactly as it_IT, but I guess this is the standard.

I am willing to translate stripe proforms, above all, and all the entries “Your profile”, “Billing method” etc. have been translated in the .po / .mo files.

Best regards
Leo

Make sure the site language in WordPress > Settings > General exactly matches the locale used in the filename; for example, if the site language is it_IT , the file must be named exactly s2member-it_IT.mo

Does your .mo file include translation for the parts you’re expecting to be translated?

Here are translations contributed in the plugins directory, and as you can see they can be incomplete, so it’s possible that the mo file loaded but you’re looking at a part that isn’t translated. https://translate.wordpress.org/projects/wp-plugins/s2member/

Could you show me the .mo file? Not sure if you can attach it here, or in a private message, otherwise you can upload it to your site and give me the url to it.

Can anyone in the forums send me a working .mo file in any language, so that I can test it? Or maybe you have a .mo file yourself, Cristian?

Thanks again
best regards

s2member-v260320.0101.zip (1.4 MB)

It may improve reliability for custom .mo files placed in either of these locations:

• modern standard wp-content/languages/plugins/s2member-LOCALE.mo
• legacy fallback wp-content/plugins/s2member-LOCALE.mo

That said, if a specific .mo file still fails after this change, the next likely cause is the file itself or a site-specific conflict, rather than the load path.

s2member-v260320.0101.zip (1.4 MB)

It may improve reliability for custom .mo files placed in either of these locations:

• modern standard wp-content/languages/plugins/s2member-LOCALE.mo
• legacy fallback wp-content/plugins/s2member-LOCALE.mo

That said, if a specific .mo file still fails after this change, the next likely cause is the file itself or a site-specific conflict, rather than the load path.

I’m going to send this information to my developer today. I’ll report back with results.

Any suggestion?
Thanks in advance

I’ve just DM you some notes, compiled from my previous responses here.

s2member-v260318.0404.zip (1.4 MB)

Gerard:

PS) I’d very much appreciate a credit on the changelog Thanx

Of course! I had already written it in the draft. It is very appreciated and welcome.

In the text I included I mention …

Got it on the format notes. I’ll review this and probably make some adjustments before the release. I’ll post an update here once I have it.

'Must be a UK Postcode (7-8 digits w/possible space).'

which almost all postcodes adhere to. Your edit

'Must be a UK postcode (5-8 characters w/ possible space).'

is fine but its no more correct than the initial 7-8 text, as if one is being 100% precise about it, submitted RegEx strings which are 4-9 characters long would be accepted.

In the official UK government Office of National Statistics website, all of the current official postcodes are between 5-7 characters long if all the spaces are removed before testing.

SELECT MIN(LENGTH(REPLACE(Postcode, ' ', ''))) AS min_length, MAX(LENGTH(REPLACE(Postcode, ' ', ''))) AS max_length FROM postcode;

min_length 5
max_length 7

The current postcode data is available to download for free.

So the RegEx I’ve implemented is:

/^(([a-zA-Z]{1,2}[0-9][a-zA-Z0-9]?|ASCN|STHL|TDCU|BBND|[BFS]IQQ|PCRN|TKCA) ?[0-9][a-zA-Z]{2}|BFPO ?[0-9]{1,4}|(KY[0-9]|MSR|VG|AI)[ -]?[0-9]{4}|[a-zA-Z]{2} ?[0-9]{2}|GE ?CX|GIR ?0A{2}|SAN ?TA1)$/

As this takes into account historic Postcodes which people might use even thought they’re not valid postcodes any more, so I think this is a better choice as its more forgiving and will generate less support queries It accepts postcodes of the British Islands and Overseas Territories + Military + exceptions such as:

* ASCN 1ZZ     (Ascension Island)
* STHL 1ZZ     (St Helena)
* TDCU 1ZZ     (Tristan da Cunha)
* BIQQ 1ZZ     (British Indian Ocean Territory)
* BFPO 123 / BFPO 9999
* SAN TA1      (Santa – special historical case)🎅🎄
* AI 2640      (Anguilla)
* VG 1110      (British Virgin Islands)
* MSR 1110     (Montserrat)
* KY3 1ZZ      (Cayman Islands)
* GE CX        (very rare exception)
* GIR 0AA      (Historical UK Government benefits payment bank, Girobank)
* GY# #AA      (Guernsey / Alderney style)

This is the main reason I suggest providing users a client side function to help format user input, as it will be very very very easy for people to input what they think is a valid postcode which doesn’t pass the RegEx, which I could imagine being very frustrating for people. I’d be happy to compile some simple examples for documentation on the s2member website if you think that would help.

The following is the “official” UK Government regular expression

^([Gg][Ii][Rr] 0[Aa]{2})|((([A-Za-z][0-9]{1,2})|(([A-Za-z][A-Ha-hJ-Yj-y][0-9]{1,2})|(([A-Za-z][0-9][A-Za-z])|([A-Za-z][A-Ha-hJ-Yj-y][0-9]?[A-Za-z])))) [0-9][A-Za-z]{2})$

Which can be found here:

https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/488478/Bulk_Data_Transfer_-_additional_validation_valid_from_12_November_2015.pdf

But even UK government websites used a variety of RegExs

I had considered implementing this with a menu page option to allow people to insert their own chosen RegEx, which would default to the above RegEx if none is submitted, but I’d thought that might perhaps be a bit to ambitious for my first contribution

Also, thanks for checking this so quickly

And yes, UK Postcodes are a nightmare

PS) I’d very much appreciate a credit on the changelog Thanx

s2member-v260317.0418.zip (1.4 MB)

I reviewed it and made a few adjustments so it fits cleanly with the existing custom field handling. The UK postcode support is now wired through the same areas as the existing zipcode formats:

• server-side validation
• admin-side expected-value selection
• front-end validation
• matching minified JS for the release package

I didn’t keep the separate postcode-formatting helper as submitted, but the validation-side support is in place and the package now looks consistent for testing.

Please take a look when you have a moment and let me know if you spot anything I should fix before release.

I’ll review it to see if it needs any tweaks or if it makes sense in the release.

Gerard