This plugin is not supported, but works as well.
Just can’t reach new plugin and theme .po .mo direction localized wp-content/languages/
Need your help to check security or start project (even with author)
to reprogram this script to admin feature with option to upload languages just like plugins and then edit them easily.
Alternative user got prebuilt CL option to just rescan .po files after update plugin / theme and create own corrects without downloading new .po. This option is more for custom traslation edits for developer needs.
Lets look at edition
Then generate .mo file
So lets talk about direction of .mo file. That’s important thing.
Back in the days structure was pretty simple:
But now all plugins and themes seems to be subordinate to new destination of .po .mo
Why this is not good solution?
Lets say back in the days .mo file was closer to template file and all tasks was made inside plugin directory. Extending area of these files, cumulate them in top of wp-content (wp-content/languages/) doesn’t make sense for me as Codestyling Localization can catch them and manage pretty well.
If I delete plugin – from admin or from ftp i delete also languages, also they are in predicted direction inside.
Some plugins got 30 translations, 10 plugin like that and we got 300 .po and 300 .po then it looks like 600 files in one catalog – big mess and loss of time to search some manually .
But why? Because for WPML its easier that way. Lot of Premium plugins started this lobby, then Woocommerce.
Everytime some plugin stepped in WPML becaming worse and overload software, that’s just my opinion as a testing developer in those times.
So let’s say – nobody was interested in codestyling localization and polylang as soon as american premium plugins lobby of WPML keep continuating all producers to fit them standards ( just like Gutenberg Team now in my opinion).
My opinion about translating is
More content You can put to .po , Low content you put to the database.
Closer from .mo file to template file is better and easier to handle for developer, server and usability.
Also .po .mo files are most reliable method I’ve learned, being at end of popularity, just because lack of software like Codestyling Localization to support classic translation system.
Why no one’s interested in translate .po?
Because premium plugins use a lot of input strings to fill by user, putten to database and like it rather than give good experience of .po editing to editors. WP is promoting and WC supporting WPML and that how things have done.
Also We still have few strings in ClassicPress,
All strings like these can be translated in Languages/string translations tab in polylang
But less of those translated inputs is better to developer, as they can be cookie dependent and start being non usable when cummulate too much together with few locales.
History is the whitness.
All persons interested in start to refresh Codestyling Localization project for ClassicPress admin feature can even contact with author or start to developing this dead project.
Welcome to share my copy of Codestyling Locatization for test huge improvements of this plugin with easy translations on all your favorite plugins language version You’ve used. Still there’s much plugins containing .po file inside and themes just like Divi. All of them You can customize with good experience.
Adding also paths to wp-content/languages/ could make fully compatible solution for these 2 methods.
Authors then can put .po .mo in modern way to wp-content/languages/ or oldfashioned inside aplication.
Also if connect it with some translation repository (based on plugins repository) Could create ClassicPress so powerful tool to reach out point “friendly software with easy multilanguage solutions”. All this features with Polylang deactivated in bundle is my kind of wish to Santa.