In T11070#198422, @ltoscano wrote:

In T11070#198415, @ppeter wrote:

In T11070#198391, @aacid wrote:

still allow people to manage translations in SVN, but it will be announced that it is being deprecated.

NO we are NOT deprecating SVN in any way, that is not acceptable.

No... It means that submit PO file to SVN is unacceptable after migrated to Weblate to prevent the conflict issues, I don't really want to deprecate SVN completely.

It would mean deprecating SVN.

One of the requirement is to allow people to still do changes on SVN. If I, as administrator, need to directly change a po file (for several languages), I must be able to do it, and the online translation tool should cope with that.

In T11070#198422, @ltoscano wrote:

In T11070#198415, @ppeter wrote:

In T11070#198391, @aacid wrote:

still allow people to manage translations in SVN, but it will be announced that it is being deprecated.

NO we are NOT deprecating SVN in any way, that is not acceptable.

No... It means that submit PO file to SVN is unacceptable after migrated to Weblate to prevent the conflict issues, I don't really want to deprecate SVN completely.

It would mean deprecating SVN.

One of the requirement is to allow people to still do changes on SVN. If I, as administrator, need to directly change a po file (for several languages), I must be able to do it, and the online translation tool should cope with that.

In T11070#198391, @aacid wrote:

still allow people to manage translations in SVN, but it will be announced that it is being deprecated.

NO we are NOT deprecating SVN in any way, that is not acceptable.

And if it is approved, could I open a JIRA task to Qt for migrating their translation platform to KDE's weblate due to the reason @meskobalazs said? @ltoscano

In T11070#198378, @ltoscano wrote:

In T11070#198376, @ppeter wrote:

In T11070#198358, @ltoscano wrote:

I mentioned it elsewhere, but before doing this, it should be clear how much the changes made to the underlying repository (file rename, file changes which do not pass through the online tool) impact the online tool.
Also, I'd personally invest more time into preparation work which would reduce the amount of changes that may break the strings, like for example:

• flattening the directory structure removing the modules (so <lang>/messages/<repository>/<po_file> instead of <lang>/messages/<module>/<po_file>
• a mechanism to detect file renames and magically handles them
• move everyone to POSummit, so that there is just one branch to take care of;
  
  With less underlying moving part, implementing a web interface would be easier.

We can make <lang>/messages/<repository>/<po_file>.po as <lang>/messages/<repository>/<module>_<po_file>.po.

That would make things more difficult. In fact modules must disappear from there, because otherwise repositories moving among modules will increase the number of moves. We just manage to remove the module name from json and desktop files translations, and having them back won't simply happen.

The idea to have show which module a program belong to from l10n.kde.org (which is a reason why probably need Damned Lies anyway, regardless of whether an online tool is there or not).

In T11070#198355, @sanecito wrote:

If KDE can't provide a test Weblate server, I can front one on my own dime. A server on Linode that meets the 2 core + 2 GB recommended specs goes for $20/month.

The other thing we'd need to know is who we could contact to connect the test Weblate instance to whatever integration/pre-prod infrastrucutre KDE has to make sure the seamless SVN integration bits all check out. In particular I believe some KDE sysadmin would need to provide some faceless account that would handle the automated pushes/pulls between integration/pre-prod Summit and Weblate.

In T11070#198358, @ltoscano wrote:

I mentioned it elsewhere, but before doing this, it should be clear how much the changes made to the underlying repository (file rename, file changes which do not pass through the online tool) impact the online tool.
Also, I'd personally invest more time into preparation work which would reduce the amount of changes that may break the strings, like for example:

• flattening the directory structure removing the modules (so <lang>/messages/<repository>/<po_file> instead of <lang>/messages/<module>/<po_file>
• a mechanism to detect file renames and magically handles them
• move everyone to POSummit, so that there is just one branch to take care of;
  
  With less underlying moving part, implementing a web interface would be easier.

So I made a RFC for this changes, and I hope it is helpful for migrating to Weblate. Hope it successful! :)