In T11070#230948, @ltoscano wrote:

I agree it's useful when you don't have tooling for it, but as I said, this (update POs with newer POTs) should happen and will continue to happen outside weblate (or any other such tool).

It's not that we don't have the tools to do that. But it's about the fact that we wanted it that way.

We have a tool to update the POT files in the master branch, where about updating the PO, we want Weblate to take care of it – simply because we have decided that Weblate should be authoritative for PO files.

While the same tool for stable branch not only updates the POT files, but also updates the PO files according to the POT in the stable branch and at the same time merge translations from the PO files from the master branch to the PO files in the stable branch.

In T11070#230949, @slavekb wrote:

In T11070#230948, @ltoscano wrote:

I agree it's useful when you don't have tooling for it, but as I said, this (update POs with newer POTs) should happen and will continue to happen outside weblate (or any other such tool).

It's not that we don't have the tools to do that. But it's about the fact that we wanted it that way.

We have a tool to update the POT files in the master branch, where about updating the PO, we want Weblate to take care of it – simply because we have decided that Weblate should be authoritative for PO files.

I understand that, but here it's different and no tool (including Weblate) should be the authoriative for PO files: the bare repository (now SVN, let's see in the future) should be the source.

While the same tool for stable branch not only updates the POT files, but also updates the PO files according to the POT in the stable branch and at the same time merge translations from the PO files from the master branch to the PO files in the stable branch.

That's interesting, but it conflicts with not having Weblate as the authoritative source. We partially have that with posummit.

In T11070#230950, @ltoscano wrote:

We have a tool to update the POT files in the master branch, where about updating the PO, we want Weblate to take care of it – simply because we have decided that Weblate should be authoritative for PO files.

I understand that, but here it's different and no tool (including Weblate) should be the authoriative for PO files: the bare repository (now SVN, let's see in the future) should be the source.

I understand. For us, the decision was as follows:

Gitea is a developer collaboration tool, Weblate is a translator collaboration tool. When both tools meet in the git repository. While developers store the results of their work via Gitea – including updating POT files, translators store the results of their work via Weblate – so PO files. That is why we consider Weblate to be an authoritative tool for managing PO files – including updates PO files according to POT. Of course, the result stored in the git repository is essential.

In T11070#192334, @lydia wrote:

The proposal is still focused a bit too much on the solution. What is it that we actually want to achieve? Make our software available to more people speaking different languages?

Just for clarification, imho of course the ultimate goal is to increase availability of translations. This task as I read it however explicitly is about lowering the entry barrier to make it easier for new contributors to start contributing.

Since it has been brought up on the mailing list and it might be useful: Maybe we should create a Wiki page to track the current state and requirements for this. Or keep the description here updated with all relevant information, so one does not have to read all comments here (plus the several threads in the mailing list) to get the complete picture.

Also, what do you think about creating some child tasks for this, so one can work and discuss on them separately.

I suggest (considering the points from the description):

• Evaluating benefits moving from SVN to git (GitLab)
• Improving documentation
• Evaluating the addition of a web-based system
• Evaluating improving the integration with existing systems (like identitfy)

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

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

SVN to gitlab is out of discussion for now, not until everything (moving files when renames happen, summit handling) is fully automated.

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.

In T11070#233718, @ltoscano wrote:

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

SVN to gitlab is out of discussion for now, not until everything (moving files when renames happen, summit handling) is fully automated.

In other words, switching from SVN to git (GitLab) also needs the current automation to be adjusted accordingly? Or is it currently not fully automated on SVN and should be automated there before switching to GitLab?

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.

Right now the workflow does not require identity registration. Any new system would respect the current schema (only people with devel access will be able to approve).

In T11070#233718, @ltoscano wrote:

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

SVN to gitlab is out of discussion for now, not until everything (moving files when renames happen, summit handling) is fully automated.

In other words, switching from SVN to git (GitLab) also needs the current automation to be adjusted accordingly? Or is it currently not fully automated on SVN and should be automated there before switching to GitLab?

Unrelated. Automation is still needed regardless, and even more before switching to git.

Right now the people who manage the repository can easily apply a global change to all languages. Splitting into per language git repositories would make management impossible. Having a single git repository may be complicate to handle for the various teams (even long term translators can easily work with svn, but git poses a few more challenges; teams who will only access through a web interface won't care.

In T11070#233740, @ltoscano wrote:

Right now the people who manage the repository can easily apply a global change to all languages. Splitting into per language git repositories would make management impossible. Having a single git repository may be complicate to handle for the various teams (even long term translators can easily work with svn, but git poses a few more challenges; teams who will only access through a web interface won't care.

Would using Git submodule and per-language repo solve this problem? Filesystem layout would be the same as current SVN in this case, there would be some overheads for update commands though.

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.

Right now the process doesn't satisfy it. The user should first contact the coordinator, which can take ages (because the coordinator has real life). And that is the reason why we lose people volunteering to translate. I've just had the case recently after we released Krita 4.3.0. When people heard words "mailing list", "subversion" and "send files", they just said "Are you crazy to ask us to go though all this hell for translating a single line?"

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.

This is not related to this task.

Right now the process doesn't satisfy it. The user should first contact the coordinator, which can take ages (because the coordinator has real life). And that is the reason why we lose people volunteering to translate. I've just had the case recently after we released Krita 4.3.0. When people heard words "mailing list", "subversion" and "send files", they just said "Are you crazy to ask us to go though all this hell for translating a single line?"

That's about web tools and injecting strings, which are different tasks.

In T11070#237777, @ltoscano wrote:

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.

This is not related to this task.

Could you please link the correct task I should add that to? This discussion has been already ruled out from the "move to git" thread. Where should it go?

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#237779, @ltoscano wrote:

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.

Well, modern tools can compile 'mo' files themselves, which the user can then substitute in his app for testing. So this requirement is fully legit.

@dkazakov I think the requirement is legitimate, at least this is the topmost task we currently have for improvement of the localization and the request seems to be in that scope. I also think that @ltoscano agrees reading his comment above.

I am not really into the translation workflow, but this might be also interesting for other people following the discussion: What modern tools are you talking about? Is this some online tool, some commandline tool or something else? Can you reference some example for such tool (and maybe also an example for the entire workflow you expect, since there are probably already projects doing this in a good way)?

In T11070#237775, @dkazakov wrote:

• 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.

Weblate has a screenshot feature, like show the place where string will be in. That kinda helps solve this problem

In T11070#237855, @clel wrote:

What modern tools are you talking about? Is this some online tool, some commandline tool or something else? Can you reference some example for such tool?

Well, I'm not a translator. I just tried the first commercial tool google suggested me and it supported compilation. I don't know if weblate supports that (perhaps it does). I just wanted to add a requirement to the list. I believe, compilation of .mo files is almost a mandatory feature for the user. Installing gettext and compiling translation files on non-linux systems is not an acceptable solution.

In T11070#237886, @dkazakov wrote:

Well, I'm not a translator. I just tried the first commercial tool google suggested me and it supported compilation. I don't know if weblate supports that (perhaps it does). I just wanted to add a requirement to the list. I believe, compilation of .mo files is almost a mandatory feature for the user. Installing gettext and compiling translation files on non-linux systems is not an acceptable solution.

Weblate allows to download the MO file directly from the web interface. The user does not need any other tool to get the MO file.

Likewise, Weblate allows to upload a PO file if the user wants to use some offline translation tool.

In T11070#237886, @dkazakov wrote:

In T11070#237855, @clel wrote:

What modern tools are you talking about? Is this some online tool, some commandline tool or something else? Can you reference some example for such tool?

Well, I'm not a translator. I just wanted to add a requirement to the list.

Maybe we should let actual translators define the requirements of what they need/want?

In T11070#237890, @aacid wrote:

Maybe we should let actual translators define the requirements of what they need/want?

Of course we should let them do that. But we should also let other people place requests that are related to translations.

The priority might not be that high, but it seems that the request is easy to fulfil, either later by some additional tools or directly by tools like Weblate (thanks @slavekb for mentioning that).

@yurchor I move the conversation here, since it seems to have nothing to do with the old task's topic anymore.

In T13514#237943, @yurchor wrote:

In T13514#237939, @clel wrote:

In T13514#237910, @yurchor wrote:

In T13514#237909, @clel wrote:

Alright. Then I don't really understand what problems you have with Weblate. The things you wrote are too general for me to understand what the concrete problems are that you experience.

Sure. Just one thing that I do not understand is that people who do not really understand how the translation system works eagerly want to change that system.

When you write "Sure", I expect some more insights :) You wrote about problems you had but did not really give much detail about them. You talk about Weblate being much slower than offline tools while not mentioning which parts of the workflow you are talking about (admin stuff, translation itself, downloading and uploading PO files?).

All of them. There is no need for offline administration, translating every string through web interface is several times longer even in the zen mode, "downloading" new strings through Subversion then found what to translate in Lokalize takes ~5 seconds, analyzing big projects (Fedora is smaller than KDE now) in Weblate takes minutes. Uploading big files (libguestfs and its man, libvirt, Weblate docs, etc.) literally takes up to 10 minutes for just one file. I can imagine how long it would be to upload KStars, Krita and its docs (the last update required several dozens of files to be uploaded, the translation itself contains several hundred files), RKWard, KMyMoney or LabPlot.

Interesting. I only sporadically worked with online translation tools like Crowdin and Transifex, but never noticed any slow behaviour when translating strings. I assumed it would just be similar in speed to any offline tool. You write several times slower, that means a factor of 3 or higher? That only seems plausible for very specific tasks like searching for a wrongly translated String maybe that one wants to correct.

Moreover, Krita developers seems want some kind of CI with ready-to-use packages after every translation. I think it's a dream without some kind of powerful cluster at hand with the current state of art.

Hm, thanks for the insight on that. I assumed that just syncing the changes to a repository won't take long. Might this be related to a special way the project is setup?

What leads to the merge conflicts?

Developers, translators, and the automatic merging system working in parallel. Just the last example from Hosted Weblate. Two days ago Michal decided to upload new translations when I tried to upload my translation. This resulted in automated push into the Weblate repo then renewal and locking translation in the web interface. For several hours all translations were locked. Should I do not have an offline translation, my translations would be lost after Michal resolving the merge conflict manually.

Did you both upload through the Weblate interface? That is indeed a bad situation then.

Fedora's translations are broken this way almost every week. The only savior is that they change very rarely.

The similar GNOME project (DL) is also *very* fragile (broken every month or so).

Are there any bug reports about this? Basically if what you write is true, those systems seem to handle conflicts rather poorly.

Uploading PO files while the same lines have been changed through the online interface? You wrote you would have to work with KDE translations "through a web interface". What tasks are you referring to when you say "work"? Translation itself apparently not, since you say you are aware that you can download and upload PO files.

Yes, I am. I do not have an additional hour in a day just to upload ~50-60 changed strings in the KDE everyday package. It's not a Fedora with its ~100 new strings in a month or GNOME with its average 5 new strings in a day.

So if talking about the slowness of doing translations through the web GUI, I refer to my answer above. From my perspective that has never been a problem.

So what is taking so long there? You mention uploading translations takes "~15 minutes a day", can you give some details? Are we talking about some maintenance stuff or actually contributions to translations? Why do you imply that translations themselves are slower with Weblate?

Just try to use Weblate somewhere. Then you will understand. You will lose time on every single step - finding what to translate, opening catalog, finding what you need to translate, translating, opening the next string, dealing with stupid quality checks (absolutely impossible thing on the large catalogs).

Good point, I guess I better will try it out. Maybe somebody already using Weblate can also give some opinion on this, ping @subins2000

Regarding your question, which I felt was a bit insulting and implying things that are not true: There has been a long discussion already that contribution to translations should be made easier, possibly by a web-based system like Weblate.

Sorry, but the main role in such discussions is for the people that (guess what?) just want to translate one application. For this scale, there will be no substantial disadvantages for offline systems. Their shortcomings (low speed, bad scalability) comes with good accessibility and some automation.

Not sure whether I understood what you were saying here. That web-based systems are ok for casual users but fail the needs of power users? And that offline translation does not really have disadvantages for casual users? In that case I have to say that many users maybe just want to quickly correct some Strings for their application that they use. Having to get familiar with a rather complicated and for that task to complex offline workflow is a high barrier. Also note that after fixing those Strings, those users might just continue to translate more missing Strings of the project and become more involved.

This task however is not about that. My question here mainly was why one central repository for all translations is needed instead of for example hosting them together in each project's repository.

Because of the scale of our project. You've got this answer several times above.

And I replied with follow-up questions several times.

Currently I have not really seen a reason why that would cause a problem, but knowing that I don't know how the entire system is setup, I of course think there might be reasons why that is not a good idea. That is why I asked for such reasons.

I'm a scientist. Please give me those numbers that show that Weblate (Transifex, Rosetta, etc.) make translation "easier" for translators (e.g. "The XX translation service gives the project 2 times more translators and 4 times more translations in the long run because it's easy"). Hopefully with your definition of "easier". Thanks in advance.

I was talking about storing and managing translation files directly in each project's repo here, not about the introduction of Weblate, I guess there has been some misunderstanding.

Regarding your question: I never mentioned any numbers. Also, to give correct context: I was talking about contribution, not translation. If we mean the same about it, that is fine. However I want to make sure it also involves overcoming the entry barrier, not just the process of pure translation. I don't have the numbers you asked for. They might exist somewhere, however, although speaking scientifically, they are probably not generated in an experiment following scientific standards, so their value would still be questionable. The whole discussion until now was rather using the following argumentation: If it were possible to lower the entry barrier for new translators (which can be shown to be true for using a web-based system) while at the same time not making the other workflows worse, that would be a win. Obviously one has to make pretty sure not to make the other workflows worse to be sure the change will really be an improvement.

Speaking anecdotally, I'd contributed through such a system fixing at least two small mistakes I came across and probably also translating some outstanding Strings (rating from what I did in the past on other projects). Also I think there are several more anecdotes like this around in the KDE community. Only they are hard to use as scientific justification.

Online translation tools can make access to translation easier (not even in every case) but they definitely make the translation process deadly longer. Everything comes with its price.

I would doubt that they make the translation process deadly longer in every case. Maybe in some corner cases that get more relevant for power users. That is why I think it is pretty important to be able to maintain their workflow, at least in a way there won't be substantial or maybe noticeable disadvantages.

In T11070#237987, @clel wrote:

@yurchor I move the conversation here, since it seems to have nothing to do with the old task's topic anymore.

In T13514#237943, @yurchor wrote:

In T13514#237939, @clel wrote:

In T13514#237910, @yurchor wrote:

In T13514#237909, @clel wrote:

Alright. Then I don't really understand what problems you have with Weblate. The things you wrote are too general for me to understand what the concrete problems are that you experience.

Sure. Just one thing that I do not understand is that people who do not really understand how the translation system works eagerly want to change that system.

When you write "Sure", I expect some more insights :) You wrote about problems you had but did not really give much detail about them. You talk about Weblate being much slower than offline tools while not mentioning which parts of the workflow you are talking about (admin stuff, translation itself, downloading and uploading PO files?).

