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?