In T13514#237785, @dkazakov wrote:

In T13514#237783, @ltoscano wrote:

I know it may seems weird that I say this again, but this point is really out of scope for this specific task.
It is tracked by T13519

Well, this task talks about "injection" as about decided fact. But I tried to understand why git and gitlab themselves cannot be used for that.

In T13514#237781, @dkazakov wrote:

In T13514#237774, @pino wrote:

Instead of suggesting solutions, please describe your requirements, or in general what you would like to see.

Well, there are two requirements:

1. When releasing, setting a tag in the git repository should be enough to make a release. The tarball should be created automatically by gitlab's "releases" feature. Right now the scripts for making tarballs out of SVN break regularly, so every release we should fix it in one or another way. And these scripts are not fool-proof. We have generated and published incorrect tarballs several times.
2. The developers should have an easy way to build/install translations. Preferably, these translations should be synced with the current branch/commit (I often switch between master and krita/4.3 branches).
   
   I've also added a workflow requirement into a different task as you asked, but got a weird reply to it: https://phabricator.kde.org/T11070#237775

Sorry for the previous comment. This is the task about the online tool. Your requirement about editing is satisfied. About testing, we can create other tools to help the compilation/replacement of the po file, but if the injection of po files is implemented (that one is a different task), that's going to be easy.

In T11070#237775, @dkazakov wrote:

I think we should make a requirement for the updated workflow like that:

• the user should be able change translation of one string, test it in the application and send the result for integration/review in 15 minutes.

In T4803#237771, @aspotashev wrote:

@nalvarez, could you please update on the status of this ticket? Are you blocked on something? Do you need help?

I think I simply forgot to close this long ago.

In T13514#237738, @rempt wrote:

No, it's not irrelevant. It doesn't matter that .po are only copied, if the translation in stable branch and the one in development branch diverge (which they eventually will), you'll get merge conflicts (when merging stable to development)

Yes, it is irrelevant. I've never seen anyone merge an entire stable branch in one merge commit into the unstable branch; normally, people cherry-pick patches. Just don't cherry-pick the po files.

In any case, the advantages of having a po folder in the project git repo outweighs all of that to me, so if you are so intent on blocking this with irrelevant arguments, well, I'll do it myself.

In T13514#237617, @aspotashev wrote:

In T13514#237610, @ltoscano wrote:

The points can be dune until the moving of translations is not automated. Otherwise having to do the operations on a set of per-languages git repositories will be impossible.

I'm not sure what you mean here, can you please elaborate? The tooling to simplify moving of translations between directories is part of step #4 of the roadmap. Something like super-duper-tool mv kscreenshot/kscreenshot.po spectacle/spectable.po would create a commit in each of the Git translations repositories and git push all of them, possibly retrying this operation in a case of a merge conflict.

In T13514#237615, @dkazakov wrote:

I strongly believe that people who need easy review needs something like weblate. All the others don't care whether it's direct git pushing or svn pushing.

Well, the main problem (in Krita) that newcomers are frightened away from doing translations because of too complicated process. Any solution that would make it simpler would work.

In T13514#237612, @dkazakov wrote:

Hi, @aspotashev!

I'm not sure about this point, could you elaborate?

Disable GitLab merge requests feature for l10n/[language].git repositories unless we have an explicit approval from particular language team's coordinators.

One of the main advantages of migration to GitLab is that people could propose/review changes via some GUI interface, avoiding sending them via email or doing weird things like that. Sending files via email in 2020 just frightens new contributors.

Also, no parallel migration. When this will happen (after everything else is automated, including summit and the new website) it should be one shot.

The points can be dune until the moving of translations is not automated. Otherwise having to do the operations on a set of per-languages git repositories will be impossible.

After a few days of usage, it seems everything is working as expected.

https://websvn.kde.org/?view=revision&revision=1574284

So what's missing apart from rechecking the history and adapting makemessages to checkout the various branches in order?

Maybe, or maybe not. A web interface with reservation will be needed anyway, and if a web translation system won't provide it, we will still need this.

In T11070#233722, @clel wrote:

In T11070#233717, @ltoscano wrote:

Integration with identity is a basic requirement for any new service; I don't think it needs its own ticket.

I took that from the description where it says

apparently integration with existing systems (like identitfy) is sub-par

this is concerning the current situation, imho.

Also, new tickets should be part of the "normal" Localization work board.

Integration with identity is a basic requirement for any new service; I don't think it needs its own ticket.

I think this is basically done at this point (thanks!)

Fixed the initial lines and committed as https://commits.kde.org/pology/5cd25ec1197562c10ab26f4d4b37b6a5ca4ba4de

@adrianchavesfernandez can you please push the sequence of changes directly?

ping?