-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-10-10 23:06, Alexander Melentev wrote:
2015-10-10 20:48 GMT+03:00 Tomáš Chvátal
:
Hello, Hi, Tomáš. Before I start my inline ranting I'd like to let you know how grateful I am for your extensive explanations, we all have missed them from the beginning. Really, I mean it, thank you so much.
Yes.
full and official announcement of the beta will be going at some point next few weeks. We just needed to "steal" some of the projects already being translated to ensure good live testing.
And one of the "stolen" projects is RELEASE NOTES exactly a few weeks before the release when there is still no single translator familiar with this new and not still established process. How do you expect to have any release notes translated in time for this release? I really would like to see the genius eyes of the guy who decided to do exactly that in this specific moment.
The plan is to have weblate for all the stuff, because it will by this per- project git repository solve most of the trouble we are having wrt longstanging SLE issues and now inherited by Leap issues.
We thought really hard about the problem and the fact that weblate actually is open-source and can be glued to internal infrastructure was the winner.
Yes, we all know this FOSS mantra "who codes decides", but I really don't think that trading devs headaches for translators' headaches is a way to go.
And this decision was made without even commenting with us... :-( Yes, It is not "those who do it decides", as we were told. They don't consider us part of "those who do". We don't code. :-//
Now for the concerns raised over the thread:
1) po translations will be allowed even externaly, ie. direct git commits 2) weblate allows mass-download and mass upload, so you can use the tool even for some checks if you don't want to do direct commits
Having more than one way to push translations in is pure evil cause it leads to conflicts. Code developers might think that git access for everybody might be a good idea and is managable, but in case of translations in terms of quality and consistency it is a road to hell: there are substantial differences between collaborating on code and collaborating on translations. Before making such "game-changing" decisions it might be a good idea to consult/collect feedback from the guys who have real experience with this "game". Lack of such communication at the very start of significant change is really frustrating.
I concur.
So you can try the translating as of now and collaboration will be deployed in close future. If you find any problems with the tool, like crashes where we didn't noticed them, or something does not behave like it should please sent sbrabec an email about it or file a ticked in bugtracker.
Please be more specific as we still have no valid info about authors of this decision and proper ways of communication with them. For instance, I once was denied to fulfill my NEEDINFO request to coolo, cause the email address I picked for this was not the one coolo expected (while still being valid coolo's address). So, what is the correct sbrabec's address for this? What is the correct bugtracker/component for such "early bird" bug reports? Where exactly was the discussion about all this held and how we can take part in it and make comments and requests? Who should we discuss the solution architecture with, i.e. this easily foreseeable scalability/managability issue I described earlier about a single translator VS 150+ repos? I am really interested in all this.
Yes, I concur. Well... I will not do any testing, not this time :-( I require first that all the procedures be documented at opensuse.org site, in text fit for dummies. I'm not going to do the investigating on how to do things, not this time, sorry. I'm too tired. Those that did this without asking or telling us, now will have to go further and explain it all to us. I need procedures documented on how to work this with lokalize (the kde tool), or equivalent (poedit?). I need to know how to download ALL the .po and .pot files to my computer: one directory for all the POTs, and another directory for all the POs, one per language. In a command or two. And there have to be different sets for different openSUSE versions: 13.2, leap, tumbleweed, etc. Ie, an structure that functionally replicates what we now have on SVN. I also need to know how to control who can commit translations of what file. Ie, to assign a file to a particular translator. And this needs to be done manually, by the coordinator, or automatically (autoassignation). Both methods are supported by Vertaal. When all is documented, I will read and evaluate. Then I will consider whether I keep contributing as translator, or not. I'm too tired to do the investigation myself...
PS: Did you know that some of those PO translations in SVN were not used for like 7 years? Now they are :) It is good that new tools can solve old issues. Now let's ensure they will not create more new issues and I think we'd better do it together =)
Indeed. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlYZkwkACgkQja8UbcUWM1wtpAD/TzGfccPNZT4tS3ScJAVAM5YD kmPr2J+kjne8qieQnl4A/i5mo0UqtdXbkyTDdPeVP8bqS5Sb0bVZF8N7Xg0jRXIO =ZItQ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-translation+owner@opensuse.org