Working with Codestyling Localization

Codestyling Localization

Codestyling Loacalization
Screnshot from admin

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.

One reason.

If I delete plugin – from admin  or from ftp i delete also languages, also they are in predicted direction inside.

Another reason.

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,

General Settings

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.