Richard Brown wrote:
On 10 October 2015 at 16:11, Carlos E. R. <carlos.e.r@opensuse.org> wrote:
Some of the translators are now talking about this, and so far all think similarly.
I know it might seem weird to start my reply to your email with the last sentence, but I need to get it out of the way. I'm very disappointed to see you use the technique of citing others without examples in order to make your opinion sound more widely supported.
This has all been discussed on the openSUSE translation mailing list, which is the place discussions on the translation infrastructure are *supposed* to take place. But where no information at all about Weblate were posted – we translators had to find out about it ‘by accident’, by observing that some translation files were being removed in SVN. And since you require citations, here’s the first post from a user found out about it: http://lists.opensuse.org/opensuse-translation/2015-10/msg00011.html And here’s some of the posts by disappointed translators that you requested: http://lists.opensuse.org/opensuse-translation/2015-10/msg00017.html http://lists.opensuse.org/opensuse-translation/2015-10/msg00018.html And here’s a quote from that last message:
What does this mean for us? FMPOV, for us that means that nobody is actually interested in our opinion, nobody cares for our established workflow and nobody has a clue about best practices in decision making by discussing the issue with those who are interested. This exact move of files clearly wasn't decided here on translators mailing list. No recent discussion was held, no simple warning was posted (sic!). I find this move really demotivating.
Tomas Chvatal, sbrabec, mcihar and others have been working on the idea of using Weblate for quite some time (2 years+)
In the past, attempts to raise conversations on topics around changing the translation workflow often resulted in bikeshedding
For example, I can think of several threads where talk about translating Tumbleweed were discussed ( http://lists.opensuse.org/opensuse-factory/2015-07/msg00921.html, http://lists.opensuse.org/opensuse-translation/2015-08/msg00022.html ) just to have the situation declared 'impossible' because the current workflow wouldn't fit with it, but no discussion to alter that workflow seemed to take root
Based on your first commented, I’m sort of disappointed you don’t cite any example of your last statement here (‘have the situation declared 'impossible'’), and take exception to your describing previous discussions as ‘bikeshedding’. But no worries. :) There has been numerous discussions on the mailing list about the (major) problems with the current translation workflow (choose just about any thread at http://lists.opensuse.org/opensuse-project/), and the translators have been very interested in having the way translations are handled imrpvoed. But translators are translators, *not* developers. And even if they were, they *can’t* change the workflow i.e. by telling developers that they must completely change *their* workflow. So the translators have been pretty powerless because of this, also because of lack of communication with any *with* the power to improve the situation. (All we can do is basically to keep translating, and hope things improve. Or quit from the project if things continue to get worse.)
This also happened on the Landing page translation thread ( http://lists.opensuse.org/opensuse-translation/2015-07/msg00009.html ) where any discussion about changing the workflow of translation for the site was pretty much killed without consideration.
For anyone reading the above and not understanding a thing, here’s an explanation. Normally translators use a translating application (e.g. KDE Lokalize). This basically shows a list of English strings, which one can navigate and supply translations too. There are also many other nice features to ensure high- quality and consistent translations, like a spell checking feature and automatic translation suggestions (based on similar translations). When one of the English strings are changed (perhaps to fix a spelling mistake), the application can show the original string and the new string, along with colour coded ‘diff’, so the translator can easily see what’s changed. Here’s a screenshot of one such application (showing just a few of the features): https://docs.kde.org/trunk5/en/kdesdk/lokalize/sync.png (Different translators can use different tools, with different feature sets, based on personal preferences (it’s a Vim/emacs-like thing). Some used Web- based systems to coordinate the translations. Some translations teams also have various custom-made tools (e.g. scripts) to ensure high-quality translations.) This is a nice and comfortable way of working for the translators. BTW, note that the same translation application and translation file format is used for *all* translatable strings, no matter if the application being translated was written in C, C++, Python, JavaScript, or is not an application at all, but some strings in, e.g., an XML file. What the message cited above said was basically this (I’m paraphrasing): Hi, translators. We have created a new ‘landing page’. To translate this (about 50 strings), you will have to 1) learn Git 2) learn to ‘fork’ a project in Git 3) manually copy some files 4) learn the JSON format, manually edit the JSON format with translations 5) manually edit a HTML file and a JavaScript 6) make a ‘pull request’ 7) continously monitor our Git repository to see if any strings are changed or added 8) figure out what is changed, and manually edit the corresponding translations 9) make new pull requests That was the ‘new workflow’ that was proposed for our (non-developer) translators, which were natually not overly enthused with this. Luckily, there was happy ending to all of this. Someone created some scripts to convert the JSON files to standard translation files (and back to JSON again), and the translators could use their normal translation application to translate the ~50 strings (and to keep them updated with any future changes), avoiding steps 1 to 9. It became the responsibility of the landing page developer to integrate the translations into the page whenever needed.
We need to move forward and be open to change.
I believe the translators are very much interested in improvements in the way translations are handled (the current situation (which has been this way for years, but which has gotten even worse with Leap and Tumbleweed) is *not* good, e.g. many translations are actually not shipped at all along with the applications). What we’re most upset about is the *complete lack of any communication*. To make this easier to understand for developers, this is what it would look like if a similar thing happened to the ‘developer’s workflow’: You’re working on developing some tools for openSUSE, as an unpaid volunteer. One day, you see some (not all) source code files for your project disappearing, replaced by links to some Web site (‘Web code: an online source-code editor’) you haven’t heard about. You check the devel mailing list, but there’s no information. Some days go by, and more and more source code files disappear. You write an e-mail to the devel list (‘What’s going on?’). No reply, except for from other confused developers. Gradually, people begin figuring out that source will be migrated to an online source-code editor (still no official communication from the ones doing the migration, though). Finally, some developer figures decides to post a question to a different mailing list (where developers not usually hangs out). And finally, some information is posted by someone who actually involved in the ‘migration’. It turns out that developing is now being moved to the Web, to an online source-code editor. But, you’re ensured, it’s really nice. It even has a spell-checking feature. Of course, it doesn’t have syntax highlighting, which you depend on, and you can only see 10 lines at the time. But not to worry, the person tells you: You can still download and upload the source code, for ‘offline editing’, if you *really* want to, and prefer to work in Vim or emacs. But you have to manually download and upload *each* source code file seperately (two or three clicks each, plus the clicks neeed to navigate to correct source code folder). You decide to try this (‘new and improved workflow’). You click and download a source code file (*click, click, click*). Manually edit it, like you used to, using your favourite editor. And then you reupload it (*click, click, click*). The next time you download it, you figure out that all the source code comments have been removed. It turns out that *source code comments* is not supported in this new online editor, so they’re automatically stripped. This is basically an exact anology of what’s happened for the translators working as volunteers on translation openSUSE. Now, are you surprised that we get messages like this from the translators: http://lists.opensuse.org/opensuse-translation/2015-10/msg00018.html
What does this mean for us? FMPOV, for us that means that nobody is actually interested in our opinion, nobody cares for our established workflow and nobody has a clue about best practices in decision making by discussing the issue with those who are interested. This exact move of files clearly wasn't decided here on translators mailing list. No recent discussion was held, no simple warning was posted (sic!). I find this move really demotivating.
-- Karl Ove Hufthammer -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org