All of them. There is no need for offline administration, translating every string through web interface is several times longer even in the zen mode, "downloading" new strings through Subversion then found what to translate in Lokalize takes ~5 seconds, analyzing big projects (Fedora is smaller than KDE now) in Weblate takes minutes. Uploading big files (libguestfs and its man, libvirt, Weblate docs, etc.) literally takes up to 10 minutes for just one file. I can imagine how long it would be to upload KStars, Krita and its docs (the last update required several dozens of files to be uploaded, the translation itself contains several hundred files), RKWard, KMyMoney or LabPlot.

Interesting. I only sporadically worked with online translation tools like Crowdin and Transifex, but never noticed any slow behaviour when translating strings. I assumed it would just be similar in speed to any offline tool. You write several times slower, that means a factor of 3 or higher? That only seems plausible for very specific tasks like searching for a wrongly translated String maybe that one wants to correct.

No. And you know what I mean. Typing, for sure, is as fast as for offline tools. But switching between translations is slow. And it eats plenty of time if you typing fast. It takes ~3-4 seconds just to switch between translations.

Moreover, Krita developers seems want some kind of CI with ready-to-use packages after every translation. I think it's a dream without some kind of powerful cluster at hand with the current state of art.

Hm, thanks for the insight on that. I assumed that just syncing the changes to a repository won't take long. Might this be related to a special way the project is setup?

What leads to the merge conflicts?

Developers, translators, and the automatic merging system working in parallel. Just the last example from Hosted Weblate. Two days ago Michal decided to upload new translations when I tried to upload my translation. This resulted in automated push into the Weblate repo then renewal and locking translation in the web interface. For several hours all translations were locked. Should I do not have an offline translation, my translations would be lost after Michal resolving the merge conflict manually.

Did you both upload through the Weblate interface? That is indeed a bad situation then.

Yes, the Weblate main developer and I just do not know what we are doing. We are bad guys.

Fedora's translations are broken this way almost every week. The only savior is that they change very rarely.

The similar GNOME project (DL) is also *very* fragile (broken every month or so).

Are there any bug reports about this? Basically if what you write is true, those systems seem to handle conflicts rather poorly.

Just read the gnome-i18n@ for the last several months. The complaints there are just 1/3 of the real cases when DL was offline.

https://mail.gnome.org/archives/gnome-i18n/2020-March/msg00120.html

https://mail.gnome.org/archives/gnome-i18n/2020-March/msg00097.html

https://mail.gnome.org/archives/gnome-i18n/2020-April/msg00045.html

https://mail.gnome.org/archives/gnome-i18n/2020-May/msg00055.html

https://mail.gnome.org/archives/gnome-i18n/2020-May/msg00038.html

https://mail.gnome.org/archives/gnome-i18n/2020-June/msg00041.html

https://mail.gnome.org/archives/gnome-i18n/2020-June/msg00020.html

https://mail.gnome.org/archives/gnome-i18n/2020-July/msg00019.html

https://mail.gnome.org/archives/gnome-i18n/2020-August/msg00030.html

Uploading PO files while the same lines have been changed through the online interface? You wrote you would have to work with KDE translations "through a web interface". What tasks are you referring to when you say "work"? Translation itself apparently not, since you say you are aware that you can download and upload PO files.

Yes, I am. I do not have an additional hour in a day just to upload ~50-60 changed strings in the KDE everyday package. It's not a Fedora with its ~100 new strings in a month or GNOME with its average 5 new strings in a day.

So if talking about the slowness of doing translations through the web GUI, I refer to my answer above. From my perspective that has never been a problem.

That's fine. If it solves no translator's problems why it should be implemented?

So what is taking so long there? You mention uploading translations takes "~15 minutes a day", can you give some details? Are we talking about some maintenance stuff or actually contributions to translations? Why do you imply that translations themselves are slower with Weblate?

Just try to use Weblate somewhere. Then you will understand. You will lose time on every single step - finding what to translate, opening catalog, finding what you need to translate, translating, opening the next string, dealing with stupid quality checks (absolutely impossible thing on the large catalogs).

Good point, I guess I better will try it out. Maybe somebody already using Weblate can also give some opinion on this, ping @subins2000

Regarding your question, which I felt was a bit insulting and implying things that are not true: There has been a long discussion already that contribution to translations should be made easier, possibly by a web-based system like Weblate.

Sorry, but the main role in such discussions is for the people that (guess what?) just want to translate one application. For this scale, there will be no substantial disadvantages for offline systems. Their shortcomings (low speed, bad scalability) comes with good accessibility and some automation.

Not sure whether I understood what you were saying here. That web-based systems are ok for casual users but fail the needs of power users? And that offline translation does not really have disadvantages for casual users? In that case I have to say that many users maybe just want to quickly correct some Strings for their application that they use. Having to get familiar with a rather complicated and for that task to complex offline workflow is a high barrier. Also note that after fixing those Strings, those users might just continue to translate more missing Strings of the project and become more involved.

No. I say that they are good (maybe excellent) for two cases

1. The project is relatively small (not more than 10 subprojects).
2. The changes rate is low (<50 messages per week).

They are an absolute failure for big projects and fast changes. There will be nothing to correct if it is impossible or hard to create the bulk translation first.

This task however is not about that. My question here mainly was why one central repository for all translations is needed instead of for example hosting them together in each project's repository.

Because of the scale of our project. You've got this answer several times above.

And I replied with follow-up questions several times.

Currently I have not really seen a reason why that would cause a problem, but knowing that I don't know how the entire system is setup, I of course think there might be reasons why that is not a good idea. That is why I asked for such reasons.

I'm a scientist. Please give me those numbers that show that Weblate (Transifex, Rosetta, etc.) make translation "easier" for translators (e.g. "The XX translation service gives the project 2 times more translators and 4 times more translations in the long run because it's easy"). Hopefully with your definition of "easier". Thanks in advance.

I was talking about storing and managing translation files directly in each project's repo here, not about the introduction of Weblate, I guess there has been some misunderstanding.

Regarding your question: I never mentioned any numbers. Also, to give correct context: I was talking about contribution, not translation. If we mean the same about it, that is fine. However I want to make sure it also involves overcoming the entry barrier, not just the process of pure translation. I don't have the numbers you asked for. They might exist somewhere, however, although speaking scientifically, they are probably not generated in an experiment following scientific standards, so their value would still be questionable. The whole discussion until now was rather using the following argumentation: If it were possible to lower the entry barrier for new translators (which can be shown to be true for using a web-based system) while at the same time not making the other workflows worse, that would be a win. Obviously one has to make pretty sure not to make the other workflows worse to be sure the change will really be an improvement.

What if I tell you that there is no need to lower the entry barrier? What if it's just a Lotka-Volterra system where you want to kill the foxes to save rabbits and then the system is just died out?

We have already had two projects with lowered barriers (UserBase wiki documentation and WikiToLearn). Can we study the effects of lowering down the barriers in these cases first?

Speaking anecdotally, I'd contributed through such a system fixing at least two small mistakes I came across and probably also translating some outstanding Strings (rating from what I did in the past on other projects). Also I think there are several more anecdotes like this around in the KDE community. Only they are hard to use as scientific justification.

O-o-h, yes! Can we lower the barriers for the code to have more anecdotes about KDE software?

Online translation tools can make access to translation easier (not even in every case) but they definitely make the translation process deadly longer. Everything comes with its price.

I would doubt that they make the translation process deadly longer in every case. Maybe in some corner cases that get more relevant for power users. That is why I think it is pretty important to be able to maintain their workflow, at least in a way there won't be substantial or maybe noticeable disadvantages.

Then I'm here to tell you this sad news. Online platforms are not silver bullets. They solve no problems. Even their authors know this (Weblate docs quote):

https://docs.weblate.org/en/latest/contributing/about.html

About Weblate
Project goals
Web-based continuous localization tool with tight Version control integration supporting a wide range of Supported file formats, making it easy for translators to contribute.

(not "to translate", not "to be effective", just "to contribute")

They can have some Hawthorne effect (can be seen for UserBase and WikiToLearn) for the short runs but they stagnate in the long run because of their indisposable issues.

https://en.wikipedia.org/wiki/Hawthorne_effect

So if you just want to have more items in the team lists (most of them with ~0 % of contribution) then go on with the online tools. But be aware that the translation coverage and the quality will go down then. Dixi.

In T11070#237992, @yurchor wrote:

In T11070#237987, @clel wrote:

@yurchor I move the conversation here, since it seems to have nothing to do with the old task's topic anymore.

In T13514#237943, @yurchor wrote:

In T13514#237939, @clel wrote:

In T13514#237910, @yurchor wrote:

In T13514#237909, @clel wrote:

Alright. Then I don't really understand what problems you have with Weblate. The things you wrote are too general for me to understand what the concrete problems are that you experience.

Sure. Just one thing that I do not understand is that people who do not really understand how the translation system works eagerly want to change that system.

When you write "Sure", I expect some more insights :) You wrote about problems you had but did not really give much detail about them. You talk about Weblate being much slower than offline tools while not mentioning which parts of the workflow you are talking about (admin stuff, translation itself, downloading and uploading PO files?).

All of them. There is no need for offline administration, translating every string through web interface is several times longer even in the zen mode, "downloading" new strings through Subversion then found what to translate in Lokalize takes ~5 seconds, analyzing big projects (Fedora is smaller than KDE now) in Weblate takes minutes. Uploading big files (libguestfs and its man, libvirt, Weblate docs, etc.) literally takes up to 10 minutes for just one file. I can imagine how long it would be to upload KStars, Krita and its docs (the last update required several dozens of files to be uploaded, the translation itself contains several hundred files), RKWard, KMyMoney or LabPlot.

Interesting. I only sporadically worked with online translation tools like Crowdin and Transifex, but never noticed any slow behaviour when translating strings. I assumed it would just be similar in speed to any offline tool. You write several times slower, that means a factor of 3 or higher? That only seems plausible for very specific tasks like searching for a wrongly translated String maybe that one wants to correct.

No. And you know what I mean. Typing, for sure, is as fast as for offline tools. But switching between translations is slow. And it eats plenty of time if you typing fast. It takes ~3-4 seconds just to switch between translations.

I will test that to verify. Thanks for clarifying. And no, I did not know what you meant :)

What leads to the merge conflicts?

Developers, translators, and the automatic merging system working in parallel. Just the last example from Hosted Weblate. Two days ago Michal decided to upload new translations when I tried to upload my translation. This resulted in automated push into the Weblate repo then renewal and locking translation in the web interface. For several hours all translations were locked. Should I do not have an offline translation, my translations would be lost after Michal resolving the merge conflict manually.

Did you both upload through the Weblate interface? That is indeed a bad situation then.

Yes, the Weblate main developer and I just do not know what we are doing. We are bad guys.

Look, this is not what I said. I acknowledged that the Weblate tool is designed in a bad way then, if it causes problems like that. I think there might be a language barrier here causing some misunderstanding.

Fedora's translations are broken this way almost every week. The only savior is that they change very rarely.

The similar GNOME project (DL) is also *very* fragile (broken every month or so).

Are there any bug reports about this? Basically if what you write is true, those systems seem to handle conflicts rather poorly.

Just read the gnome-i18n@ for the last several months. The complaints there are just 1/3 of the real cases when DL was offline.

https://mail.gnome.org/archives/gnome-i18n/2020-March/msg00120.html

https://mail.gnome.org/archives/gnome-i18n/2020-March/msg00097.html

https://mail.gnome.org/archives/gnome-i18n/2020-April/msg00045.html

https://mail.gnome.org/archives/gnome-i18n/2020-May/msg00055.html

https://mail.gnome.org/archives/gnome-i18n/2020-May/msg00038.html

https://mail.gnome.org/archives/gnome-i18n/2020-June/msg00041.html

https://mail.gnome.org/archives/gnome-i18n/2020-June/msg00020.html

https://mail.gnome.org/archives/gnome-i18n/2020-July/msg00019.html

https://mail.gnome.org/archives/gnome-i18n/2020-August/msg00030.html

Thanks, will do so. So there are no actual bug reports then?

Uploading PO files while the same lines have been changed through the online interface? You wrote you would have to work with KDE translations "through a web interface". What tasks are you referring to when you say "work"? Translation itself apparently not, since you say you are aware that you can download and upload PO files.

Yes, I am. I do not have an additional hour in a day just to upload ~50-60 changed strings in the KDE everyday package. It's not a Fedora with its ~100 new strings in a month or GNOME with its average 5 new strings in a day.

So if talking about the slowness of doing translations through the web GUI, I refer to my answer above. From my perspective that has never been a problem.

That's fine. If it solves no translator's problems why it should be implemented?

I don't understand what you are saying here.

Regarding your question, which I felt was a bit insulting and implying things that are not true: There has been a long discussion already that contribution to translations should be made easier, possibly by a web-based system like Weblate.

Sorry, but the main role in such discussions is for the people that (guess what?) just want to translate one application. For this scale, there will be no substantial disadvantages for offline systems. Their shortcomings (low speed, bad scalability) comes with good accessibility and some automation.

Not sure whether I understood what you were saying here. That web-based systems are ok for casual users but fail the needs of power users? And that offline translation does not really have disadvantages for casual users? In that case I have to say that many users maybe just want to quickly correct some Strings for their application that they use. Having to get familiar with a rather complicated and for that task to complex offline workflow is a high barrier. Also note that after fixing those Strings, those users might just continue to translate more missing Strings of the project and become more involved.

