thanks you
Have also created an account and am happy that I can contribute to ClassicPress.
2 Likes
I should have everything ready soon. We’re wrapping up branding changes in text strings. So when I generate PO file, everything will be correct 
3 Likes
I could help out with Dutch (both normal and formal)
2 Likes
I will prepare strings for translations this week. We’re getting close to v2.0 release.
3 Likes
Hi Viktor,
I still would like to help out with the Dutch translations.
Could you tell me where I need to sign-up, please?
Please also see my post: ClassicPress 2.0.0 "Bella" Release Notes - #25 by StonehengeCreations
You should shortly be receiving a link to sign up for our Crowdin account.
Hi Tim,
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.
Maybe the link went to a junk email folder. But I’m glad you’re in now! There’s quite a lot of translating to do!
1 Like
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$titlevariable 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.
Thank you very much, @ElisabettaCarrara. I am very happy to help out.
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.
1 Like
I looked at the CP Twenty Fifteen theme, bundled in V2.
In the functions.php:
function cp2015_setup() { load_theme_textdomain( 'classicpress-twentyfifteen' ); }
This theme already uses its own text domain and is not part of the core, which uses ‘default’ (fallback for none).
The core code uses load_default_textdomain().
1 Like
Makes sense to supply the default localized on its own then. As for the plugins: the strings should be sourced in Crowdin from the original CP release repo that does not contain plugins itself… I might misunderstand the technicality of the connection but to me the plugins should not transpire in Crowdin if my assumption is correct?
As far as I know, Crowdin does not generate the .pot file itself - it needs to be uploaded by the Project Owner.
When generating a .pot file, all included files will be indexed. That is why I said/suggested to delete the wp-content folder temporarily. I do this myself for my plugins, excluding any composer/vendor dependencies and the PUC Updater (for premium plugins).
Delete ( = move somewhere outside the main directory, like your Desktop) everything that must be excluded. Then generate the .pot file. After the .pot file has been created, move the excluded files back.
Crowdin Enterprise has the option to connect directly with the software repo where the release lives and source .pot files directly from there and when releases for translations are issued from Crowdin they are directly included in the software release repo (in the form of a PR or Commit I think) - we do have such connection and Matt was handling it but I am not sure if it is connected to CP release repo OR to a test repo Matt set up not to mess with the release one that might contain the plugins and themes. I don’t have access to the GitHub to a level allowing me to see this (not a core dev so it’s better because I might damage the repo by trying to do things on my own).
For now we can only wait Matt help on this. I think that going forward having clean core strings by checking this issue will benefit the project, in the end the time we are investing now will make our localization workflow better for future releases. And we might be able to teach a thing or two to WP (I personally translated for them tons of strings before, during and after being an happiness contractor at Automatic, last I checked despite them complimenting me during the WC Italy held online during COVID they never revised/released my strings).
1 Like
So far as translation of themes is concerned, it makes sense to me to translate only the new core theme, but to do that separately from core. But I don’t know how easy it is for @MattyRob to isolate purely core strings.
I have never generated a .pot file before. If you can point me in the right direction, I will see if I can generate the appropriate .pot file for the new core theme, and then upload it to Crowdin. I will also then open a PR to get the file (and folder, if it doesn’t already exist) added to the theme.
I have slightly hands full now (writing tutorial and announcement). Will write about .pot files generation in the tutorial, and I will send it to you in private to be sure is a good tutorial so that this can hopefully point you in the right direction.
1 Like