Committed. Thanks.
- Queries
- All Stories
- Search
- Advanced Search
Advanced Search
Jul 5 2023
Jul 4 2023
In D30134#684291, @okellogg wrote:I'm not sure whose turn it is, will you commit? Shall I?
Jul 3 2023
Thanks
Aug 30 2022
Oct 23 2021
I used to use scripting in Lokalize but... Ok, if it cannot be implemented anymore.
May 5 2021
In D29904#677749, @dreyero wrote:After creating this MR, do I need to add participants to that MR or is this done automatically?
What is the next step?( It is my first contribution to the KDE project )
Aug 24 2020
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.
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.
In T11070#238104, @dkazakov wrote:Hi, @yurchor!
Could you please explain your total opposition to having Weblate as another source of translations?
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.
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.
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.
Aug 23 2020
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#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.
Aug 22 2020
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?).
Aug 21 2020
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.
In T13514#237900, @clel wrote:In T13514#237897, @yurchor wrote:Weblate (as any online translation system) is still deadly slow compared to offline tools. On Hosted Weblate and Fedora's Weblate I witnessed constant git merge conflicts every week which should be resolved manually. This is a total nightmare for the KDE range of repositories number. Actually, I will have to prioritize some KDE translations because it is unrealistic to work with all of them through web interface (only ~15 minutes a day just to upload the translations, not saying about translating).
Weblate, Pootle, Wordbee, Transifex, Rosetta, etc. all tailored to leave several translations in a week or for *huge* teams.
Thanks for the insight. Maybe we should continue that on T11070 or T13311 to not hijack this task too much. I don't know the reasons behind those merge conflicts, so I cannot really judge the tools on that. Are you aware that you can download PO files from Weblate, use them in your offline workflow and upload them again?
In T13514#237894, @clel wrote:In T13514#237857, @ltoscano wrote:Is there some other reference where it is described, why this will make things "much harder for the translators"? Basically you would in fact have one central location for all files, but per project. Ideally those could get summarized at a different place like Weblate maybe, so there is still a fast overview of all projects and languages needing attention for example. Not sure whether that is supported by Weblate, though.
Not everyone will use weblate and we would have tons of repositories. It is not a path
The amount of repositories would not grow. The translations would just be incorporated and managed in the existing repositories for each project. The amount is also just as big as the already existing amount of projects. Can you elaborate what would be against using Weblate to manage those repositories? Maybe you can do that specifically in the task about evaluating an online translation tool to avoid duplication.
Jun 28 2020
Jun 20 2020
Jun 19 2020
Jun 18 2020
Jun 17 2020
Jun 16 2020
Jun 15 2020
Jun 14 2020
Jun 13 2020
Jun 11 2020
Jun 10 2020
Jun 9 2020
Jun 8 2020
Jun 7 2020
Jun 6 2020
Actually, Phabricator is deprecated. It is recommended to use gitlab for the patches now.
Jun 5 2020
Jun 4 2020
Moved: