The work on version 2.0 continues; one big task we have left is translations.
We plan to use WordPress translations to help us get a running start but will need proofreaders to verify translations and translators to translate strings unique to ClassicPress.
If you can help, please comment on this thread with the language(s) you can help and if you can translate or proofread. Even simple proofreading is helpful, so don’t hesitate to offer your help!
We use the Crowdin platform for translations, and are currently working on getting it set up for v2.0.
edit: seems there is an other problem,i can’t proofread or approve/vote translations for french ,only translate. i am sorry ,i am not experienced with Crowdin but i will learn
Unfortunately I have not received a link (yet), but… I was finally able to use the URL mentioned by @koubi10. Using the link directly, let me to the paid option of Crowdin, which I did not want.
When I changed my Crowdin login from “using Github” to a normal password, I was able to connect to the ClassicPress project.
I am still trying to connect ClassicPress Crowdin with Poedit (my favourite translation app), so for now I simply downloaded the .pot file.
Auto-importing by connecting the Crowdin project within Poedit failed. The file could not be opened. But when I downloaded the files manually, opening the zip file was no problem. I contacted the Poedit developer about this…
Unfortunately the .po file contains strings for three third-party plugins: add-from-server, subscribe_2html and wpmq.
Having said that, I noticed several strings that, to me, make no sense to be using the __() function as they do not really hold any translatable content.
'ClassicPress 2.0.0' (/wp-admin/about.php, line 112), 'ClassicPress 1.0.1 - %s' (/wp-admin/about.php, line 127) and 'ClassicPress 1.0.0' (/wp-admin/about.php, line 141) only hold the brand name and version numbers.
'ClassicPress Maintenance and Security Releases' (/wp-admin/about.php, line 152) vs 'Maintenance and Security Releases' (/wp-admin/about.php, line 246). Could line 152 simply be changed to <h3>ClassicPress <?php _e( 'Maintenance and Security Releases' ); ?></h3> ?
'%s — ClassicPress' (/wp-admin/admin-header.php, line 50). The $title variable has already been translated in the lines 40 and 43.
'%1$s “%2$s”' (/wp-admin/admin-header.php, line 60) has nothing to translate.
'%1$s ‹ %2$s — ClassicPress' (/wp-admin/admin-header.php, line 68 and /wp-login.php, line 72) has nothing to translate.
These are only a few, but else this post would become way too long…
I am also wondering if a “clean up of duplicate strings” is something to start thinking about.
For example just the word “Next” already has 4 entries, plus Next >, Next » and Next →
You can’t remove duplicates because they refer to different contexts. Removing one results in not having a translation for it.
As per the strings you noticed, each one should be revised by core devs (there might be a reason for that specific format).
I generally agree with you that where possible they should be adapted.
As per the Crowdin>Poedit connection failing and the third party strings again @MattyRob could give more insight. They could be third party libraries used by CP.
I suggest you do not translate/revise/approve all the strings that pose issues so that we can identify and reference them at a later time, or that you make a list of them, that way we could work to normalize them for all locales.
Your insights are very valuable, I am very thankful for your help on this matter.
Upon further inspection of the V2 .po file, I found that, aside from three plugins, also the default themes are included. Since themes and plugins do not use the ‘default’ text domain, they should excluded from the Core translation files, right? When creating the main .pot file, I found it is best practice to (temporarily) delete the wp-content folder to prevent indexing.
In the current version there are 528 strings that are not part of the core code:
Plugin “Add From Server” has 16 strings (ID’s 4577 - 4592)
Plugin “Subscribe2” has 379 strings (ID’s 4593 - 4971)
Plugin “WPMQ” has 37 strings (ID’s 4972 - 5008)
All themes combined have 96 strings (ID’s 5009 - 5104)
Could these be removed, please?
In some cases I agree with that, like when the context is either a verb or a noun, such as “Trash” (“Found in Trash” v.s. “Trash this post”). But if the contexts “Next set of posts” or “Next post” or “Button label” I doubt translations for a single word like “Next” would differ.
As said, I believe this could perhaps be something to look into for future releases. And yes, to prevent loss of translations the source code would then have to be changed form _x() to __(), but currently most of these “duplicate contexts” are only used once.
I am willing to take a precise inventory for this, if the Core Team decides to look at this possibility.
The inventory would be a good place to start for a (much needed) cleanup for a future translation release.
About third party plugins and themes I agree on a logic level that it would be best to remove them and translate only the core but I need the input of @MattyRob and/or @timkaye on this, specifically the default theme issue because we are planning to remove WP default themes in favor of a CP specific default theme. Should we offer the default theme localized with the core? Is offering the localized theme a big endeavour that might slow down our team or is it a good move? And the third party plugins are they really needed or are they part of the process to generate the strings? I myself am checking on the it locale to see what needs doing while I prepare all the things needed for an announcement and tutorial so that I might have more informed answers over the weekend about how to proceed.
I would appreciate your opinion also on the default CP theme localization. It could be localized separately or in core. Which makes more sense?
The mentioned plugins are not part of the Core nor needed to generate strings. I assume that @MattyRob is using those himself. Subscribe2 seems to be a newsletter plugin.
Looking at the original WordPress code, three types of translations are being used: Core, Themes and Plugins and they are downloaded separately from their Repository API - each type has its own subdirectory. Available translation updates are also listed separately on the Admin Update page.
I do agree with providing localization for the default CP theme, but that should be part of the theme itself, using its own text domain, corresponding with the slug. Just like every other theme and plugin.
