Plugin Author
Tim W
(@timwhitlock)
Thanks for the suggestions.
Point 1 is somewhat against the way PO files work. (they are deliberately locked) Adding and removing lines can be done in the POT file that all PO files sync to. Unfortunately many authors do not provide valid POT files.
Point 2 is something I’m working on right now. It’s likely to work in the same way that WordPress does unauthenticated file system operations (like installing plugins) which is to prompt for remote connection details. (FTP/SSH).
G’day Tim … Thanks for the prompt response.
I truly agree that Pt. 1 deemed unfeasible. Perhaps, there could be a way to incorporate a non-linkable PO file to all installed plugins. Meaning, this PO file is independent, and may not require any POT file for synchronisation. I’m unsure if such an approach is attainable. If it could, it’ll act as a dummy PO file, while leaving the rest of the locked PO files intact. This will definitely save me the trouble of adding filters to distinguish the selected language in my child theme’s functions.php. For your information, I’m using the qtranslate-x plugin.
As for Pt. 2, the approach could be somewhat similar to what you’ve mentioned. I was thinking instead of removing the extra PO files, there may be an option to hide them from the listing. Perhaps, a global setting to only list PO files based on the admin’s choice of languages, rather than listing every single PO file that’s available from the active/installed themes and plugins. This way, I won’t have to scroll/search like mad to know if a plugin is missing my choice of language PO files.
Let me know your thoughts. Cheers!
Plugin Author
Tim W
(@timwhitlock)
on point 2 – the new home page has a reduced listing, with plugins and themes split into separate tabs. I am planning a “starred” feature (further down the line) so favourite or recently used items will be surfaced.
On point 1. I’ll give this some thought, but my primary goal is simplicity. The support overhead for this plugin is huge, and making it more technical/nuanced is to be avoided. Ideally it should help developers localise their code properly, and make it easier for non-technical folk to just work with what’s there. The number of requests I get about why a particular string isn’t showing up would only increase if people could arbitrarily add strings to PO files.
Wow! I can’t wait to see how Pt. 2 is like. As for Pt. 1, you’re right that an arbitrarily adding strings to PO files will yield unsaved or hidden translated strings.
By the way, it’ll be great to include an option that allows certain roles access to Loco Translate via the admin end. So far, I noticed only Administrator role is given access. Even the Editor role isn’t provided any permission.