No. I say that they are good (maybe excellent) for two cases

1. The project is relatively small (not more than 10 subprojects).
2. The changes rate is low (<50 messages per week).
   
   They are an absolute failure for big projects and fast changes. There will be nothing to correct if it is impossible or hard to create the bulk translation first.

I am not enough into this to know what a bulk translation is or there are language barriers again.

Currently I have not really seen a reason why that would cause a problem, but knowing that I don't know how the entire system is setup, I of course think there might be reasons why that is not a good idea. That is why I asked for such reasons.

I'm a scientist. Please give me those numbers that show that Weblate (Transifex, Rosetta, etc.) make translation "easier" for translators (e.g. "The XX translation service gives the project 2 times more translators and 4 times more translations in the long run because it's easy"). Hopefully with your definition of "easier". Thanks in advance.

I was talking about storing and managing translation files directly in each project's repo here, not about the introduction of Weblate, I guess there has been some misunderstanding.

Regarding your question: I never mentioned any numbers. Also, to give correct context: I was talking about contribution, not translation. If we mean the same about it, that is fine. However I want to make sure it also involves overcoming the entry barrier, not just the process of pure translation. I don't have the numbers you asked for. They might exist somewhere, however, although speaking scientifically, they are probably not generated in an experiment following scientific standards, so their value would still be questionable. The whole discussion until now was rather using the following argumentation: If it were possible to lower the entry barrier for new translators (which can be shown to be true for using a web-based system) while at the same time not making the other workflows worse, that would be a win. Obviously one has to make pretty sure not to make the other workflows worse to be sure the change will really be an improvement.

What if I tell you that there is no need to lower the entry barrier? What if it's just a Lotka-Volterra system where you want to kill the foxes to save rabbits and then the system is just died out?

I gave you anecdotical examples where the barrier in fact was to high. So you telling me there might be no need to lower the barrier is just some speculation not even based on anecdotical evidence and also not backed up by some other logical explanation. Your comparison with a Lotka-Volterra system is just not really working. If you kill the foxes, the rabbits will thrive based on that model. Also you did not even define what you are referring to with foxes and rabbits in the real world.

We have already had two projects with lowered barriers (UserBase wiki documentation and WikiToLearn). Can we study the effects of lowering down the barriers in these cases first?

Feel free to do so. Just be aware that those cases might not be comparable to this one from a scientific standpoint.

Speaking anecdotally, I'd contributed through such a system fixing at least two small mistakes I came across and probably also translating some outstanding Strings (rating from what I did in the past on other projects). Also I think there are several more anecdotes like this around in the KDE community. Only they are hard to use as scientific justification.

O-o-h, yes! Can we lower the barriers for the code to have more anecdotes about KDE software?

I don't get what you are trying to say here.

Online translation tools can make access to translation easier (not even in every case) but they definitely make the translation process deadly longer. Everything comes with its price.

I would doubt that they make the translation process deadly longer in every case. Maybe in some corner cases that get more relevant for power users. That is why I think it is pretty important to be able to maintain their workflow, at least in a way there won't be substantial or maybe noticeable disadvantages.

Then I'm here to tell you this sad news. Online platforms are not silver bullets. They solve no problems. Even their authors know this (Weblate docs quote):

https://docs.weblate.org/en/latest/contributing/about.html

About Weblate
Project goals
Web-based continuous localization tool with tight Version control integration supporting a wide range of Supported file formats, making it easy for translators to contribute.

(not "to translate", not "to be effective", just "to contribute")

Using this quote as some reference for your statement that the author would "know", that "online platforms" would "solve no problems" does not work. Even if we don't consider the fact that you use weird definitons of the verbs "contribute" and "translate" (with "contribute" apparently not involving "translate"), this still is not useful, since obviously the author says that the tool solves the problem of easy contribution. This whole argument does not really seem based on scientific standards.

They can have some Hawthorne effect (can be seen for UserBase and WikiToLearn) for the short runs but they stagnate in the long run because of their indisposable issues.

https://en.wikipedia.org/wiki/Hawthorne_effect

