It’s quite different. You may say that Indonesian language is more developed one, because we adopt so much more other languages than Malaysian.
pm you now.
thanks.
2 Likes
@steamboatid - I have checked in Crowdin tool and in fact they don’t even have a Bahasa Melayu but only “Malay” and “Indonesian”, so I activated “Indonesian”. I have also sent you an invite link in the PM (and if that does not work just send me what I asked in the PM).
As for the process, this is what needs to be done first Approving and cleaning existing strings on Crowdin
@James - for some reason the newly added language does display “0 strings” when going to the “proofreading > editor > QA Check > Without QA Check”
Do you know why this is? Does Crowdin maybe need to “warm up” first?
Or did I miss something when adding the language?
1 Like
We will need to import the WP translations for each new language, and probably some other steps, that haven’t been done yet.
1 Like
Thanks!
I have never done any of this before in the tool.
Do you know how to this all? Or did we have someone who setup the langs existing I could ask for assistance on this?
Since we do have someone who seems to be eager to contribute I would like to respond with the same eagerness 
and not take out the wind from his momentum, the start of something is often colouring how things end.
Let me know if you know how to do these things or if there’s someone I could ask so we can then also write an instruction for the future.
(I have seen the “import” button in the Crowdin but I wouldn’t even know what to import. WP 4.9 strings are different than WP 5.x and thus… not sure where to get the originals to import to start with).
2 Likes
I did the import of existing languages + translations from our old system (GlotPress, decommissioned) into Crowdin. The person who set things up in GlotPress was @Mte90 but he moved on a while ago. So I think we will need to figure out most of the steps ourselves.
The basic steps should be something like this:
- add the new language
- get the WP .pot file for that language and import it (hopefully Crowdin will match up only the strings that are actually used, most of them should still be the same)
- make sure the translations go through to GitHub
After that, we will still need to set up a process to check what is coming for Crowdin for any issues like unexpected tags, decide on a strategy for handling the different versions of ClassicPress that are out there, and actually make the translations flow through to ClassicPress installs.
1 Like
Well, the strings are now there.
Either someone imported them (not me) or Crowdin does pre-translate them and it just takes time.
In any case, the Indonesian strings are now available for what is further elaborated here Approving and cleaning existing strings on Crowdin
FYI @steamboatid
@james
Just to see if I understand this right…
…even if we forget about new languages for a moment;
do I get it right that we are not sure if we can at the end actually use the translations from Crowdin, and it is not known if the effort would lead to results or might end in “does not work”?
Or do I misunderstand the part where you say…
After that, we will still need to set up a process to check what is coming for Crowdin for any issues like unexpected tags, decide on a strategy for handling the different versions of ClassicPress that are out there, and actually make the translations flow through to ClassicPress installs."
… wrongly?
To me that sounds like we do not really know if this even will work with CP and how.
What precisely is required to have translations working in CP Installs?
I have so far confirmed in Crowdin that we can download the (finished or in progress) translations as .po files manually of each language.
While we can not sync that somehow automatically to somewhere like GitHub as example, as far I see, they do have an API with things like API v2 Reference (Enterprise)
So that suggest that with some code (which needs to be written), stored somewhere, we could call that API and export said translation .po files, and I imagine with this we could maybe then populate our remote (git?) from which actual CP Installs would pull them back into the single installs.
Is that useful? (Like, after all things are translated of course).
I think we would need to be relatively sure we can actually use this before we create a lot of translations that we are not sure we will be able to use.
Very simplistically speaking, is a .po file with translations for each available language something we can work with to serve CP Installs from a remote we own?
If so, then I think we will be able to figure something out, since .po files are exactly what Crowdin delivers us.
As for CP versions (tags) I assume that would need a specific new .po file each version.
I think we should not support that, and just assume/support the latest version of CP (which currently is not the case anymore, since the master .po on the crowdin does not reflect the latest CP).
Otherwise I think we will pile up .po files ad-infinitum for each tag that might change a single string or add a single string.
And it also would require to set up distinct project instances in Crowdin, since it defaults to one master .po file for each project, not several, thus does not really allow “version management” as such, as far I saw.
Should we follow up on this all in a specific to-do thread?
The current setup will definitely work once it is finished.
The strings are there, but the translations are not. We need to grab the Indonesian .po file from WP and upload it into Crowdin. It will pull in the translations for all of our existing strings. Only after that will Indonesian be ready for the steps at Approving and cleaning existing strings on Crowdin.
Yes, we can… New Crowdin translations by ClassyBot · Pull Request #2 · ClassicPress/i18n-core-crowdin · GitHub is exactly this. See GitHub Integration | Crowdin Documentation for more info.
- set up a process to check what is coming for Crowdin for any issues like unexpected tags (this needs to be done before merging PRs generated by Crowdin)
- decide on a strategy for handling the different versions of ClassicPress that are out there (how and when to update translations as new versions of ClassicPress are released)
- actually make the translations flow through to ClassicPress installs (this is pretty easy compared to the other steps)
Yes, probably.
The strings are translated
When I actually open crowdin and go Indonesian strings page I can see translated strings
That’s why I think it actually took time to … pre translate
I can’t see any other reason why the strings wouldn’t be there at all initially and now appearing even translated (well, beware I didn’t check all pages - just the first…)
About 1% of the strings are translated. From the few I looked at, this was done by @steamboatid a few days ago.
Please import the file from WP before continuing, it will save you a lot of time.
@james that’s what I asked to @anon66243189 couple days ago.
Indonesia translation is 100% for WP. If CP has some mods to its texts, it’s OK, I’ll take it 
I also know Javanese language, its my mother languange.
People at suriname still use this language.
@anon66243189 please also import javanese if available at WP
1 Like
Javanese is available for WP but it is only 57% translated. It is also not in the list of the top 50 locales: Stats – WordPress.org
When we started our localization project, we started with the top 10 locales used by WordPress. Indonesian is currently #21 according to those statistics. Let’s leave Indonesian since it’s already added, but we should not add every language just because someone is available to help with it. Every language that we add is an additional maintenance burden going forward, and we need to balance that against how useful it is actually going to be. If there are no other ClassicPress users that are asking for a language then it may not be worth it to add it.
As another example, we don’t know how to localize language variants yet. Until we have a process for this, we shouldn’t add things like other variants of English either.
OK… I do not see the same. While the “bar” says 1%, in fact the translations are there.
If we go to the editor and check page by page, all strings are translated.
You can in fact go to the last page and it is all translated.
It is not approved (as per workflow), and thus I believe that is why it says 1% translated.
What I noticed is, there are just something above 600 strings in Indonesian, but there should be 40K+ I believe.
In any case, I tried to upload the translation to Crowdin, and while the DOC does not match the current Crowdin Screen (see Uploading Existing Translations | Crowdin Documentation) I was able to upload the only supported format (XLIFF) which I had to convert from the PO (or other formats) that you can download at Translations < Indonesian < 4.9.x < GlotPress | WordPress.org
I used Convert PO files to XLIFF language packs for this, might be handy later.
Uploaded, and it said “upload complete” and just as before, it says 1% translated.
It also still only recognised 600 something strings, but there are over 40k words “to do” in the crowdsource section (on other languages that number differs in each)
When I filter Indonesian by “untranslated” zero strings are shown, indicating all is translated, but again, there is just a total of 600+ strings, instead of 40k
I have even tried to remove and re-add the language, and the same problem happens.
There should be 43 297 words, yet the import/without import/no matter what Indonesian only pulls up 600+ words in the proofreading section, and the rest is in “crowdsource” section and no matter what, it does not update those strings even after uploading the translated file.
Doing all that BTW I noticed we can have more than one branch, so that would allow to keep track and translate of more than a master branch, I suppose (such as versions). While this is not yet really important, it is what might help us down the road to keep track of the distinct versions translations.
The 600 words is the 1% of strings that are translated (shorter strings were translated first). All 43,000 strings are present in Crowdin but the majority of them are not translated.
Make sure you don’t have any filters enabled:
It looks like this didn’t work.
When I set this up, I got Crowdin to pull the translations from GitHub. However, going to the GitHub integration settings I see this:
Translations from GitHub are pulled when you set up the integration. After, it is expected that all translations will be made in Crowdin, so we won’t check for new translations made in GitHub.
1 Like
Yeah, seems that upload of files (despite it clearly suggests that this is how you upload existing translations, even if for example someone wants to work locally and then upload…) does not work.
What I thought… to press the “pre translate” button.
Because I have seen in the activity logs you did that a couple times in past, so perhaps if I press that, it will at least do some translations even if perhaps not pull the ones from po file, it will machine translate them?
Can I ruin anything by pressing that button?
I think we can always “undo”, as far I saw in the activity log.
I am trying to chat with support now there to get more clarity, before I proceed…
I wouldn’t do that. I don’t remember doing that in the past either. I would expect the resulting translations to be terrible.
I’m not sure why uploading translations didn’t work for you (and in fact, it looks like I would be able to upload a .po file). Still, I am doing it another way: by resetting the GitHub integration with the new language file in place. This needed to be done anyway since it was no longer pushing new translations to GitHub.
1 Like
wait, unless you are already done.
I am in chat with their support… could be an issue with the XLIFF headers
I will update here as soon we resolved (if) that
They say PO should work and yet it does not. They could not resolve the issue and forwarded the problem to email for further check.
@James - I guess whatever you wanted to … will be faster than waiting for them. Yet I will be eagerly awaiting their resolution so we can do that on our own in future…
PS they also recommended to use WPML to translate “our site” 
Fun times.
Well… re-syncing with GitHub got the Indonesian strings up to 32% translated.
I then uploaded the .po file which worked perfectly fine for me but didn’t increase the translation percentage any.
That is weird. Me gets an error only XLIFF being supported…
I will update support about this status (because since 100% Indonesian is translated, de facto it should show that, I think)
I guess its progress, still, as compared to before.
@steamboatid I suggest you hold on with doing anything there yet.
1 Like
Found the issue - WP translations are split across multiple “sub-projects”:
Then under Admin, there is one more sub-project for Network Admin.
I uploaded these other files and got the translated strings up to 78%, which should be higher - around 90-95% - the difference is that many of the WP strings and translations that say WordPress should actually say ClassicPress. So I created separate copies of the .po files to correct for this (just replaced all instances of WordPress with ClassicPress), and then re-uploaded.
For new languages we can download all 4 of those translation files from GlotPress, create copies of the .po files that have WordPress replaced with ClassicPress, and upload all 8 files at once (we need the original 4 also, since some of those strings will still say WordPress). Here are the settings used. The only change from the defaults is to check the box to import strings that do not change when translated, like city names:
Now we are up to 94% translated for Indonesian, and these are steps we can repeat for other new languages. (I still don’t think we should add new languages without a bit more consideration though, we should focus on making the existing ones fully working first.)
Anyway, now Indonesian is ready to follow the steps at Approving and cleaning existing strings on Crowdin.
3 Likes