Non-standard location of .mo files

[boatsRus]

OK, so the reason I had problems with the translation perhaps was not due to the .po file error. Instead I noticed that wp-google-maps textdomain .mo files are stored in a non-standard location. Typically plugins store .mo files in /wp-content/languages/plugins but WPGMZ stores them in /wp-content/languages/.

Did this change in 8 or what happened?

[Dylan]

Hi there,

Thank you for your time, we do appreciate it.

Our PO/MO files are stored in the following directory: wp-content\plugins\wp-google-maps\languages

These PO files are maintained internally by our community and submitted to us directly. Our text-domain is set up to support this structure.

With that being said, in some environments, WordPress will download the publicly maintained language files instead, as found here: https://translate.wordpress.org/projects/wp-plugins/wp-google-maps/

In these cases, the PO files will be stored in the shared language files instead.

I hope this helps clarify?

[boatsRus]

Yes, I know where to find them when you deliver the plugin and I translate them myself, thank you. However, the question was about where they are located at runtime. Most “well-behaved” plugins leave the /wp-content/languages folder for WordPress .mo files and fetch the plugin specific .mo files from /wp-content/languages/plugins. Emphasis on “well-behaved” 🙂

[Dylan]

Hi there,

Thank you for your feedback I do appreciate it. 🙂

I have looked through our release logs and I can confirm that we have not made any major changes to our text-domain recently.

This is quite strange admittedly as this is controlled entirely by the WordPress core. These community files do load separately from our bundled language files in some cases, although they should not.

With that being said, what I believe may be happening here is that some of our string localizing code may be missing a text-domain reference.

I believe WordPress is then loading the standard PO files and storing them in the base languages folder as our custom text-domain is ignored.

We are currently looking into this further, however, it does appear this is the case. If so, we will be releasing an update to resolve the missing references to the text-domain which should restore the standard file loading.

I hope this helps?

[boatsRus]

Sorry, there were so many things I needed to try to get this sorted I got myself confused.

So, yes, currently the .mo file is fetched (only) from /site/wp-content/plugins/wp-google-maps/languages. The correct way would be to first try to fetch from /site/wp-content/languages/plugins but for some reason wpgmza does not do that. Only if there is no .mo file in the /site/wp-content/languages/plugins should it try the plugin directory.

Why? Because, now if I make my own changes to the .mo file (which I need for Finnish), and store it in the plugin directory, this directory will every now and then be totally overwritten and the translation file will be lost. Also, if I want to modify any of the translations that come with the plugin as “standard” (and yes, there are many valid reasons to modify them), then such modifications will be overwritten every time the plugin is updated.

Therefore plugins should fetch their .mo file first from /site/wp-content/languages/plugins because then plugin updates will not overwrite/destroy site specific translations. This should be the standard function of the load_plugin_textdomain(), for some reason this does not work with google maps?

I’m wondering if it is this filter that changes the behaviour, no idea?
add_filter('load_textdomain_mofile', array($this, 'onLoadTextDomainMOFile'), 10, 2);
The code is on line 58 in the file shown in the screen shot.

Still, it would be nice if the intended/default behavior would be enabled so that the plugin would fetch .mo files also from the /site/wp-content/languages/plugins directory.

Attachments:

You must be logged in to view attached files.

[Dylan]

Hi there,

Not a problem at all, thank you for taking the time to discuss this with me further.

After looking at our core I can confirm that we do prioritize the language files included with our plugin in ‘/plugins/wp-google-maps/languages’. The reason we do this by default is that our bundled PO files are usually more updated than the versions loaded from WordPress directly.

In cases where our translations are directly updated by WordPress.org Translation Contributors, they often need to be approved by a Translation Editor before being included and deployed. For many languages which are supported by our plugin we do not have Editors who approve them, or approval may take excessively long as it is all community-driven.

When we receive an updated PO file from one of our users directly we have found that these files are often more complete and can be deployed with the next update we release.

I will discuss the possibility of switching to the community-driven language files as a setting moving forward for those interested in making use of this. I will need to discuss this with Perry, the lead developer, as it may require various changes aside from the filter mentioned in your reply.

In the meantime, a possible workaround which I have used in the past is to edit the PO file which ships with our plugin, and store the compiled MO file. Copy these to the wp-content/languages directory so that you have a version of them stored outside of our content folder.

I hope this helps? Once again, thank you for your time, I will discuss the ability to toggle off the use of our bundled translations with Perry tomorrow.

[boatsRus]

Hi,

No this does not help as it seems your plugin never picks stuff up from the wp-content/languages so if that indeed is the case, what you propose does not work. And users constantly running the risk of loosing (own) translations when updating. This happens with exactly zero other plugins, it would be good if you did as the majority of plugins do.

[Dylan]

Hi there,

Unfortunately, due to the reasons mentioned in my previous response, we load our bundled PO files instead of the community-driven PO files.

As mentioned I am in the process of discussing the ability to disable this moving forward as a setting within the plugin.

I do apologize for the inconvenience, however, we do not currently have an option to disable this. If you are using a translation management plugin, these do override our text domains in most cases.

The issue has been submitted to our lead developer for consideration moving forward.

[RichyR]

Hi,
I am confirming this problem. I updated a language file myself (French) but the plugin is not taking into account my corrections, whether I install the .mo files in the plugin language file directory or the wordpress language file directory. I wish this could be fixed quickly.
Please confirm a date if possible.
Thanks

Just an example :

Accueil

The word Radius should be Rayon.

[Dylan]

Hi there,

Thank you for getting in touch, we do appreciate your time.

We do plan on releasing an update within the next week or two which should address localization issues by improving support for multi-language plugins accordingly.

Along with this update, we have reworked the base language processing code as well to enforce loading the PO files found in our plugin, instead of the community-driven files as these are not as maintained as our internal files.

I hope this is acceptable.

[Author]

Posts