Tim W
Forum Replies Created
-
Forum: Plugins
In reply to: [Loco Translate] New versionI’m not familiar with that plugin or what behaviour it supposedly fixes, but Loco Translate has observed DISALLOW_FILE_MODS for a long time. It has various other security controls including optional base directory restrictions added in the current development version.
I don’t know what workarounds you’re referring to, but mu-plugins are supported as standalone PHP files.
The disabled checkbox logic comes from this code. It was added almost 10 years ago, and I’m no longer familiar enough with the thought process behind it that I’m willing to risk changing it. It seems to be in place so you can’t accidentally revoke access from yourself.
Forum: Plugins
In reply to: [Loco Translate] Redirection to a empty page – filtering fieldThe text filter field doesn’t need to display when there’s no table to filter. I’ll fix it.
Thanks for reporting this. I’ve found the bug and fixed it in the trunk.
If you can’t wait for 2.8.4 to be released, you could patch your code as per this commit. It was a silly mistake on my part where the target
$localevariable was being overwritten by the source locale.Forum: Plugins
In reply to: [Loco Translate] Log flooded with alertsChanging your PHP version won’t cause new messages like these. Possibly your logging wasn’t set up properly, and now it is.
Either way, I have to close this ticket, as there’s nothing further for me to investigate. Feel free to reopen it, if you find something useful.
Forum: Plugins
In reply to: [Loco Translate] Log flooded with alertsNothing has changed for years in how Loco Translate validates JavaScript file references. More likely the code base being referenced has changed.
If you don’t want to suppress ALL debug messages, then you’ll have to investigate why the PO file being compiled has bad references in the first place. It may need syncing to a more recently updated POT file (if references have changed), but I can’t say if this is the case, or if the POT file itself has bad references.
For example. Your PO file references a script at
blocks/assets/js/editor-components/products-control/index.jswhich doesn’t exist (or can’t be found). Without knowing who/what produced this reference in the first place, I’m not able to comment on what may have changed.Forum: Plugins
In reply to: [Loco Translate] Error reported by PCP plugin for .l10n.php filesI don’t see that
.l10n.phpfiles should need this line as they won’t produce an error if executed out of context. They simply return an array of string literals. WordPress (GlotPress) don’t add this line. If they start doing so, then I’ll do the same.As a side point: Shipping your own translations within your plugin is something that WordPress have discouraged over the years. Contributing your translations to their GlotPress project would mean no need to submit any l10n.php files
Forum: Plugins
In reply to: [Loco Translate] Best way to keep editsPlease read the documentation on safe file locations.
https://localise.biz/wordpress/plugin/faqs/files-deletedForum: Plugins
In reply to: [Loco Translate] Log flooded with alertsThe cause of these notices are JavaScript file references encountered in a PO or POT file that don’t actually reference the string they say they do.
In some cases it looks like the .js file doesn’t exist (or Loco Translate can’t find it). In other cases it looks like the referenced file has no translations (or Loco Translate can’t extract any).
You can suppress debug messages with the
loco_debugfilter. However, the purpose of the message is to tell you something that may be useful. i.e. The JSON translation file will be missing for these .js files.If you’re asking me for my opinion. Translated content in en_AU should be held in files named en_AU with your site language set to en_AU.
It’s subjective, because it’s your site and not mine. I can’t say what issues you have to deal with, now or in the future.
I am thinking of downloading the translated ‘en_AU’ .po file from site1, then renaming it to the ‘en_US’ extension, then uploading it to site2 as ‘en_US’ .po file into the ‘Custom’ destination folder.
Would that be correct?
This will work for your file. Loco Translate will compile the required
en_US.l10n.phpfile as for any valid language code.As for whether it’s “correct” – this is subjective. It’s entirely down to you whether you want to override regional English without specifying a “translation” language for your site2, as. you have with your site1. I can only tell you how my plugin works.
Am I allowed to have 2 ‘en_US’ .po files at the same time?
Yes. Loco Translate will merge your system and custom files as documented.
See this note about loading order.Forum: Plugins
In reply to: [Loco Translate] How to export theme translations to from site1 to site2@joe-bloggs Please ask new questions in new threads.
Forum: Plugins
In reply to: [Loco Translate] Automatic Translation by DeepLI’ve answered this query by email.
This plugin has no support for DeepL glossaries. The main Loco platform does, but it’s currently a separate product and not supported via this forum.
Forum: Plugins
In reply to: [Loco Translate] A string appears as “Context” in the source textThe context field (as with the source text) is not editable directly in translation files. You must go back to the source of these values, which is likely a POT file. Correct that first by syncing it to the actual source and context values in the code. Then sync any damaged translation files to the updated template.
Read about translation templates, and syncing source strings to understand what’s happening here.
Forum: Plugins
In reply to: [Loco Translate] Option to synchronize from files and ignore the POTThat’s correct and intended. A blank field will not work.
Let me be clearer. Any non-empty template file path value that doesn’t point to an existent file will force direct source code extraction.