Marcus

Having removed the offending rules, I see no side-effects from doing so, we’ll add this in the next update which should be out in the coming days.

I’m curious what you mean by this though:

or if we should add your plugin to the list of excluded plugins

What list are you referring to?

thanks for reporting this, it’ll get fixed in the next update which is due out this week

Hi Alison,

Most likely, no. It’s possible you’ll find another article somewhere with similar instructions, in this case you need to make sure it’d work with the v3 library of FullCalendar, which is what we upgraded to in the recent update.

Have you tried switching themes temporarily? Or maybe disabling other plugins?

If that doesn’t work post a screenshot of your settings and a url you expect the tag to show on

Hello,

Firstly, thanks for pointing this out, although I’d have appreciated you contact us directly about a potential security risk, even though you haven’t identified a vulnerability.

Secondly, I’ll get in touch with the team about this. They have an outdated version of their RIPS running and on another plugin there were some false positives, but that doesn’t mean it’s not worth double-checking or dismissing in any way.

Hello, just to let you know this has been fixed in the recent update.

Hi Thorsten,

Yes, it’s not perfect by any means, this becomes another subject wider to WP as a whole :/

The bright side is that the translation teams are pretty strict on vetting who can translate what so in some ways it’s better than individual plugins managing their translations like in the past. However, each team is run by different people, and they are all volunteers so there are big trade-offs and things vary wildly from language to language (even being the developer and fluent was hard to become PTE of my languages).

I’ve written to you already, as I have an idea about this.

Guys, I do agree with you about the intricacies of translating. I speak 4 languages fluently and appreciate the nuances ??

I’ll write this all here for posterity.

It’s a tricky one to solve in a community-driven platform like WordPress, or frankly any software where translations are done by volunteers and a consistent consensus is needed.

As an counter-example?@per4mance I translated some of the Spanish one myself last week, and had to decide between boletos, billete, entrada or even “ticket” which is also widely used in event platforms. Managing consistency accross all those translations is already a task in itself, let alone deciding on WHAT to be consistent on.

Sadly, there’s no perfect solution, however being WP and with all the hooks available, the upside is it’s not hard for you to take matters into your own hands as you have in already. But still, there’s no point in keeping that pot file there because its out of date. You have lots of options.

Firstly, just grab the latest translation from here or here (bottom of page). These are updated on-the-fly when we commit to the SVN repo. You can update your own po file from that POT file if I’m not mistaken in po edit. Also, a pot file is a po file, just change the extension if need be.

If you want a clean POT file straight from the plugin there are also options, you could try loco translate or the one we used (even though it’s not actively developed), codestyling localization.

Then, using script like Patrick’s you can add your own translation wherever you’d like. Personally, I’d change it slightly so you can add it in a folder like wp-content/languages/custom/ and avoid it getting overwritten on updates (I’ve not tested this):

<?php
function my_custom_em_plugin_translations() {
	$text 	= 'events-manager';
	$locale = apply_filters( 'plugin_locale', function_exists( 'determine_locale' ) ? determine_locale() : get_locale(), $text );
	$mofile = WP_CONTENT_DIR . '/languages/custom/'. $text . '-' . $locale . '.mo';
	$loaded = load_textdomain( $text, $mofile );
	if( !$loaded ) { $loaded = load_plugin_textdomain( $text, false, '/languages/' ); }
	if( !$loaded ) { $loaded = load_muplugin_textdomain( $text, '/languages/' ); }
}
add_action('init', 'my_custom_em_plugin_translations');

I’d also suggest pasting this into its own .php file and placing it in wp-content/mu-plugins

Thorsten, I’ll email you because I have some ideas on how to make alternative good translations like yours available to others, without compromising on your level of consistency.

Hello,

We have deprecated the langs folder as more up-to-date translations are on the www.remarpro.com repo. This was a conscious decision because that folder hasn’t been updated in years, and all the language files were copied over to the translate.wordpres.org repo anyway so they are either the same if untranslated or more up to date.

Additionally, those files managed by WordPress are given priority in the core languages folder anyway, so in theory, you’ll be using those anyway by default. We didn’t announce this due to that reason.

@duisterdenhaag We don’t need load_plugin_textdomain, we did test this out and translations do work fine without it. On the dashboard, the language shown is the one in your profile, front-end is the one in general settings.

@per4mance I would first argue that maybe you could help get your language correctly translated on translate.www.remarpro.com if there’s something incorrect there ??

However, I’m not sure what you mean by your screenshot… for example this string seems to be OK? I’d appreciate an explanation to understand it better.

If you still need the old po/pot files, they’ll always remain in the SVN repo. @duisterdenhaag’s snippet would probably make a good upgrade-proof way to preserve your translation work (but again, I’d consider the route of contributing to the translations so they’re correct for everyone).

Hi, we’ve replied to your email. Thanks!

[mods – can you please remove the email from the OP?]

• This reply was modified 7 years, 3 months ago by Marcus.

This will be fixed in the next update, but it shouldn’t have any effect on the functionality of the plugin. Many are using PHP 7 (including myself) without issue, you can go ahead and upgrade.

@onigetoc

I think it’d be best you start a new thread as I’m pretty sure the error won’t be related to PHP 7 anymore if you’re running the latest plugin updates. This issue is resolved.

I’d suggest also deactivating ALL your plugins apart from EM and/or switching themes, to rule those out. If that doesn’t work, or when you find the conflicting plugin/theme, check your PHP logs to see if there’s anything there that’d give a clue as to what’s happening, which would help us or the other developer, depending where the problem lies.