That the Hawthorne effect plays a role there is probably just speculation on your side. Just speaking for me, I would have used the system in the past, if it were there. Also without knowing that there was monitoring going on (which there wasn't). That would be the premise, so the Hawthorne effect could even play a role. But okay, that effect might have played a role, but probably not a relevant one, especially when it comes to the reasons why those projects stagnated "in the long run" (on which level, by the way?).

So if you just want to have more items in the team lists (most of them with ~0 % of contribution) then go on with the online tools. But be aware that the translation coverage and the quality will go down then. Dixi.

As I told before, I think it is crucial to maintain a good workflow for power users. Thus I don't see how coverage would decline then. The other points are probably just speculative again from your side.

In T11070#237992, @yurchor wrote:

In T11070#237987, @clel wrote:

@yurchor I move the conversation here, since it seems to have nothing to do with the old task's topic anymore.

In T13514#237943, @yurchor wrote:

Fedora's translations are broken this way almost every week. The only savior is that they change very rarely.

The similar GNOME project (DL) is also *very* fragile (broken every month or so).

Are there any bug reports about this? Basically if what you write is true, those systems seem to handle conflicts rather poorly.

Just read the gnome-i18n@ for the last several months. The complaints there are just 1/3 of the real cases when DL was offline.

I read them now. This just seems to be used as references that the damned lies system might have had some problems in the past. However, they seem not related to any conflicts with files, so there does not seem to be a problem with that.

https://mail.gnome.org/archives/gnome-i18n/2020-March/msg00120.html

Seems to be just a bad error message: https://mail.gnome.org/archives/gnome-i18n/2020-March/msg00123.html

https://mail.gnome.org/archives/gnome-i18n/2020-March/msg00097.html

Seems to be just a migration going on: https://mail.gnome.org/archives/gnome-i18n/2020-March/msg00100.html

https://mail.gnome.org/archives/gnome-i18n/2020-April/msg00045.html

Poor hosting performance: https://mail.gnome.org/archives/gnome-i18n/2020-April/msg00046.html

https://mail.gnome.org/archives/gnome-i18n/2020-May/msg00055.html

No follow-up: https://mail.gnome.org/archives/gnome-i18n/2020-May/msg00056.html

https://mail.gnome.org/archives/gnome-i18n/2020-May/msg00038.html

Confirmed bug that seems to already be fixed: https://mail.gnome.org/archives/gnome-i18n/2020-May/msg00041.html

https://mail.gnome.org/archives/gnome-i18n/2020-June/msg00041.html

Did not see what this was about or how it is related.

https://mail.gnome.org/archives/gnome-i18n/2020-June/msg00020.html

Seems to be a valid problem, probably already fixed, though.

https://mail.gnome.org/archives/gnome-i18n/2020-July/msg00019.html

Another problem.

https://mail.gnome.org/archives/gnome-i18n/2020-August/msg00030.html

Temporary failure related to reboots: https://mail.gnome.org/archives/gnome-i18n/2020-August/msg00032.html

It seems to me the system is far less bad than you try to imply here.

In T11070#237992, @yurchor wrote:

No. And you know what I mean. Typing, for sure, is as fast as for offline tools. But switching between translations is slow. And it eats plenty of time if you typing fast. It takes ~3-4 seconds just to switch between translations.

I just had a test with the dev tools in Firefox. It displayed me 1.45 s for loading the page with the next translation after submitting the previous one. I admit that this is noticeable, but accapteable and not really slowing down the translation process much. I tested on https://hosted.weblate.org/translate/osmand/ios/de/. Let me know if you have a different site where the performance is worse. Also, if it takes really 3-4 seconds for you, it might have to do with your setup. I don't say that to blame you, but to try to understand. That amount is clearly a bad user experience that one should try to avoid.

In T11070#237998, @clel wrote:

Fedora's translations are broken this way almost every week. The only savior is that they change very rarely.

The similar GNOME project (DL) is also *very* fragile (broken every month or so).

Are there any bug reports about this? Basically if what you write is true, those systems seem to handle conflicts rather poorly.

Just read the gnome-i18n@ for the last several months. The complaints there are just 1/3 of the real cases when DL was offline.

https://mail.gnome.org/archives/gnome-i18n/2020-March/msg00120.html

https://mail.gnome.org/archives/gnome-i18n/2020-March/msg00097.html

https://mail.gnome.org/archives/gnome-i18n/2020-April/msg00045.html

https://mail.gnome.org/archives/gnome-i18n/2020-May/msg00055.html

https://mail.gnome.org/archives/gnome-i18n/2020-May/msg00038.html

https://mail.gnome.org/archives/gnome-i18n/2020-June/msg00041.html

https://mail.gnome.org/archives/gnome-i18n/2020-June/msg00020.html

https://mail.gnome.org/archives/gnome-i18n/2020-July/msg00019.html

https://mail.gnome.org/archives/gnome-i18n/2020-August/msg00030.html

Thanks, will do so. So there are no actual bug reports then?

Come on... From the bureaucratic point of view, "no bug reports" is "no bugs". But all the developers on the mailing list and they definitely know the situation.

https://gitlab.gnome.org/Infrastructure/damned-lies/-/issues/184
https://gitlab.gnome.org/Infrastructure/damned-lies/-/issues/177
https://gitlab.gnome.org/Infrastructure/damned-lies/-/issues/176

Uploading PO files while the same lines have been changed through the online interface? You wrote you would have to work with KDE translations "through a web interface". What tasks are you referring to when you say "work"? Translation itself apparently not, since you say you are aware that you can download and upload PO files.

Yes, I am. I do not have an additional hour in a day just to upload ~50-60 changed strings in the KDE everyday package. It's not a Fedora with its ~100 new strings in a month or GNOME with its average 5 new strings in a day.

So if talking about the slowness of doing translations through the web GUI, I refer to my answer above. From my perspective that has never been a problem.

That's fine. If it solves no translator's problems why it should be implemented?

I don't understand what you are saying here.

I'm saying that you are trying to manipulate the facts. You are trying to convince me that web GUI is as fast as offline.

Regarding your question, which I felt was a bit insulting and implying things that are not true: There has been a long discussion already that contribution to translations should be made easier, possibly by a web-based system like Weblate.

Sorry, but the main role in such discussions is for the people that (guess what?) just want to translate one application. For this scale, there will be no substantial disadvantages for offline systems. Their shortcomings (low speed, bad scalability) comes with good accessibility and some automation.

Not sure whether I understood what you were saying here. That web-based systems are ok for casual users but fail the needs of power users? And that offline translation does not really have disadvantages for casual users? In that case I have to say that many users maybe just want to quickly correct some Strings for their application that they use. Having to get familiar with a rather complicated and for that task to complex offline workflow is a high barrier. Also note that after fixing those Strings, those users might just continue to translate more missing Strings of the project and become more involved.

No. I say that they are good (maybe excellent) for two cases

1. The project is relatively small (not more than 10 subprojects).
2. The changes rate is low (<50 messages per week).
   
   They are an absolute failure for big projects and fast changes. There will be nothing to correct if it is impossible or hard to create the bulk translation first.

I am not enough into this to know what a bulk translation is or there are language barriers again.

Ok. Can you tell me please how long does it take to translate 100 messages (~5 words per message on average) with Lokalize and Weblate online (zen mode). Does anybody ever measure the effect for docs.krita.org translation (~100000 words)? Who would take this translation if he/she knows that it takes 200 days in Weblate? Is this barrier low enough?

Of course, when you find a mistake in such a big translation, you can say that it is hard enough to fix it. But what should you do when one decided that it is not worth to fight Weblate deficiencies just to enable someone to say that barriers are not low enough?

Currently I have not really seen a reason why that would cause a problem, but knowing that I don't know how the entire system is setup, I of course think there might be reasons why that is not a good idea. That is why I asked for such reasons.

I'm a scientist. Please give me those numbers that show that Weblate (Transifex, Rosetta, etc.) make translation "easier" for translators (e.g. "The XX translation service gives the project 2 times more translators and 4 times more translations in the long run because it's easy"). Hopefully with your definition of "easier". Thanks in advance.

I was talking about storing and managing translation files directly in each project's repo here, not about the introduction of Weblate, I guess there has been some misunderstanding.

Regarding your question: I never mentioned any numbers. Also, to give correct context: I was talking about contribution, not translation. If we mean the same about it, that is fine. However I want to make sure it also involves overcoming the entry barrier, not just the process of pure translation. I don't have the numbers you asked for. They might exist somewhere, however, although speaking scientifically, they are probably not generated in an experiment following scientific standards, so their value would still be questionable. The whole discussion until now was rather using the following argumentation: If it were possible to lower the entry barrier for new translators (which can be shown to be true for using a web-based system) while at the same time not making the other workflows worse, that would be a win. Obviously one has to make pretty sure not to make the other workflows worse to be sure the change will really be an improvement.

What if I tell you that there is no need to lower the entry barrier? What if it's just a Lotka-Volterra system where you want to kill the foxes to save rabbits and then the system is just died out?

I gave you anecdotical examples where the barrier in fact was to high. So you telling me there might be no need to lower the barrier is just some speculation not even based on anecdotical evidence and also not backed up by some other logical explanation. Your comparison with a Lotka-Volterra system is just not really working. If you kill the foxes, the rabbits will thrive based on that model. Also you did not even define what you are referring to with foxes and rabbits in the real world.

And I'll give you ten examples where it was not high enough for each of your examples.

We have already had two projects with lowered barriers (UserBase wiki documentation and WikiToLearn). Can we study the effects of lowering down the barriers in these cases first?

Feel free to do so. Just be aware that those cases might not be comparable to this one from a scientific standpoint.

Absolutely comparable.

8 years ago I was told the following:

1. KDE Documentation is stale.
2. DocBook format is hard to understand.
3. Committing to SVG/Git is out of the scope for non-power users.
4. Wiki is easy.
5. Anybody will commit the new docs online.
6. We've got the translation extension, everybody can translate with ease.

During the first 2-3 years, UserBase was thriving. Dozens of users, hundreds of pages, many translations (literally months of my life). But then... Our main contributor (Anne Wilson) gone, our admin (Ingo Malchow) gone.

Now we have:

1. KDE Documentation is still up-to-date (UserBase is not).
2. DocBook format is still in use.
3. It is not easy to register on UserBase because of the spam attack prevention.
4. You should learn to create high-quality wiki pages as well.
5. UserBase is almost abandoned.
6. The translation extension is broken for almost one year. It is impossible to translate the new pages.

I beg you not to ruin what is working. Please do no make harm to this project. It is beautiful enough (best in the FOSS) to keep it as is.

Speaking anecdotally, I'd contributed through such a system fixing at least two small mistakes I came across and probably also translating some outstanding Strings (rating from what I did in the past on other projects). Also I think there are several more anecdotes like this around in the KDE community. Only they are hard to use as scientific justification.

O-o-h, yes! Can we lower the barriers for the code to have more anecdotes about KDE software?

I don't get what you are trying to say here.

Everybody can register on gitlab then use online editor (web-based) to fix the code and make it better. Low enough, isn't it? So why not use just online coding? And where all those new coders eager to improve the code and distracted by the high barriers of the old-fashioned previous systems?

Online translation tools can make access to translation easier (not even in every case) but they definitely make the translation process deadly longer. Everything comes with its price.

I would doubt that they make the translation process deadly longer in every case. Maybe in some corner cases that get more relevant for power users. That is why I think it is pretty important to be able to maintain their workflow, at least in a way there won't be substantial or maybe noticeable disadvantages.

Then I'm here to tell you this sad news. Online platforms are not silver bullets. They solve no problems. Even their authors know this (Weblate docs quote):

https://docs.weblate.org/en/latest/contributing/about.html

About Weblate
Project goals
Web-based continuous localization tool with tight Version control integration supporting a wide range of Supported file formats, making it easy for translators to contribute.

(not "to translate", not "to be effective", just "to contribute")

Using this quote as some reference for your statement that the author would "know", that "online platforms" would "solve no problems" does not work. Even if we don't consider the fact that you use weird definitons of the verbs "contribute" and "translate" (with "contribute" apparently not involving "translate"), this still is not useful, since obviously the author says that the tool solves the problem of easy contribution. This whole argument does not really seem based on scientific standards.

Ten chickens do not make one eagle. Contributing one line of the translation does not mean to translate.

They can have some Hawthorne effect (can be seen for UserBase and WikiToLearn) for the short runs but they stagnate in the long run because of their indisposable issues.

https://en.wikipedia.org/wiki/Hawthorne_effect

That the Hawthorne effect plays a role there is probably just speculation on your side. Just speaking for me, I would have used the system in the past, if it were there. Also without knowing that there was monitoring going on (which there wasn't). That would be the premise, so the Hawthorne effect could even play a role. But okay, that effect might have played a role, but probably not a relevant one, especially when it comes to the reasons why those projects stagnated "in the long run" (on which level, by the way?).

So if you just want to have more items in the team lists (most of them with ~0 % of contribution) then go on with the online tools. But be aware that the translation coverage and the quality will go down then. Dixi.

As I told before, I think it is crucial to maintain a good workflow for power users. Thus I don't see how coverage would decline then. The other points are probably just speculative again from your side.

There are no "power" users. The division line is not in the tools you are using. You can learn by the previous examples (Wikipedia, LP/Rosetta) that work for more than dozen years the "lowering" barriers in the way you propose does not solve problems with the contribution level. Your so-called "power users" (I call them actually "translators") adopt any system because they can learn. Your "lowered-barrier" users will translate two strings and will complain that even these barriers are high. And if you will make the "power users" life harder the only result can be the degraded translation.

In T11070#238001, @clel wrote:

In T11070#237992, @yurchor wrote:

No. And you know what I mean. Typing, for sure, is as fast as for offline tools. But switching between translations is slow. And it eats plenty of time if you typing fast. It takes ~3-4 seconds just to switch between translations.

I just had a test with the dev tools in Firefox. It displayed me 1.45 s for loading the page with the next translation after submitting the previous one. I admit that this is noticeable, but accapteable and not really slowing down the translation process much. I tested on https://hosted.weblate.org/translate/osmand/ios/de/. Let me know if you have a different site where the performance is worse. Also, if it takes really 3-4 seconds for you, it might have to do with your setup. I don't say that to blame you, but to try to understand. That amount is clearly a bad user experience that one should try to avoid.

I want some explanation for what reason you take 1.45 s of my life for each translation. Can you explain please why it is acceptable for me to lose them?

In T11070#238001, @clel wrote:

In T11070#237992, @yurchor wrote:

No. And you know what I mean. Typing, for sure, is as fast as for offline tools. But switching between translations is slow. And it eats plenty of time if you typing fast. It takes ~3-4 seconds just to switch between translations.

I just had a test with the dev tools in Firefox. It displayed me 1.45 s for loading the page with the next translation after submitting the previous one. I admit that this is noticeable, but accapteable and not really slowing down the translation process much. I tested on https://hosted.weblate.org/translate/osmand/ios/de/. Let me know if you have a different site where the performance is worse. Also, if it takes really 3-4 seconds for you, it might have to do with your setup. I don't say that to blame you, but to try to understand. That amount is clearly a bad user experience that one should try to avoid.

When I am typing Korean my typing speed is about 500-600 keystrokes per minute. I consider this as slightly above from average. 1.45 s is enough to complete one or two word translation on average. This kind of delay, when cumulated, seriously degrades my productivity. Also one of the reason why I don't want to use web-based translation management system, but not opposing the addition of it.

(Disclaimer: I've used Pootle, Launchpad, Zanata, Weblate before)

@yurchor

I won't answer all your points this time, since I think it just won't make too much sense. There is clearly some misunderstanding on your side about my motives. You seem to think I would want to force you to use Weblate which is not true. Also I understand that using Weblate would slow down your workflow. However you use a problematic discussion style to outline that. To me it seems there is some truth to your points, but it is pretty hard to get to it, since the truth is sometimes covered behind some arguments that don't really make sense. This includes coming up with some non-standard definitions of words like "translator".

As I said several times, I want to make sure to keep existing workflows.

@pshinjo Thanks for your insight. I did not know this is really having such a high impact, although I'd still argue that some of it probably is also a bit subjective and that one cannot simply use keystrokes per minute in that formula, since translation also involves some kind of processing in mind before typing the words.

However, I guess it is pretty clear that Weblate does not offer the responsiveness needed for a good translation experience for some users, so it is important to have an offline workflow. And since that is presumably, judging from what @yurchor wrote, also not ideal on Weblate (I might do some more investigation there as well), there is probably the need of some other way to contribute translations for an offline workflow.

@clel , the main point here is the focus on the tool, as if we open an online translation tool, this would aggregate more translators. Well, I really don't think so. And I have some examples.

Some time ago, when GCompris wasn't part of KDE ecosystem, I was its main translator and presented it in some free software meetings in Brazil. A lot of people, mainly teachers, loved it and offered to help with its translation and maintenance, specially with voice translations, our major demand. I set a Pootle instance to help them. One or two of them appeared, translated a few strings and never came back.

Another example. I coordinate some Android free softwares translations on Transifex. From time to time someone appears, ask to be part of the team, again, translate a few strings and disappear. Still, in Transifex, one of these softwares has a premium version and, during some time, its developer offered keys to those who contribute on translation. The result? A lot of string with bad translation, many completely out of context, looking like many of them was made using automatic translation.

My point here is that even if you use the easiest tool to facilitate translation, you have no guarantee that this will aggregate more translators to the teams. In fact, you could have an opposite effect and fragment these teams, with a lot of isolated contributions and no integration between them. What makes a strong and active community are the people and the way they manage it, not the tools they use. These tools can, at most, facilitate the management of the community or communication between their members.

Web-based translation tools make translations more accessible. They don't help you: 1. get more contributors/keep the current ones 2. help maintain translation quality. Those have nothing to do with the tool used unless the tool has major issues that drive people away, or the tool actively makes people translate worse for some reason.

In that case I have to say that many users maybe just want to quickly correct some Strings for their application that they use.

This is the crux of the issue, you think random drive-by people translating 2 strings is a good thing, I am almost convinced it isn't.

The time spent by the reviewer to review those 2 strings is just the same as if she translated them, so in the case the suggested drive-by translation is perfect, there's no real win.

But the truth is that most most probably the translation will not follow translation guidelines of that particular language (because you know, doing good translations is actually hard, do you know what's the different between Settings and Configuration and what's the terms used in the KDE translation for your language? Does it help if i add Parameters to the mix? What about Folder and Directory? And Widget?), so now the reviewer has to spend translating the message and explaining drive-by contributors why their suggestion is wrong.

The total time spent by the reviewer increases, the drive-by contributors that just translated 2 strings get annoyed because they don't feel their contribution being welcome (as their suggestion is not accepted) and the maintainer gets annoyed because she spent more time that just if she had done the work from scratch.

I can't prove this is what will happen to KDE if we do that, but it's what I've seen happen everywhere else.

In T11070#237987, @clel wrote:

In that case I have to say that many users maybe just want to quickly correct some Strings for their application that they use. Having to get familiar with a rather complicated and for that task to complex offline workflow is a high barrier.

We have i18n as a Bugzilla component which is quite actively used: https://bugs.kde.org/buglist.cgi?product=i18n (also mentioned in https://bugs.kde.org/show_bug.cgi?id=423171#c10). This will work faster for established teams when an external person wants to correct typos, missing translations, etc. Bugzilla user interface offered only in English might be an accessibility problem, but this should not be confused with a need for web-based translation system. I think for those small suggestions, promoting and exposing the information to contact the team in native language is more important than allowing anyone to access the translation directly. Windows 10 has Feedback Hub, at least users can report translation errors without touching the strings directly using their native language (I don't want to discuss how effectively Microsoft handles the feedback or daemonize Microsoft here)

I think web-based translation system can solve some accessibility problem especially for those who want to translate an application but no team had been established or their team is inactive. That's why I think web-based translation should be opt-in for each language so currently active team can maintain their traditional workflow directly using either SVN or git (possibly).

In T11070#238036, @aacid wrote:

In that case I have to say that many users maybe just want to quickly correct some Strings for their application that they use.

This is the crux of the issue, you think random drive-by people translating 2 strings is a good thing, I am almost convinced it isn't.

"Correct", not "translate". I am one of those users. One translation had a missing space (I opened a bug on Bugzilla and it got corrected extremely fast) and one had a capitalized letter where it should not be. I cannot simply fix those. This also shows that the quality of the translations is not always high. Although I am sure it still could be much worse, of course.

Also I think I noticed missing translations for my language. This shows the translation at least for Germany can be improved.

In T11070#238042, @pshinjo wrote:

In T11070#237987, @clel wrote:

In that case I have to say that many users maybe just want to quickly correct some Strings for their application that they use. Having to get familiar with a rather complicated and for that task to complex offline workflow is a high barrier.

We have i18n as a Bugzilla component which is quite actively used: https://bugs.kde.org/buglist.cgi?product=i18n (also mentioned in https://bugs.kde.org/show_bug.cgi?id=423171#c10). This will work faster for established teams when an external person wants to correct typos, missing translations, etc. Bugzilla user interface offered only in English might be an accessibility problem, but this should not be confused with a need for web-based translation system. I think for those small suggestions, promoting and exposing the information to contact the team in native language is more important than allowing anyone to access the translation directly. Windows 10 has Feedback Hub, at least users can report translation errors without touching the strings directly using their native language (I don't want to discuss how effectively Microsoft handles the feedback or daemonize Microsoft here)

I think web-based translation system can solve some accessibility problem especially for those who want to translate an application but no team had been established or their team is inactive. That's why I think web-based translation should be opt-in for each language so currently active team can maintain their traditional workflow directly using either SVN or git (possibly).

You might have some good points here. I understand that for an active team there is not much need for such a system. However, almost no language has all Strings translated already when looking at: https://l10n.kde.org/stats/gui/stable-kf5/team/. Quite the opposite if you look how much untranslated Strings there are for many languages. So apparently almost no team is active enough to reach a completeness level of 100 %. Thus I assume they lack the time and manpower.

I personally don't have a problem with Bugzilla being available in English, but the interface is pretty outdated plus I'd prefer directly changing the affected String instead of having to create a bug on Bugzilla.

In T11070#238043, @clel wrote:

You might have some good points here. I understand that for an active team there is not much need for such a system. However, almost no language has all Strings translated already when looking at: https://l10n.kde.org/stats/gui/stable-kf5/team/. Quite the opposite if you look how much untranslated Strings there are for many languages. So apparently almost no team is active enough to reach a completeness level of 100 %. Thus I assume they lack the time and manpower.

Just to say, GNOME's l10n system is called "Damned Lies" (https://en.wikipedia.org/wiki/Lies,_damned_lies,_and_statistics). Yes, only a small number of teams reach 100% in the statistics. I personally do not aim 100% there because:

• websites-kde-org/www_www.po contains ALL release notes dating back from KDE 4.x era. Even if I translate 100% of them who will practically read all of them? Also I don't direct other translators to touch them either.
• Big specialized applications: I would name Krita, KStars, GCompris, RKWard as examples. They require specialized domain knowledge for usage (and correct translation). For some languages, even finding a user who is using the application in English (and eventually willing for a translation) could be hard enough.

In T11070#238031, @kucharczyk wrote:

[...] Those have nothing to do with the tool used unless the tool has major issues that drive people away,

That is exactly the problem we have at the moment. The current workflow drives new contributors away.

In T11070#238010, @yurchor wrote:

In T11070#237998, @clel wrote:

O-o-h, yes! Can we lower the barriers for the code to have more anecdotes about KDE software?

I don't get what you are trying to say here.

Everybody can register on gitlab then use online editor (web-based) to fix the code and make it better. Low enough, isn't it? So why not use just online coding? And where all those new coders eager to improve the code and distracted by the high barriers of the old-fashioned previous systems?

You might not believe me, but I've seen a few people using the gitlab's online editor to modify patches and make commits. It is useful in some circumstances.

And, yes, here in Krita we constantly strive to lower the barriers for the code contributions: we make scripts for building Krita on all three major platforms, we make building AppImages easier, so people could use their custom builds in their workflow without waiting for a release.

And we have quite a good progress, btw. We are getting more and more people proposing MRs on GitLib. There is a lot of new contributors proposing some nice small changes.

In T11070#237887, @slavekb wrote:

Weblate allows to download the MO file directly from the web interface. The user does not need any other tool to get the MO file.
Likewise, Weblate allows to upload a PO file if the user wants to use some offline translation tool.

Hi, @slavekb!

Perhaps you know, does Weblate supports some kind of "locking" a translation file by the maintainer of the project? Such locking would really help people like @yurchor to do bulk-translations offline.

I mean, we could make a policy that "a translator can ask to lock a specific file for not more than N days(?)" to do the translations offline safely and push them into SVN/Git. And the rest of the time the files would be available for translations by other people through web-interface.

In T11070#238065, @dkazakov wrote:

In T11070#238031, @kucharczyk wrote:

[...] Those have nothing to do with the tool used unless the tool has major issues that drive people away,

That is exactly the problem we have at the moment. The current workflow drives new contributors away.

In T11070#238010, @yurchor wrote:

In T11070#237998, @clel wrote:

O-o-h, yes! Can we lower the barriers for the code to have more anecdotes about KDE software?

I don't get what you are trying to say here.

Everybody can register on gitlab then use online editor (web-based) to fix the code and make it better. Low enough, isn't it? So why not use just online coding? And where all those new coders eager to improve the code and distracted by the high barriers of the old-fashioned previous systems?

You might not believe me, but I've seen a few people using the gitlab's online editor to modify patches and make commits. It is useful in some circumstances.

And, yes, here in Krita we constantly strive to lower the barriers for the code contributions: we make scripts for building Krita on all three major platforms, we make building AppImages easier, so people could use their custom builds in their workflow without waiting for a release.

And we have quite a good progress, btw. We are getting more and more people proposing MRs on GitLib. There is a lot of new contributors proposing some nice small changes.

I've seen all these experiments several times on different projects. I know the results.

Can Krita be excluded from KDE translations and continue experimentation by itself? We already have Kaidan on Weblate so this case will not be the first.

Read every point here and both sides have valid arguments. Want to clarify some points :

1. No, the point is not to force Weblate on everyone (the sentence I made was regarding how to avoid merge conflict, in which case a one system would help)
2. Yes, the reload time between strings is a problem in Weblate, Zen mode is better in that regard, but doesn't have all the features as the main utility
3. Yes, the GNOME system has problems, it simplifies the translator entry, but is difficult for reviewers (who has other jobs) and might even discourages new contributors. We can do better
4. Yes, for veteran translators, the current system works good and teams with active translators are at the top of the list in translation stats. If a new contributor approaches them, I'm sure that the team will help them to get started with SVN, Lokalize because the team will be active to contact to. No, we don't need to disrupt this good workflow
5. No, for small teams or teams where the maintainer is inactive, it is indeed difficult for someone or a group (say students of the same college, a translator sprint) to start out
6. Yes, using an online tool may decrease translation quality, but this can be reduced by enabling Translation Suggestion Voting. It also helps busy reviewers to easily review
7. Yes, having many components in Weblate is confusing. I suggest to include only major apps like Dolphin, Desktop Workspace related components. This decision should be made by the translation teams who need the online system

So, the solution I propose is :

A Single KDE Hosted Weblate for language teams that need it

Q: Who will most likely need it ?
A: Small teams, teams that maintainer gets busy later and ghost. These teams often bounce up after a while, but those who come will go through the same burden the old maintainer started with. A simple online tooling will help someone who's new and want to change some few strings. Perhaps that contributor will keep on. If that contributor feel to step up, they can go to the next step of offline Lokalize.

Q: Merge conflicts ?
A: Maintainer of teams that move to this online tool should resolve it. They're free to also use SVN together (conflicts can be avoided with a locking mechanism as @dkazakov suggested.

Q: Would the ENTIRE PO files be in Weblate ?
A: No, because too many files in Weblate will be super confusing for beginners. IMO, Weblate is only good for small number of components. The individual language teams can decide which they need to include. The translators can of course request the team maintainer or kde-i18n to include a component in Weblate in their language.

This can be done successfully by a separate git repo specially for Weblate as done here. From this intermediary git repo, conflicts (if there are any) can be safely resolved between weblate and upstream and synced together.

Q: How to maintain quality ?
A: One way is enable Translation Suggestion Voting

Q: Maintenance ?
A: There will be a special repo for Weblate, files chosen to be in Weblate will be here, and any maintainer irrespective of language team can maintain the syncing (The steps to do so are here). This system will be easier if that language team decide to move to Weblate and not use SVN [they can still use it with locking mechanism in Weblate]

In T11070#238091, @subins2000 wrote:

Q: Who will most likely need it ?
A: Small teams, teams that maintainer gets busy later and leaves soon. These teams often bounce up after a while, but those who comes will go through the same burden the old maintainer started with. A simple online tooling will help someone who's new and want to change some few strings. Perhaps that contributor will keep on.

H-m-m...

1. What outcome do you expect for small teams? More translators (to become the large translation teams)? More translations (please explain how it can be implemented without strong coordination)?
2. Who will approve new translators when there will be no active coordinator/reviewer?
3. Who will vote if the number of translators is small?
4. What about the consistency of translations?

Thanks in advance for your answers.

Just a quick note: we can't and won't ever enable any automatic acceptance of strings.
It would like allowing automatic merging of code from people without commit permissions, and this is not allowed.
The final decision about the validity of a string must be done by someone with commit access.

What outcome do you expect for small teams? More translators (to become the large translation teams)? More translations (please explain how it can be implemented without strong coordination)?

From my experience of being in the small Malayalam team, it was difficult to restart a team that was inactive. As the sole maintainer, it was difficult to guide interested translators to send files, keep track of who's doing what, receiving them over Telegram, merge, upload back etc. and the translators didn't like it. Some did, they liked Lokalize for being speedy to do the translation. But, as the maintainer, reviewing was difficult.

With our move to Weblate, contributors increased, people who liked Lokalize could still use it and reviewing can be done by multiple people now easily without having SVN commit access. Suggestion Voting or review permission to some people. The quality checks in Weblate also helped in reviewal.

Who will approve new translators when there will be no active coordinator/reviewer?

With suggestions voting, If a suggestion gets 3 votes, it will get accepted. If the language team maintainer (with commit access) is busy, someone else can still review it. If it gains enough votes, and gets accepted, it will get merged upstream by a different maintainer of a different language team cause this single KDE Hosted Weblate instance is synced upstream by any of the maintainers of different language teams. Only one person need to do it in a week or so [can this be automated ? it can, if there are no conflicts in the intermediary git repo, perhaps a warning email when script finds a conflict during a sync procedure)

Who will vote if the number of translators is small?

A minimum requirement of X people is always needed. What this system does is reduce burden on small language team maintainers or someone new to bring in some new people to do things.

What about the consistency of translations?

There's glossary and similar strings across all components in Weblate to help. Maybe as an extra step, user who signups on Weblate won't be able to directly translate, will have to ask someone to get their account approved to add suggestions [We do this in Malayalam team].

Just a quick note: we can't and won't ever enable any automatic acceptance of strings.

Acceptance by people voting on a string suggestion would be alright though, right ? Or acceptal by reviewers ?

In T11070#238095, @subins2000 wrote:

Just a quick note: we can't and won't ever enable any automatic acceptance of strings.

Acceptance by people voting on a string suggestion would be alright though, right ? Or acceptal by reviewers ?

We can only implement acceptance from people with commit access (i.e. people who can push to KDE repositories).

If you change "voting" with "comment on a merge request", "translator" with "developer" and "string suggestion" with "merge request", you will see how acceptance from non-registered people can't be used.

In T11070#238091, @subins2000 wrote:

1. Yes, the GNOME system has problems, it simplifies the translator entry, but is difficult for reviewers (who has other jobs) and might even discourages new contributors. We can do better

Note that Damned Lies (the system used by GNOME) is not the same thing as Weblate. Dl does not do online translations, but rather teams, file assignments, statistics per release/branch, and even uploading of files by translators to the team coordinators.

Note that "release" in DL parlance is for example "Plasma", or "Frameworks", or "release service" in our case.

1. No, for small teams or teams where the maintainer is inactive, it is indeed difficult for someone or a group (say students of the same college, a translator sprint) to start out

With an inactive team no tool will help you, because there's noone to review your work, help you with terminology, and so on.

So, the solution I propose is :

A Single KDE Hosted Weblate for language teams that need it

Q: Who will most likely need it ?
A: Small teams, teams that maintainer gets busy later and ghost. These teams often bounce up after a while, but those who come will go through the same burden the old maintainer started with. A simple online tooling will help someone who's new and want to change some few strings. Perhaps that contributor will keep on. If that contributor feel to step up, they can go to the next step of offline Lokalize.

How do you define "small team" exactly?

Q: Would the ENTIRE PO files be in Weblate ?
A: No, because too many files in Weblate will be super confusing for beginners. IMO, Weblate is only good for small number of components. The individual language teams can decide which they need to include. The translators can of course request the team maintainer or kde-i18n to include a component in Weblate in their language.

Erk, no, I disagree. Either you provide the complete set of files, or the situation you describe will be confusing.

This can be done successfully by a separate git repo specially for Weblate as done here. From this intermediary git repo, conflicts (if there are any) can be safely resolved between weblate and upstream and synced together.

No, no, no. No separate repositories please. There are enough repositories upstream, adding more will create a maintenance burder we have no manpower to support. If a Weblate for a language is setup, then it ought to push directly to the svn/git repository of the language.

Q: How to maintain quality ?
A: One way is enable Translation Suggestion Voting

With suggestions voting, If a suggestion gets 3 votes, it will get accepted. If the language team maintainer (with commit access) is busy, someone else can still review it. If it gains enough votes, and gets accepted, it will get merged upstream by a different maintainer of a different language team cause this single KDE Hosted Weblate instance is synced upstream by any of the maintainers of different language teams. Only one person need to do it in a week or so [can this be automated ? it can, if there are no conflicts in the intermediary git repo, perhaps a warning email when script finds a conflict during a sync procedure)

Definitely not. If a translator writes crap, other people vote it and it gets automatically approved, where is the quality? Please,

• no automatic approval of suggestions
• suggestions can be enabled even by anonymous
• only language coordinators (and maybe translators for their files, but Weblate has no concept of "my file") can approve comments

Even worse is the suggestion about letting other translators/coordinators of a language approve translations of a different language. Why should I, Italian translator, approve a string in e.g. Malayam, just because a translator asks me because of the disappearance of their coordinator? It makes zero sense.

Q: Maintenance ?
A: There will be a special repo for Weblate, files chosen to be in Weblate will be here, and any maintainer irrespective of language team can maintain the syncing (The steps to do so are here). This system will be easier if that language team decide to move to Weblate and not use SVN [they can still use it with locking mechanism in Weblate]

Again, no.

Let me be clear: adding Weblate as long as translations are in SVN is a totally bad idea, becase

1. SVN
2. it will require re-import and basically re-setup from scratch with the switch to Git, doubling the efforts needed for Weblate.

That's why T13514: Migrate KDE translations to Git is priority #1: the sooner we migrate to git, the better.

In T11070#238095, @subins2000 wrote:

From my experience of being in the small Malayalam team, it was difficult to restart a team that was inactive. As the sole maintainer, it was difficult to guide interested translators to send files, keep track of who's doing what, receiving them over Telegram, merge, upload back etc. and the translators didn't like it. Some did, they liked Lokalize for being speedy to do the translation.

Strictly speaking, for this there is no need for Weblate, but DL can do that.

But, as the maintainer, reviewing was difficult.

There is nothing that saves you from reading and checking 1000 strings if a translator sends you 1000 newly translated strings to review.

Sure, some tools can help you with diff between old and new strings, consistency/spell/etc checks and so on, but in the end you will need a lot of patience to go through translations, and the translators will need patience to wait for your review. IME it is the "human part" of a review what takes the most time.

Hello here, as one of the people interested in this issue I was following the task for a while and here I am to throw my 5 cents:

In T11070#230899, @frederico wrote:

That said, there is some FUD here. Please note that "translators don't answer on the mailing list" is not going to be solved by any specific tool.

The point was that there's barely any people involved and thus no activity as evidenced by the mailing list, bug tracker and website.

And how a web translation tool would help? I totally agree with @ltoscano . If they don't interact in mailing list, why would they interact in another tool? If the problem is that no one uses mailing lists anymore (an argument that I disagree, but it's been used a lot), then open other communication channels. Here in Brazil we created a group in Telegram, some time ago to try to solve it. And, surprise! It didn't solve it completely. We have 56 people on our Telegram group, but only the same 5 or 6 members interact and effectively work on translations.

You don't solve social problems with tooling.

Whether it's a social problem or not, it was caused by the tooling. The high barrier of entry made it so that only few people joined and even fewer remained.

As I answered above, the use of a more popular communication tool didn't solve our problem. Because people choose to collaborate or not.

You seems to be missing a use-case here.
You are assuming that if a translation team for a language have no active people then nothing can be done.
But actually, anyone with commit access can approve translations.
There are people like me, not translators but developers with write access who are not native English speakers, so they can contribute by translating in their mother tongue.
Personally speaking, I can translate stuff in Russian (native level) and in Italian (almost native level), except that the current workflow is too much a hastle for me.
It's not like I can't do it if I need it, but the point is, I don't really need it.
If I can just login and begin translating like I do in other projects which have a web translation tool I would do it with pleasure (Italian completeness is quite good, but Russian, sadly, is lacking).
Even if there is no one to approve my translations I can do it myself.
But looking at the current contributing workflow - I'll pass. I don't have that much of free time to study things I am not interested in.
The barrier is not too high to pass, is just so high that people lose their motivation.
(And I don't want to study SVN or Cobol in 2020).

In T11070#237992, @yurchor wrote:

Speaking anecdotally, I'd contributed through such a system fixing at least two small mistakes I came across and probably also translating some outstanding Strings (rating from what I did in the past on other projects). Also I think there are several more anecdotes like this around in the KDE community. Only they are hard to use as scientific justification.

O-o-h, yes! Can we lower the barriers for the code to have more anecdotes about KDE software?

Online translation tools can make access to translation easier (not even in every case) but they definitely make the translation process deadly longer. Everything comes with its price.

I would doubt that they make the translation process deadly longer in every case. Maybe in some corner cases that get more relevant for power users. That is why I think it is pretty important to be able to maintain their workflow, at least in a way there won't be substantial or maybe noticeable disadvantages.

They can have some Hawthorne effect (can be seen for UserBase and WikiToLearn) for the short runs but they stagnate in the long run because of their indisposable issues.

https://en.wikipedia.org/wiki/Hawthorne_effect

So if you just want to have more items in the team lists (most of them with ~0 % of contribution) then go on with the online tools. But be aware that the translation coverage and the quality will go down then. Dixi.

You and someone other seems to be making a mistake by equalizing our code contribution barrier and our translation contribution barrier.
They are not the same.
A developer unable to use git and collaboration platforms like Phabricator and Gitlab is not a good developer.
Devs can pass the code contribution barrier by using their developer skills.
But for a translator the usage of SVN (or other VCS) and the ability to handle handle PO files is not a part of their area of competence.
Sure, they can learn it, if they need it.
But as formerly said, they don't need it.
Because this is a purely volunteering part (unlike for devs who are getting experience and contributing to their CV).
The fundamental difference between the code barrier and the i18n barrier is that the skills necessary to overcome said barrier are inside the area of competence for devs but outside for translators,
so, if a dev can't handle it then he is not good enough to be allowed to contribute, but if a translator can't overcome the current barrier this does not mean he is not good enough.

(not "to translate", not "to be effective", just "to contribute")

Illuminate me please on how could someone contribute to a translation without actually translating.

In T11070#238016, @pshinjo wrote:

In T11070#238001, @clel wrote:

In T11070#237992, @yurchor wrote:

No. And you know what I mean. Typing, for sure, is as fast as for offline tools. But switching between translations is slow. And it eats plenty of time if you typing fast. It takes ~3-4 seconds just to switch between translations.

I just had a test with the dev tools in Firefox. It displayed me 1.45 s for loading the page with the next translation after submitting the previous one. I admit that this is noticeable, but accapteable and not really slowing down the translation process much. I tested on https://hosted.weblate.org/translate/osmand/ios/de/. Let me know if you have a different site where the performance is worse. Also, if it takes really 3-4 seconds for you, it might have to do with your setup. I don't say that to blame you, but to try to understand. That amount is clearly a bad user experience that one should try to avoid.

When I am typing Korean my typing speed is about 500-600 keystrokes per minute. I consider this as slightly above from average. 1.45 s is enough to complete one or two word translation on average. This kind of delay, when cumulated, seriously degrades my productivity.

As in coding, in translation thinking consumes way more time than typing.

Ah, yes, an "occasional contribution" does not mean a "two strings contribution".
It means "not a regular contribution".
It can contain 2 string as well as 200.

In T11070#238099, @zhigalin wrote:

In T11070#237992, @yurchor wrote:

Speaking anecdotally, I'd contributed through such a system fixing at least two small mistakes I came across and probably also translating some outstanding Strings (rating from what I did in the past on other projects). Also I think there are several more anecdotes like this around in the KDE community. Only they are hard to use as scientific justification.

O-o-h, yes! Can we lower the barriers for the code to have more anecdotes about KDE software?

Online translation tools can make access to translation easier (not even in every case) but they definitely make the translation process deadly longer. Everything comes with its price.

I would doubt that they make the translation process deadly longer in every case. Maybe in some corner cases that get more relevant for power users. That is why I think it is pretty important to be able to maintain their workflow, at least in a way there won't be substantial or maybe noticeable disadvantages.

They can have some Hawthorne effect (can be seen for UserBase and WikiToLearn) for the short runs but they stagnate in the long run because of their indisposable issues.

https://en.wikipedia.org/wiki/Hawthorne_effect

So if you just want to have more items in the team lists (most of them with ~0 % of contribution) then go on with the online tools. But be aware that the translation coverage and the quality will go down then. Dixi.

You and someone other seems to be making a mistake by equalizing our code contribution barrier and our translation contribution barrier.
They are not the same.
A developer unable to use git and collaboration platforms like Phabricator and Gitlab is not a good developer.
Devs can pass the code contribution barrier by using their developer skills.
But for a translator the usage of SVN (or other VCS) and the ability to handle handle PO files is not a part of their area of competence.
Sure, they can learn it, if they need it.
But as formerly said, they don't need it.
Because this is a purely volunteering part (unlike for devs who are getting experience and contributing to their CV).
The fundamental difference between the code barrier and the i18n barrier is that the skills necessary to overcome said barrier are inside the area of competence for devs but outside for translators,
so, if a dev can't handle it then he is not good enough to be allowed to contribute, but if a translator can't overcome the current barrier this does not mean he is not good enough.

Sure? Fundamental difference? Why did you compare them just below.

I think there is some infantile way of think that we see here: "I do not want to send translation in the Russian ML or to Russian coordinator (that's the requirement). I do not even want to know the team policies. I want to do it my way! The problems for other teams are acceptable to me!" That's how it sounds now.

(not "to translate", not "to be effective", just "to contribute")

Illuminate me please on how could someone contribute to a translation without actually translating.

Simple. You want to change "foo" with "buzz" without reviewing. You go to Launchpad, register (there is no barrier there), change "foo" with "buzz", and vanish. You are a valuable contributor now. Other people might not want to call you "translator". In fact, when it comes to Russian, you can easily imagine some other term.

As in coding, in translation thinking consumes way more time than typing.

Of course. Why not allowing anonymous pushes?

In T11070#238067, @dkazakov wrote:

In T11070#237887, @slavekb wrote:

Weblate allows to download the MO file directly from the web interface. The user does not need any other tool to get the MO file.
Likewise, Weblate allows to upload a PO file if the user wants to use some offline translation tool.

Hi, @slavekb!

Perhaps you know, does Weblate supports some kind of "locking" a translation file by the maintainer of the project? Such locking would really help people like @yurchor to do bulk-translations offline.

I mean, we could make a policy that "a translator can ask to lock a specific file for not more than N days(?)" to do the translations offline safely and push them into SVN/Git. And the rest of the time the files would be available for translations by other people through web-interface.

Not slavekb, but am someone who uses Weblate. Yes, you can lock translations (or entire components for freezes right before a release). See: https://docs.weblate.org/en/weblate-3.0.1/admin/translating.html#locking

In T11070#238101, @yurchor wrote:

I think there is some infantile way of think that we see here: "I do not want to send translation in the Russian ML or to Russian coordinator (that's the requirement). I do not even want to know the team policies. I want to do it my way! The problems for other teams are acceptable to me!" That's how it sounds now.

Oh, wow.
I didn't wanted to seem rude to you so I didn't wrote anything about it but if you are speaking like this I might as well go on:
You in all the messages you wrote so far, including the one I am replying to, displayed exceptional infantile clinginess to the current system to the point you had to assign words a different meaning unique to your understanding, and do cheap manipulations like selective blindness and putting your own words into the mouth of your opponents.
Exactly as you did in the part I quoted above.
First, when I spoke of approving my translations by myself I was very clearly referring to the case when the team is dead and there is no coordinator like in the Czech case you were discussing about.
Second, the "team policies" and "approval by the coordinator" have nothing to do with the current system and can be done in weblate or other online systems.

In T11070#238099, @zhigalin wrote:

In T11070#237992, @yurchor wrote:

Speaking anecdotally, I'd contributed through such a system fixing at least two small mistakes I came across and probably also translating some outstanding Strings (rating from what I did in the past on other projects). Also I think there are several more anecdotes like this around in the KDE community. Only they are hard to use as scientific justification.

O-o-h, yes! Can we lower the barriers for the code to have more anecdotes about KDE software?

Online translation tools can make access to translation easier (not even in every case) but they definitely make the translation process deadly longer. Everything comes with its price.

I would doubt that they make the translation process deadly longer in every case. Maybe in some corner cases that get more relevant for power users. That is why I think it is pretty important to be able to maintain their workflow, at least in a way there won't be substantial or maybe noticeable disadvantages.

They can have some Hawthorne effect (can be seen for UserBase and WikiToLearn) for the short runs but they stagnate in the long run because of their indisposable issues.

https://en.wikipedia.org/wiki/Hawthorne_effect

So if you just want to have more items in the team lists (most of them with ~0 % of contribution) then go on with the online tools. But be aware that the translation coverage and the quality will go down then. Dixi.

You and someone other seems to be making a mistake by equalizing our code contribution barrier and our translation contribution barrier.
They are not the same.
A developer unable to use git and collaboration platforms like Phabricator and Gitlab is not a good developer.
Devs can pass the code contribution barrier by using their developer skills.
But for a translator the usage of SVN (or other VCS) and the ability to handle handle PO files is not a part of their area of competence.
Sure, they can learn it, if they need it.
But as formerly said, they don't need it.
Because this is a purely volunteering part (unlike for devs who are getting experience and contributing to their CV).
The fundamental difference between the code barrier and the i18n barrier is that the skills necessary to overcome said barrier are inside the area of competence for devs but outside for translators,
so, if a dev can't handle it then he is not good enough to be allowed to contribute, but if a translator can't overcome the current barrier this does not mean he is not good enough.

Sure? Fundamental difference? Why did you compare them just below.

Sure.
Now, it should be common sense that if different things have some common aspect that aspect could be compared.

(not "to translate", not "to be effective", just "to contribute")

Illuminate me please on how could someone contribute to a translation without actually translating.

Simple. You want to change "foo" with "buzz" without reviewing. You go to Launchpad, register (there is no barrier there), change "foo" with "buzz", and vanish. You are a valuable contributor now. Other people might not want to call you "translator". In fact, when it comes to Russian, you can easily imagine some other term.

Other people might not want call you "contributor" either so that's not a valid point.

As in coding, in translation thinking consumes way more time than typing.

Of course. Why not allowing anonymous pushes?

You sure are capable to indicate when exactly I proposed allowing anonymous pushes or this is an another example of your cheap tricks?

Hi, @yurchor!

Could you please explain your total opposition to having Weblate as another source of translations? You are constantly saying that "the performance will be much lower", but noone in this thread says about forbidding direct pushes into svn/gitlab repository with translations. More than that, @sanecito has just confirmed that one can lock the file in Weblate and work with it in his/her own way. Why can't you just lock the file in Weblate and go translating it in Lokalize?

With such workflow Weblate will just work as a "translations coordinator", which distributes jobs among people. Where do I get it wrong?

In T11070#238104, @dkazakov wrote:

Hi, @yurchor!

Could you please explain your total opposition to having Weblate as another source of translations?

Because I've used it for several years.

I think that we do not need "another source of translations". With Weblate/Transifex/whatever you will soon find that the team coordinator is gone, or do not want to approve your translations, or you do not want to approve somebody's translations. The problem was not with tools (again). One more tool just makes the current life harder. Just look at this thread. All the problems can be solved with better team management.

You are constantly saying that "the performance will be much lower", but noone in this thread says about forbidding direct pushes into svn/gitlab repository with translations.

No. Quite opposite. They say that it is hard/should be cut off/left for the "power" users.

More than that, @sanecito has just confirmed that one can lock the file in Weblate and work with it in his/her own way. Why can't you just lock the file in Weblate and go translating it in Lokalize?

Why should I lock it first?

Just an example. Today we have ~40 new strings in ~10 catalogs. I should go and find one of ~1000 KDE catalogs and lock it. ~5 mins of my time gone for nothing. I guess that overall probability that nobody wants to translate something is about 99.99%.

Another example. XX locked the catalog and gone. Who will unlock it for an abandoned language?

These locks are of no good for anybody except scripty or developers.

With such workflow Weblate will just work as a "translations coordinator", which distributes jobs among people. Where do I get it wrong?

Everywhere. First, most of the complaints are from people who do not want the distribution of jobs. They just want to change something and vanish.

Second, we are speaking about teams with 2-3 active translators (most KDE teams). "Coordination" in such teams is rather simplistic. You just translate, translate, and translate. Once in several months comes a guy/girl with a new translation which you have to review. Once a year, you have a correct bug report about a mistake in translation.

Almost all Weblate features are unusable in such a workflow. You just want to get rid of any coordination and go Launchpad/Rosetta way (or Transifex way like it is for MATE or Deepin), to be honest.

Hello all.
I have been watching this for a while now, and I have to admit it: there are good points from both sides here.

My take is this story:

Let's imagine a semi-inactive language team X. After a period of time, a new translator appears! Great.
They start translating using the great nice-looking web interface, and starts sharing it with friends and social media.
Next day, 20 new translators appear! Great. They work randomly on what they feel they want to contribute for, and also share that with thier friends.
Several days later, 40 new translator appear! Now all of the 60 + 1 translators start translting and voting for each other, and things are going just fine.

After a period of time, a new user moves to KDE, and finds the chess game. Time to play chesss! While playing, he reads "Checkmark". Hmmm... whats that? Did they mean "Check"?
Opens a bug, a developer seeks the language team maintainer (that first translator). The translators investigate and find that 40+ people approved/voted for "Checkmark" as a translation of "Check" [mate] in a chess game. He reverts that, and a war starts.

Where is the error? Sharing what you love? People voting on strings even though we set the criteria so high (10)?

This is how I see it: By using Weblate-alike interafce, we set the barrier too low that anyone (those 60 weren't all translators, but people who understand both English and X language) can contribute without any mentoring/checking/guidance etc etc.

You might say that well, not a big deal, we can revert any bad translation... and hit the wall when seeing thousands of translations done either literally, or by a machine. And repeat this whenever many new "translators" appear.

Having web interface is good, but it should not make the reviewing work harder, or allow anyone to translate anything and add load to the system.
We can for example have that each new account can translate up to X strings (without us telling them, so the translator don't take any action based on that criteria). If all things went good (after reviewing), he can then translated up to X+Y strings, etc etc till the maintainer make sure that they are following whatever policies/standards/guides/etc, and the contributer can be approved as a translator.
EDIT: or for example maintainers/approved translators can set specific files as "Good first translation" that will appear to newcomers and they can work on it.

And regarding the load time, Mozilla's Pontoon translation page is a SPA, so you shouldn't get any wait time between strings, but unfortunately you have to wait till the string is posted to the server, checked for errors (if any), sent back, fix the error (if any), send again, move to the next string.

If anything happened and the online web interface didn't get accepted, I still say a DL like interface is a must to manage and lower the barrier a little bit so that translators can actually translate. (And still, we've seen someone replying to our "there are grammer/spelling mistakes issues in the file, listed below" in Gnome with "i DonT caRE about langUage &speling mistaks". The translation got reverted to what it was and stayed as is for 2-3 years till someone worked on it)

TL;DR

• A better online tool to manage translations/translators/comments/locking/reviewing is needed. Dammed Lies lacks a proper way to review translations, as it just provides a simple file differ. An enhancment can be adding a translations differ along with that file differ (so we still are able to check if metadata is the same/comments are still there/etc)
• Online translation tools shouldn't lower the barrier too much that anyone can come and translate. There should be limits to firstcomers and management of the whole translation process.

My vision:
Step 1: Dammed Lies interface for KDE.
Step 2: Enhance and polish Lokalize, making it extendable to accept any file format and custom projects: think opening YML in Lokalize, or translating collaboratory using remote resources with APIs. This allows having the exact same offline experiance and lowering the barrier as "Download the app, enter this URL, login, start translating what you want (with the limits mentioned above)"
At the end we will reach to a better ecosystem, , suits everybody and a better Lokalize, used by everybody, talks to different websites using APIs, have the ability to work offline, etc etc

Thanks.

Safa,
Arabic team maintainer

In T11070#238103, @zhigalin wrote:

In T11070#238101, @yurchor wrote:

I think there is some infantile way of think that we see here: "I do not want to send translation in the Russian ML or to Russian coordinator (that's the requirement). I do not even want to know the team policies. I want to do it my way! The problems for other teams are acceptable to me!" That's how it sounds now.

Oh, wow.
I didn't wanted to seem rude to you so I didn't wrote anything about it but if you are speaking like this I might as well go on:
You in all the messages you wrote so far, including the one I am replying to, displayed exceptional infantile clinginess to the current system to the point you had to assign words a different meaning unique to your understanding, and do cheap manipulations like selective blindness and putting your own words into the mouth of your opponents.

Oh, yes. The current system is awful (no doubts) because it uses Subversion that you do not want to learn.

Exactly as you did in the part I quoted above.
First, when I spoke of approving my translations by myself I was very clearly referring to the case when the team is dead and there is no coordinator like in the Czech case you were discussing about.

Get a coordinator. There is no other way.

Second, the "team policies" and "approval by the coordinator" have nothing to do with the current system and can be done in weblate or other online systems.

So there will be no difference for the team management and sooner or later we will be in the same situation again.

In T11070#238099, @zhigalin wrote:

In T11070#237992, @yurchor wrote:

Speaking anecdotally, I'd contributed through such a system fixing at least two small mistakes I came across and probably also translating some outstanding Strings (rating from what I did in the past on other projects). Also I think there are several more anecdotes like this around in the KDE community. Only they are hard to use as scientific justification.

O-o-h, yes! Can we lower the barriers for the code to have more anecdotes about KDE software?

Online translation tools can make access to translation easier (not even in every case) but they definitely make the translation process deadly longer. Everything comes with its price.

I would doubt that they make the translation process deadly longer in every case. Maybe in some corner cases that get more relevant for power users. That is why I think it is pretty important to be able to maintain their workflow, at least in a way there won't be substantial or maybe noticeable disadvantages.

They can have some Hawthorne effect (can be seen for UserBase and WikiToLearn) for the short runs but they stagnate in the long run because of their indisposable issues.

https://en.wikipedia.org/wiki/Hawthorne_effect

So if you just want to have more items in the team lists (most of them with ~0 % of contribution) then go on with the online tools. But be aware that the translation coverage and the quality will go down then. Dixi.

You and someone other seems to be making a mistake by equalizing our code contribution barrier and our translation contribution barrier.
They are not the same.
A developer unable to use git and collaboration platforms like Phabricator and Gitlab is not a good developer.
Devs can pass the code contribution barrier by using their developer skills.
But for a translator the usage of SVN (or other VCS) and the ability to handle handle PO files is not a part of their area of competence.
Sure, they can learn it, if they need it.
But as formerly said, they don't need it.
Because this is a purely volunteering part (unlike for devs who are getting experience and contributing to their CV).
The fundamental difference between the code barrier and the i18n barrier is that the skills necessary to overcome said barrier are inside the area of competence for devs but outside for translators,
so, if a dev can't handle it then he is not good enough to be allowed to contribute, but if a translator can't overcome the current barrier this does not mean he is not good enough.

Sure? Fundamental difference? Why did you compare them just below.

Sure.
Now, it should be common sense that if different things have some common aspect that aspect could be compared.

And you will decide which aspect it is. That's very convenient.

(not "to translate", not "to be effective", just "to contribute")

Illuminate me please on how could someone contribute to a translation without actually translating.

Simple. You want to change "foo" with "buzz" without reviewing. You go to Launchpad, register (there is no barrier there), change "foo" with "buzz", and vanish. You are a valuable contributor now. Other people might not want to call you "translator". In fact, when it comes to Russian, you can easily imagine some other term.

Other people might not want call you "contributor" either so that's not a valid point.

As in coding, in translation thinking consumes way more time than typing.

Of course. Why not allowing anonymous pushes?

You sure are capable to indicate when exactly I proposed allowing anonymous pushes or this is an another example of your cheap tricks?

No. You have proposed exactly this. Anybody registered within Weblate can push to "low the barriers".

In T11070#238106, @safaalfulaij wrote:

Hello all.
I have been watching this for a while now, and I have to admit it: there are good points from both sides here.

My take is this story:

Let's imagine a semi-inactive language team X. After a period of time, a new translator appears! Great.
They start translating using the great nice-looking web interface, and starts sharing it with friends and social media.
Next day, 20 new translators appear! Great. They work randomly on what they feel they want to contribute for, and also share that with thier friends.
Several days later, 40 new translator appear! Now all of the 60 + 1 translators start translting and voting for each other, and things are going just fine.

After a period of time, a new user moves to KDE, and finds the chess game. Time to play chesss! While playing, he reads "Checkmark". Hmmm... whats that? Did they mean "Check"?
Opens a bug, a developer seeks the language team maintainer (that first translator). The translators investigate and find that 40+ people approved/voted for "Checkmark" as a translation of "Check" [mate] in a chess game. He reverts that, and a war starts.

Where is the error? Sharing what you love? People voting on strings even though we set the criteria so high (10)?

This is how I see it: By using Weblate-alike interafce, we set the barrier too low that anyone (those 60 weren't all translators, but people who understand both English and X language) can contribute without any mentoring/checking/guidance etc etc.

The automated push when a certain number of people without the commit access approve the translation was proposed here by just one person and immediately rejected, so this is not a case here at all

In T11070#238099, @zhigalin wrote:

You and someone other seems to be making a mistake by equalizing our code contribution barrier and our translation contribution barrier.
They are not the same.
A developer unable to use git and collaboration platforms like Phabricator and Gitlab is not a good developer.
Devs can pass the code contribution barrier by using their developer skills.
But for a translator the usage of SVN (or other VCS) and the ability to handle handle PO files is not a part of their area of competence.
Sure, they can learn it, if they need it.
But as formerly said, they don't need it.
Because this is a purely volunteering part (unlike for devs who are getting experience and contributing to their CV).
The fundamental difference between the code barrier and the i18n barrier is that the skills necessary to overcome said barrier are inside the area of competence for devs but outside for translators,
so, if a dev can't handle it then he is not good enough to be allowed to contribute, but if a translator can't overcome the current barrier this does not mean he is not good enough.

I generally agree, new translators might want to just get work done as swiftly as possible with their existing skillset instead of acquiring new unrelated skills, even if short and easily manageable ones.

But as mentioned in T13514#237624 , SVN currently requires minimal interaction and can mostly be avoided by translators by using kdesvn or dolphin-plugins, which are both awesome. Additionally, sending commits through SVN isn't particularly difficult and can be done by copy-pasting.

I see a transition to Weblate as slightly advantageous from the (hypothetical) perspective of a complete newbie who only studied languages and have experience translating in that the current system requires:

• (Possible) To find a chat group for translation on Telegram/Matrix; if not exists,
• (Possible) Send an email to translation team mailing list; if inactive,
• (Possible) Send an email to main localization mailing list or i18n IRC and request to become coordinator; if more contributors show up,
• (Possible) Send commits yourself after learning how to do it
• Learning how to translate with Lokalize
• Learning the translation team's guidelines and localization infrastructure
• Sending translation to coordinator
• (If approved translator) Learn to commit with SVN or kdesvn

Whereas with Weblate we have:

• (Ideal) Contacting the translation team; if inactive/inexistent,
• (Possible) Request to become coordinator straight away at main IRC or mailing list; if more contributors show up,
• (Possible) Review their suggestions, no need to send commits yourself, just approving translations and it gets automatically synced
• Requesting to join Weblate group
• Learning how to translate with Weblate
• Learning the translation team's guidelines

Not quite a drastic difference, but it removes a few potential issues.

In T11070#238054, @pshinjo wrote:

In T11070#238043, @clel wrote:

You might have some good points here. I understand that for an active team there is not much need for such a system. However, almost no language has all Strings translated already when looking at: https://l10n.kde.org/stats/gui/stable-kf5/team/. Quite the opposite if you look how much untranslated Strings there are for many languages. So apparently almost no team is active enough to reach a completeness level of 100 %. Thus I assume they lack the time and manpower.

Just to say, GNOME's l10n system is called "Damned Lies" (https://en.wikipedia.org/wiki/Lies,_damned_lies,_and_statistics). Yes, only a small number of teams reach 100% in the statistics. I personally do not aim 100% there because:

• websites-kde-org/www_www.po contains ALL release notes dating back from KDE 4.x era. Even if I translate 100% of them who will practically read all of them? Also I don't direct other translators to touch them either.
• Big specialized applications: I would name Krita, KStars, GCompris, RKWard as examples. They require specialized domain knowledge for usage (and correct translation). For some languages, even finding a user who is using the application in English (and eventually willing for a translation) could be hard enough.

Also leaving out those not really relevant stuff, I think there is still alot of untranslated strings currently. I might read the statistics wrong, though. The second point of having specialized applications imho can be seen as an argument to lower the contribution barriers, so people familiar with those can help translate the missing strings.

The problem was not with tools (again). One more tool just makes the current life harder. Just look at this thread. All the problems can be solved with better team management.

No it can't. While technically there is a transfer process happening from SVN to Git, the problem of 'localizers should know SVN' is not being addressed. It's great that you and others put in the time to learn SVN, but telling linguists that no, they must first learn SVN to contribute string suggestions is utterly ridiculous and offputting. It's like telling people they can't make a fire with a lighter and instead they have to learn to use a wood spindle simply because you spent time learning how to use a wood spindle. There are better tools in the world; KDE does not benefit by being stuck in the past using wood spindles over lighters. If you read the actual original ticket, the issue is not that coordinators have to sign off on translations, but rather the process to get, write, and submit suggestions is absolutely painful.

People are getting incredibly stuck up on approval being 'have X' votes. It doesn't have to be this way if this is an issue for people. You can have the current KDE process in Weblate: someone submits a suggestion via Weblate, and then a team coordinator signs off on it/'submits' it. Coordinators can easily find these by either setting up notifications when a new suggestion is made for component X with language Y, or just select strings w/ language Y suggestions from the dashboard.

On a separate note unrelated to the tool, it's worth noting that at some point you have to make someone a team coordinator if there are no active ones for the language. Team coordinators of the past weren't magically given commit access, KDE granted it to them through some process or lack there of. Whatever process KDE used to establish the first Italian, Russian, etc team coordinators is the process that you can use going forward when dealing w/ inactive coordinators or the lack there of.

In T11070#238107, @yurchor wrote:

In T11070#238103, @zhigalin wrote:

In T11070#238101, @yurchor wrote:

I think there is some infantile way of think that we see here: "I do not want to send translation in the Russian ML or to Russian coordinator (that's the requirement). I do not even want to know the team policies. I want to do it my way! The problems for other teams are acceptable to me!" That's how it sounds now.

Oh, wow.
I didn't wanted to seem rude to you so I didn't wrote anything about it but if you are speaking like this I might as well go on:
You in all the messages you wrote so far, including the one I am replying to, displayed exceptional infantile clinginess to the current system to the point you had to assign words a different meaning unique to your understanding, and do cheap manipulations like selective blindness and putting your own words into the mouth of your opponents.

Oh, yes. The current system is awful (no doubts) because it uses Subversion that you do not want to learn.

First, using SVN in 2020 is like using Cobol.
The only possible motivation you would be willing to learn Cobol in 2020 is because you're doing it for a bank which pays you a ton of money.
Second, the problem is not the VCS used. If it would be git the issue would be pretty much the same.

Exactly as you did in the part I quoted above.
First, when I spoke of approving my translations by myself I was very clearly referring to the case when the team is dead and there is no coordinator like in the Czech case you were discussing about.

Get a coordinator. There is no other way.

Illuminate me, where I should get him?
Should I hire someone?
If you are willing to pay his salary then count me in.

Second, the "team policies" and "approval by the coordinator" have nothing to do with the current system and can be done in weblate or other online systems.

So there will be no difference for the team management and sooner or later we will be in the same situation again.

If you weren't using your selective blindness here you would noticed that in case of Malayalam team using weblate instead of your shiny perfect system helped the coordinator to revive the team so it should be obvious that there *is* difference in management.

In T11070#238099, @zhigalin wrote:

In T11070#237992, @yurchor wrote:

Speaking anecdotally, I'd contributed through such a system fixing at least two small mistakes I came across and probably also translating some outstanding Strings (rating from what I did in the past on other projects). Also I think there are several more anecdotes like this around in the KDE community. Only they are hard to use as scientific justification.

O-o-h, yes! Can we lower the barriers for the code to have more anecdotes about KDE software?

Online translation tools can make access to translation easier (not even in every case) but they definitely make the translation process deadly longer. Everything comes with its price.

I would doubt that they make the translation process deadly longer in every case. Maybe in some corner cases that get more relevant for power users. That is why I think it is pretty important to be able to maintain their workflow, at least in a way there won't be substantial or maybe noticeable disadvantages.

They can have some Hawthorne effect (can be seen for UserBase and WikiToLearn) for the short runs but they stagnate in the long run because of their indisposable issues.

https://en.wikipedia.org/wiki/Hawthorne_effect

So if you just want to have more items in the team lists (most of them with ~0 % of contribution) then go on with the online tools. But be aware that the translation coverage and the quality will go down then. Dixi.

You and someone other seems to be making a mistake by equalizing our code contribution barrier and our translation contribution barrier.
They are not the same.
A developer unable to use git and collaboration platforms like Phabricator and Gitlab is not a good developer.
Devs can pass the code contribution barrier by using their developer skills.
But for a translator the usage of SVN (or other VCS) and the ability to handle handle PO files is not a part of their area of competence.
Sure, they can learn it, if they need it.
But as formerly said, they don't need it.
Because this is a purely volunteering part (unlike for devs who are getting experience and contributing to their CV).
The fundamental difference between the code barrier and the i18n barrier is that the skills necessary to overcome said barrier are inside the area of competence for devs but outside for translators,
so, if a dev can't handle it then he is not good enough to be allowed to contribute, but if a translator can't overcome the current barrier this does not mean he is not good enough.

Sure? Fundamental difference? Why did you compare them just below.

Sure.
Now, it should be common sense that if different things have some common aspect that aspect could be compared.

And you will decide which aspect it is. That's very convenient.

Just how you decided the difference between "contributor" and "translator". Very convenient indeed.

(not "to translate", not "to be effective", just "to contribute")

Illuminate me please on how could someone contribute to a translation without actually translating.

Simple. You want to change "foo" with "buzz" without reviewing. You go to Launchpad, register (there is no barrier there), change "foo" with "buzz", and vanish. You are a valuable contributor now. Other people might not want to call you "translator". In fact, when it comes to Russian, you can easily imagine some other term.

Other people might not want call you "contributor" either so that's not a valid point.

As in coding, in translation thinking consumes way more time than typing.

Of course. Why not allowing anonymous pushes?

You sure are capable to indicate when exactly I proposed allowing anonymous pushes or this is an another example of your cheap tricks?

No. You have proposed exactly this. Anybody registered within Weblate can push to "low the barriers".

Oh, so you go as low as making plain stupid lies.
You truly are willing to do anything and everything, aren't you?

I suggest everyone (and I literally mean everyone) stops commenting on this ticket for 48 hours.

Let's stop for a moment and reconvene.

In T11070#238111, @sanecito wrote:

The problem was not with tools (again). One more tool just makes the current life harder. Just look at this thread. All the problems can be solved with better team management.

No it can't. While technically there is a transfer process happening from SVN to Git, the problem of 'localizers should know SVN' is not being addressed. It's great that you and others put in the time to learn SVN, but telling linguists that no, they must first learn SVN to contribute string suggestions is utterly ridiculous and offputting. It's like telling people they can't make a fire with a lighter and instead they have to use a wood spindle simply because you spent time learning how to use a wood spindle. There are better tools in the world; KDE does not benefit by being stuck in the past using wood spindles over lighters. If you read the actual original ticket, the issue is not that coordinators have to sign off on translations, but rather the process to get, write, and submit suggestions is absolutely painful.

People are getting incredibly stuck up on approval being 'have X' votes. It doesn't have to be this way if this is an issue for people. You can have the old process in Weblate: someone submits a suggestion via Weblate, and then a team coordinator signs off on it/'submits' it. Coordinators can easily find these by either setting up notifications when a new suggestion is made for x component with y language, or just select strings w/ X language suggestions from the dashboard.

On a separate not unrelated to the tool, it's worth noting that at some point you have to make someone a team coordinator if there are no active ones for the language. Team coordinators of the past weren't magically given commit access, KDE granted it to them through some process or lack there of. Whatever process KDE used to say to establish the first Italian, Russian, etc team coordinators is the process that you can use going forward when dealing w/ inactive coordinators or the lack there of.

Yes, you are right. So the first thing that you as a coordinator should do is to write the instructions for the next coordinator on sustainable hosting. I have done this for Ukrainian and Russian. Other guys have done this for English (me just updated):

https://l10n.kde.org/docs/translation-howto/

And again, the same applies to Weblate things (even for Weblate itself).

https://docs.weblate.org/en/latest/contributing/release.html

Team management it is.

In T11070#238105, @yurchor wrote:

In T11070#238104, @dkazakov wrote:

Hi, @yurchor!

Could you please explain your total opposition to having Weblate as another source of translations?

Because I've used it for several years.

I think that we do not need "another source of translations". With Weblate/Transifex/whatever you will soon find that the team coordinator is gone, or do not want to approve your translations, or you do not want to approve somebody's translations. The problem was not with tools (again). One more tool just makes the current life harder. Just look at this thread. All the problems can be solved with better team management.

You are constantly saying that "the performance will be much lower", but noone in this thread says about forbidding direct pushes into svn/gitlab repository with translations.

No. Quite opposite. They say that it is hard/should be cut off/left for the "power" users.

More than that, @sanecito has just confirmed that one can lock the file in Weblate and work with it in his/her own way. Why can't you just lock the file in Weblate and go translating it in Lokalize?

Why should I lock it first?

Just an example. Today we have ~40 new strings in ~10 catalogs. I should go and find one of ~1000 KDE catalogs and lock it. ~5 mins of my time gone for nothing. I guess that overall probability that nobody wants to translate something is about 99.99%.

Another example. XX locked the catalog and gone. Who will unlock it for an abandoned language?

These locks are of no good for anybody except scripty or developers.

With such workflow Weblate will just work as a "translations coordinator", which distributes jobs among people. Where do I get it wrong?

Everywhere. First, most of the complaints are from people who do not want the distribution of jobs. They just want to change something and vanish.

Second, we are speaking about teams with 2-3 active translators (most KDE teams). "Coordination" in such teams is rather simplistic. You just translate, translate, and translate. Once in several months comes a guy/girl with a new translation which you have to review. Once a year, you have a correct bug report about a mistake in translation.

Almost all Weblate features are unusable in such a workflow. You just want to get rid of any coordination and go Launchpad/Rosetta way (or Transifex way like it is for MATE or Deepin), to be honest.

I'm the sole KDE translator into Polish for a long time, and generally agree with most (if not everything) that @yurchor writes.

I use Lokalize (+ kdesvn) for translations, and find it to be a great tool. Management time is minimal.

I think that switching to Weblate would cause more harm than good due to:

1. slower performance
2. "hit-and-run" translators

I think there should be some kind of an entry barrier for translating. If a potential translator is not determined to overcome them, then he's also not enough determined to do the real work.

I think that using either SVN or GIT should not be a concern for an occasional translator.
Nothing stops him from downloading .po file from https://l10n.kde.org/stats/gui/trunk-kf5/team/ and then sending it to a language coordinator.

I have a feeling that many people here don't translate stuff on a daily basis, and then post solutions to people that do it efficiently on a daily basis for years.

I hope that current system maintainers will favour solution better to current than future contributors.

@wojnilowicz

Why not integrating Lokalize with Weblate? There's a great API and you can choose what to load, possibly having some background worker to prefetch and sync the strings, glossary, suggestions, optional screenshots to speed things up, TM, etc.

There's no problem with hit-and-run because you can limit the access however you want, in LibreOffice I'm only getting suggestions by registered guests so they can hit-and-run as many suggestions they want.

@yaron
I think it's good idea.

I think that switching to Weblate would cause more harm than good due to:

1. slower performance
2. hit-and-run" translators

If people would completely read the conversation history they would realize both points are moot.

1. Again, the proposal is not to completely replace a SVN/Git Merge/Pull Request system, merely complement. If you prefer Lokalize because you believe it's faster by all means use Lokalize. Weblate would be so professional linguists aren't forced to read 57+ pages of highly technical computer science English documentation just to get started w/ the auxiliary components like SVN and can use a much easier work flow/tool, even if it's perceived to be a little slower.
2. Random people wouldn't have merge/PR access in Weblate. You can easily implement the policy in Weblate that people can only make suggestions w/ a registered account and said suggestions have to signed off by a team lead much like submitting a patch to the language team email lists. People can already submit hit and run patch suggestions to the mailing lists right now if they so felt.

More on 2.

"All the problems can be solved with better team management."

Again, no. It should be common sense better team management does not solve the issue in the proposal of the huge ramp of 57+ highly technical computer science related pages to read through for those who are professional linguists . Team leads coming and going, etc is independent of the tool(s) used. Solving a human problem does not solve the technical. If you want more professional linguists contributing to the project, one has to eliminate barriers like learning SVN and giving them tools that allow them to simply focus on localization: create account, select project in browser, select untranslated strings, and submit suggestions.

Or to put it more bluntly, everyone here can agree that having to learn SVN and other bits via 57+ pages of documentation just to suggest localized strings for even simple stuff like 'File', 'Edit', etc. is silly, right?

The current state of localization contributions will continue to be more apparent as KDE continues to create/adopt software and projects be it Plasma Mobile, Bigscreen, NeoChat, etc. without lowering the SVN/Git barriers for linguists who aren't versed in computer science. If you want projects like Plasma Mobile and PlaMo friendly KDE apps to succeed in user adoption against platforms like Android or Roku, they first need to be in peoples' native languages.

So I just tried to import all the summit translations to a local weblate instance (using docker). Unfortunately, the import failed after an hour with a timeout. Also, there are no native svn supports, it is just using git-svn. It looks like weblate is not optimized to handle big projects like KDE for now or at least not in a 16GB RAM/i7 CPU laptop. Also, the import was single-threaded :(

I created a bug report: https://github.com/WeblateOrg/weblate/issues/5128

Another 'simpler' ways would be to put the translations in the repo and let weblate handle it. And let lokalize fetch the translations from the weblate API instead of SVN. This would make all the git repositories the source of truth for the translations with GitLab fetching and pushing new translations to them (and with correct authorship for the commit). This would remove the need to have a SVN instance and make scripty useless. Maybe it would be worth at least experimenting with a few projects if this could work, same as we did with GitLab, and see if this really work and if we get more/less translations for these projects.

In T11070#247298, @wojnilowicz wrote:

I'm the sole KDE translator into Polish for a long time, and generally agree with most (if not everything) that @yurchor writes.

I use Lokalize (+ kdesvn) for translations, and find it to be a great tool. Management time is minimal.

I think that switching to Weblate would cause more harm than good due to:

1. slower performance
2. "hit-and-run" translators
   
   I think there should be some kind of an entry barrier for translating. If a potential translator is not determined to overcome them, then he's also not enough determined to do the real work.

We shouldn't have technical barriers on a translators/linguist. We can expect a developer to know how git works, but we can't expect the same for someone working with documentation or translations. Instead, we should expect good knowledge in the language.

I have a feeling that many people here don't translate stuff on a daily basis, and then post solutions to people that do it efficiently on a daily basis for years.

I translated many strings in the userbase wiki using the web translator. Unfortunately, I never jumped in doing application translation since I didn't know at that time how to use SVN, po files, and mailing lists.

I hope that current system maintainers will favour solution better to current than future contributors.

I hope we can find a solution that makes everyone happy. Currently, KDE software is poorly translated in non-European languages and I would hope this could change with "future contributors".

Translations in the repositories would make the life of people who touches several repositories almost impossible, so it's out of the question.
The solution is to make weblate work with a structure which fits us (either svn or per-language git repositories).

In T11070#247315, @sanecito wrote:

Or to put it more bluntly, everyone here can agree that having to learn SVN and other bits via 57+ pages of documentation just to suggest localized strings for even simple stuff like 'File', 'Edit', etc. is silly, right?

A personal note: I totally agree with almost everything in your comment, but I'd much prefer if you I'd stop with the "57+ pages" part, because that's not true. We can cut down that manual and make a better quick start guide (someone already wrote a good blog post, for example), because in reality the needed steps to start are much, much less.
I agree with everything else. Don't underestimate the management point, though.

EVERYONE: we are not discussing whether we need an online system, but how to go there in a way that does work also for heavy offline translators. So any comment about having or not an additional online translation system is just going to add noise, please avoid them.

In T11070#247390, @ltoscano wrote:

Translations in the repositories would make the life of people who touches several repositories almost impossible, so it's out of the question.
The solution is to make weblate work with a structure which fits us (either svn or per-language git repositories).

Unfortunately I am not that deeply into the workflows used for those people and also there seem to exist different usage scenarios. I am still wondering a bit whether this cannot be overcome, maybe by something like a reverse scripty so the source of truth is in the project's repositories. Maybe there is a way, I don't know. Also I guess it would help @ognarb with his approach if you could point out possible problems more precisely so one can think of solutions.

Online tools generally slow down high-volume translators. Plus, they are slow, and require an internet connection. Downloading and uploading translations are always a hassle, and error-prone.

KDE already has a greatly expandable tool named Lokalize. With some effort, it could provide a great environment for both coordinators-translators and occasional contributors.

1. Logging in to Lokalize with a KDE Invent account would help identify the translator
2. Lokalize can offer easy cloning of any repository available
3. Those with commit access can easily have their translations submitted through Lokalize; a commit button would greatly simplify things
4. Those without commit access would simply add suggestions that would pop up on coordinator's/translator's interface

In the meantime, Lokalize itself could also use some improvements. I've been heavily translating for almost a year now, and I still grep instead of using Lokalize's built-in search tool. The interface is also very fragile, for the sake of being too modular. Screwing up a layout is very easy but hard to recover.

I agree it could be a good solution but I'm looking at it from a different angle.

Allowing Lokalize to interact with Weblate using an API can do exactly that plus it will allow the translators who don't have access to their desktop computer to change strings, converse over strings and use screenshots (adding all those feature to Lokalize could be amazing but not mandatory).

This way we can have a modern translation tool instead of interacting with git/svn and still use Lokalize at will.

This is the bug I've opened for this suggestion:
https://bugs.kde.org/show_bug.cgi?id=432198

I suggested the same for gtranslator as the status in GNOME is sightly better than KDE but still has a long way to go.

Thank you.

Thanks for opening that request against Lokalize to plug into Weblate's existing API. A workflow that uses Weblate to remove the need to deal with git/svn to encourage contributions from non-Computer Science types while still allowing for those who have used Lokalize to continue using Lokalize is the best way forward I feel.