In T11080#309987, @davidedmundson wrote:

Feel free to action reviving it if it's not too late to submit proposals. It can be copy pasted (resetting the 'I am willing to put work into this' section of course!)

I would also support this goal.

I'm deliberately not proposing or championing any goals this round, but if there's anyone else who would be willing to champion a revival of this one, I'll happily help to put work into it.

Feel free to action reviving it if it's not too late to submit proposals. It can be copy pasted (resetting the 'I am willing to put work into this' section of course!)

I agree, it would be amazing to revive this goal for 2024. I thought it was a great idea at the time it was proposed, and it's scoped appropriately for being a KDE-wide goal, not just something for e.g. Plasma.

In T11080#277259, @davidedmundson wrote:

In T11080#277256, @fusionfuture wrote:

+1 to revive this goal

Feel free to take this into the next round of goals. I won't have time to lead it, but I feel you're a good candidate to do so.

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.

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

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.

In T11080#277256, @fusionfuture wrote:

+1 to revive this goal

+1 to revive this goal

Yeah, the tabs in GNOME are fabulous and I wish someday Kirigami could gain a similar functionality. It could be really helpful for Okular Mobile, Angelfish, ...

About consistency of tabs accross applications, GNOME developers wrote new tab widgets from the ground up to replace all the different tabs they have accross their own applications:

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

In T11070#247315, @sanecito 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).

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 think that switching to Weblate would cause more harm than good due to:

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

@yaron
I think it's good idea.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

In T11070#238104, @dkazakov wrote:

Hi, @yurchor!

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

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?

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.

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.

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.

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.

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#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

In T11070#238095, @subins2000 wrote:

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)?

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.

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.

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