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 :

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.

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.

In T11070#238031, @kucharczyk wrote:

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

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.

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.

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.

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

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.

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

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

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.

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.

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?

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.

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.

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.

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.

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

In T11070#237890, @aacid wrote:

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

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.

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.

In T11070#237855, @clel wrote:

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.

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

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.

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

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.

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

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.

I just noticed something, the lack of consistent spacial navigation direction in the older widget store windows, having the content on the left and the sidebar on the right. I know there's new kcm's that have a vertical focused organization layout.

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.

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.

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

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

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?

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.

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.

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

In T11070#230947, @slavekb wrote:

In T11070#230929, @ltoscano wrote:

As I mentioned – POT files are updated externally and are pushed into the GIT, as the unique place to which they belong.

Weblate then automatically takes care of updating PO files according to templates. There probably does not give much reason for this step to be solved by each team individually / manually. Therefore, it seems like a good idea when this is done automatically in Weblate.

Just for the record: our current automation already does it (for the last 15+ years).

Sure, I had no doubt that this is already automated. With such a volume of translations, it is not possible otherwise.

Updating PO files by POT is basically a mechanical operation, so there can be a useful one when Weblate does this, as a central place to manage PO files, because during that, it can do merges with currently pending translations.

In T11070#230929, @ltoscano wrote:

As I mentioned – POT files are updated externally and are pushed into the GIT, as the unique place to which they belong.

Weblate then automatically takes care of updating PO files according to templates. There probably does not give much reason for this step to be solved by each team individually / manually. Therefore, it seems like a good idea when this is done automatically in Weblate.

Just for the record: our current automation already does it (for the last 15+ years).

In T11070#230944, @slavekb wrote:

In T11070#230929, @ltoscano wrote:

As I mentioned – POT files are updated externally and are pushed into the GIT, as the unique place to which they belong.

Weblate then automatically takes care of updating PO files according to templates. There probably does not give much reason for this step to be solved by each team individually / manually. Therefore, it seems like a good idea when this is done automatically in Weblate.

In T11070#230929, @ltoscano wrote:

In T11070#230928, @slavekb wrote:

In T11070#230898, @ltoscano wrote:

In T11070#230894, @slavekb wrote:

If you find it useful, I can mention the experience of using Weblate for a project that is very similar to the scope of translations – Trinity Desktop Environment – see TDE Weblate.

It's a tool people are very aware of, and probably one of the best candidate. That said, it's not just "install and it magically integrates in the existing infrastructure". Which again, does *not* mean it won't
be implemented.

Yes, of course, it doesn't solve integration by waving a magic wand – it takes effort. However, it can be beneficial for process automation.

For example, for TDE:

PO file management is now the sole responsibility of TDE Weblate. Outside TDE Weblate is an automated update of POT files that are pushed into TDE Gitea. Thanks to the webhook, an update is triggered in the TDE Weblate. And TDE Weblate will update each PO file, which is pushed back into TDE Gitea.

This is the easy part, but I'm not sure I want to delegate to tool the full handling of the templates and translations. The source should be external, and the tool just use that, but not being the reference place. This also because some teams may decide to opt out from the web tool, and because we still need to perform low level operations on the translations if needed.

In T11070#230928, @slavekb wrote:

In T11070#230898, @ltoscano wrote:

In T11070#230894, @slavekb wrote:

If you find it useful, I can mention the experience of using Weblate for a project that is very similar to the scope of translations – Trinity Desktop Environment – see TDE Weblate.

It's a tool people are very aware of, and probably one of the best candidate. That said, it's not just "install and it magically integrates in the existing infrastructure". Which again, does *not* mean it won't
be implemented.

Yes, of course, it doesn't solve integration by waving a magic wand – it takes effort. However, it can be beneficial for process automation.

For example, for TDE:

PO file management is now the sole responsibility of TDE Weblate. Outside TDE Weblate is an automated update of POT files that are pushed into TDE Gitea. Thanks to the webhook, an update is triggered in the TDE Weblate. And TDE Weblate will update each PO file, which is pushed back into TDE Gitea.

In T11070#230898, @ltoscano wrote:

In T11070#230894, @slavekb wrote:

If you find it useful, I can mention the experience of using Weblate for a project that is very similar to the scope of translations – Trinity Desktop Environment – see TDE Weblate.

It's a tool people are very aware of, and probably one of the best candidate. That said, it's not just "install and it magically integrates in the existing infrastructure". Which again, does *not* mean it won't
be implemented.

No, moving to better infrastructure and tooling won't make translators more responsive.

And having a better tool doesn't guarantee it either. BUT. It enables people who want to put in the work to be able to do the work without a huge overhead.

In T11070#230899, @frederico wrote:

And I have another fear: bad translations. Some people said to our translation group that would be interesting that Lokalize include a tool to use Google Translator, for example. And I work on some translation on Transifex and saw terrible translations, clearly result of using automatic translations. One tremendous problem that we had was with Rocs. In Brazilian Portuguese, we translate "graph" in two different ways: when it's about graph theory, we use "grafo" and when is graph as charts, we use "gráfico". Well, someone translated all "graph" in Rocs as "gráfico" and not "grafo". You can imagine the problem of it, specially because this is an educational tool... And I won't even talk about consistency problems, of terms translated differently in the same package.

@ltoscano I don't think we're disagreeing. It's obvious you are not against this project moving forward so my original argument was not directed at you.

My 5 cents...

In T11070#230894, @slavekb wrote:

If you find it useful, I can mention the experience of using Weblate for a project that is very similar to the scope of translations – Trinity Desktop Environment – see TDE Weblate.