Carlos E. R. wrote:
They were not working because the developers were not doing their part. So, they are not happy and they change it, good, but destroying our side of the system, the side that was working correctly, bad.
More 'us' vs 'them' - Stop it Richard, please, stop pushing this "'us' vs 'them'" on Carlos and all of us. We are all adult people here, we all understand there is no 'versus' between devs and translators. Every team is doing its part of
As wonderful as things might have been from your perspective, the reality is that the output of 'your' part was not working correctly
Just look at Tumbleweed - Mostly untranslated, by your own omission
Just look at Leap - Untranslated, by your own omission As it was already pointed out, the whole process was just not fitting
2015-10-13 11:57 GMT+03:00 Richard Brown <RBrownCCB@opensuse.org>: the job for the sake of benefitting the project we all love, everything is fine here. Just a lack of communication between 'us' AND 'them', which can lead to undesirable consequences for the project as a whole. As you admitted in the following email, "communication about Weblate could have been handled better", so I suggest we all start to handle it better now. For instance, by stopping false accusations like these: the needs of these new release types, so saying that this situation is translators' own omission is an exaggeration. Once again, consequent steps for translating openSUSE are like this: Stage 1: 1.1) generate translation templates from the software (handled by devs, semi-automated work) 1.2) publish translation templates on i18n SVN (handled by devs, manual work) Stage 2: 1.3/2.1) generate translatable files from templates and push to i18n SVN where translators can get them by language (handled by translation coordinators: keichwa and sometimes community volunteers including myself; manual/semi-automated work) 2.2) get the files for your language and translate (handled by translators, manual work) 2.3) push translated files back to i18n SVN where devs can reach them (handled by translators, automated work: svn commit) Stage 3: 3.1) get the translated files from i18n SVN and push them for packaging for release (handled by devs/packagers, manual/semi-automated work) So, Tumbleweed was not performing well on stage 3 and Leap has never passed stage 1. Lack of performance and lots of manual work are easily noticeable in this 'old' process, so several developers decided to fix this and came up with the new solution, which brings some automation to stages 1 and 3. It is great, cause these stages failed most in the old approach, and now they should be passed like a breeze. From developers' point of view this should speed up the whole process significantly, cause 4 out of 6 steps will be automated. From translators point of view it is not that great because the price for speeding up other stages is ruining the only automated step of the old way and making harder others. Imagine we all are on the big ship: devs are the central section at the very core of the ship, translator's section is along a broadside. For historical reasons we have some water of noticable level in our sections which slows down the whole ship, but we somehow got used to it. Developers are smart guys and craft a new pumping station that pushes the water out of their section through the wall. Developers see the falling water level in their section and expect the ship to go faster, but it is not happening. Guess why? Because nobody asked the translators sitting behind this wall, the water level in their section is rising and the ship is still too heavy. Additional valve to pour the water through the broadside would correct the whole situation, but it was not included in this brand new pumping station. Back to the real life: all the translators will be really grateful for new tools that will fix the issues of the old way. There is absolutely nothing wrong in taking action to make everyone's life easier, but please consider that this introduced some problems, which are severely more notable from translators' side: 1. Stealing real content. "Never test on production" is a widely known postulate. I don't know the correct idiomatic expression in English, but here in Russia we call it "blood-written rule". Release notes of upcoming Leap release will get near to zero new translations, since it was taken out of "old but somewhat working" SVN server and put to "not yet an open beta" weblate server which no new translator is familiar with. 2. Scalability. When everything will be migrated to weblate it will result in almost 200 separate repos/projects. On currently deployed Weblate I saw no option to mass-download files of one language from all (or subset of) projects. Same for uploading. Managing that file by file in web UI is too much for one individual. Can we expect some API/scripting support on server side to be able to push a bunch of files at once from command line? That would really become the needed "valve" to speed everything up. 3. Communication. Knowing only by accident about significant changes gone live was not a pleasant experience and this thread was started in bad feelings. It is getting too big for detailed discussion, and my previous questions about proper ways to talk to weblate guys were not answered. I really would like to see devs/translators communication improving. Can we organize a separate technical discussion or even better an IRC meeting? I clearly saw form this and other discussions (incl. ongoing in yast-devel) that devs and translators have different understanding and priorities of the same process, so some meeting/detailed discussion would definitely help us to understand each other better. --- Best regards, Minton. -- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-translation+owner@opensuse.org