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().
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).
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.
The .pot files for v2.0 must be generated using WP-CLI. All the tooling we had for v1 does not work in it’s current form. So unless someone wants to fix it, there is a WP-CLI command to generate core translation strings. There’s more information in this issue:
For reference, the command is:
wp i18n make-pot . v2-c.pot --ignore-domain --exclude=wp-content,composer.json,wp-admin/about.php --skip-theme-json --skip-block-json --no-color
v2-c.pot is the name of the file being generated.
This morning I actually used WP-CLI to see if I I could create a new .pot file. And I did…
Why are you excluding wp-admin/about.php? That file holds all the info related to ClassicPress…
You don’t need to exclude composer.json, because are no translatable strings in there. 
“theme-json” is already excluded by excluding the entire wp-content folder and isn’t “–skip-block-json” redundant as CP was made to not include the block editor? 
I used this command myself:
wp i18n make-pot . v2-c.pot --ignore-domain --exclude="/wp-content/" --package-name="ClassicPress 2.0.0"
I used the following command when creating the .pot file:
wp i18n make-pot . ./en_US.pot --skip-plugins --skip-themes --ignore-domain --skip-audit
Clearly, the skip theme and plugin flags don’t actually do anything. I will push an updated .pot file now and sync it to CrownIn to remove theme and plugin strings.
I’ve also realised the pot file should be based on a build rather than dev files, so that is updated and sync’d to CrowdIn now.
I do not know if this is the correct place/topic, so please let me know if I need te (re)post this elsewhere…
CP gathers all the core strings neatly into one single pot file, unlike WP which uses two (or three on Multisite installations).
The function load_default_textdomain (defined in /wp-includes/i10n.php lines 853 to 890) determines which file (nl_NL.mo, admin-nl_NL.mo or admin-network-nl_NL.mo) should be loaded, based on either the front end, blog admin or network admin.
But because these files do not exist in CP, this check could possibly result in having the Admin and/or Network Admin not being translated.
Has this been tested? And is running this check even needed, since there is only one file to be loaded?
We should have a way to include these multisite strings. @MattyRob and @timkaye might be able to suggest a way to include them.
Thanks for your attention to this detail.
Those strings are already in the CP pot file. (I double checked using a specific Network string.)
What I meant was, CP does not have to check which mo file load, since all core strings are already in one and the same file.
So, in my opinion, the function could be slimmed down to something like this:
function load_default_textdomain( $locale = null ) {
if ( null === $locale ) {
$locale = determine_locale();
}
// Unload previously loaded strings so we can switch translations.
unload_textdomain( 'default' );
// Reload strings if the locale has been switched.
return load_textdomain( 'default', WP_LANG_DIR . "/$locale.mo", $locale );
}
Having said that, in /wp-admin/includes/admin.php line 17 also tries to load the non-existing admin-$locale.mo file.
And I have not checked this yet, but I assume that similar code might also be presents in Network Admin files.
That is clear to me now, basically WP needs to state which files are to be used (single site vs multisite) and CP does not, having only one file with all the strings
This is one of the things we need to do differently than WP because we dared change the localization system from WeGlot to Crowdin. You can blame this on me because at the time I was i18n Team Lead and to solve a standby I proposed to have our own localization solution different from WeGlot.
That being said, I think this needs a PR to allow this change being included into core, will take care of submitting it on behalf of i18n team tomorrow morning first thing. Even if I am a developer with a small experience I think i can describe the issue in layman terms referencing this conversation so that our core team can see to the change. We need to do this before issuing the first release of our translations IMHO.
I am actually glad CP moved to Crowdin. 
I agree.
Is there a way I can get more involved myself?
I just opened an issue here.
The right way to go about that is continuing the discussion about this specific issue there on GitHub, and help as needed to make the change happen.
This can mean testing the solution that core team comes up with, reviewing and approving the code when tested to prepare it for merge etc.
Personally I am not confident to meddle with core code myself, even if I understand what it does. This because changing something (even small) can have repercussions on other files and there is the need to check that this change does not affect other functionalities. But i am available to troubleshoot, test and if given access to the level needed to approve a PR opened for an issue I am ready to do that too.
As i18n team we can help by specifying what should happen in this case, and how we envision the solution to work. This will allow our core team to make an informed decision on what we need from them to make translation work.
You can contribute directly to core if you have an account on Github. To do so, clone the main ClassicPress repository to your Github account, then create a sub-branch of your clone, and make code changes to that. When you’re ready to submit the code, open a pull request (PR).
To make a new PR, make a new branch, and repeat the process.
Thank you.
I do have a GitHub account (I use it to log in on this forum). I have not yet cloned or sub-branched other’s code yet. So I have to look into that.
As a WP Plugin developer myself I have an quite extensive knowledge of how the core code works, so I would like to be a fly on the wall during discussions about core code changes, if possible.
Continuing about the i18n, I have some (admin / technical) questions about how Crowdin works, regarding to providing the default CP theme its own translations, etc.
Like: Could that be a sub-project of CP Core, allowing all current translators access automatically? Or does Crowdin regard that as a new project?
To whom may I turn for questions like these to gain more personal insight.
First thing: in the #core channel on Zulip every week (on Thursdays at 5:00pm Italian time) there is the meeting for core development (I always do my best to attend even if it is only to listen). Being that the i18n team needs help from the core team to make things smooth it is a good thing to start helping/listening there and give your two cents when you have something to say.
Also by being active in the comments section of the Issue I opened on GitHub and the PR(s) that could be opened in response to it you will be able to be that fly on the wall regarding this specific issue and also you will be i18n eyes to make sure that the specific change is made in a way it does not damage other things. I will be there too so that we can both keep our eyes open and ensure everything goes well.
Second, the i18n Team has a channel on Zulip too. As a team we should totally have a recurring monthly (or weekly) meeting set up like core has its weekly meeting happening always on same day at same time for the exact reason you mention, being able to discuss localization challenges and decisions to be made like the ones about themes to be localized.
On the topic of the default theme(s) localization: For now we localize the core - this takes strong precedence IMHO. Then in the same Crowdin space we can open the default theme(s) individual project(S) (so that when you open dashboard you will see a card for each project: ClassicPress, theme One, other default themes in the future) and by clicking the one you want to localize you can go in and translate strings. This setup has to be discussed however and if we are all in agreement we can proceed. I am not taking the decision on how to setup default themes localization alone, i18n is a Team and as a Team it should work.
On how Crowdin works I published a tutorial here, and generally I am the go-to person if you have doubts on how to use it or on i18n in ClassicPress.
Thank you very much. It seems I have a lot of reading to do.
And I will add the recurring meetings to my calendar.