Hi! (This is my personal view, if solving this should prove difficult we might need a meeting of the coordination team to discuss this in detail.) After reading through (the English part of) the mails I came to some conclusions what is wrong in this team: * Trust: To me it seems that there is a lack of trust between the team members and the team coordinator. I think when you have some reviewers you should trust in them to make a final review. People will always make mistakes but it's better to "release early, release often". There are scripts that usually fix all the release critical bugs. If you find bugs later you can still fix it. But as long as a translation isn't public there won't be any users and thus no bug reports. So, I would encourage you to drop the final review stage (now). * Positiv attitude towards newcomers: First, nonetheless how it is implemented, a formal mail is not the way to go. We already place a good amount of hurdles in the way of new translators by having to get used to git/damned-lies, po-files, etc. This is not like launchpad where everyone can start translating and that's done on purpose. That means that everybody who got that first step will already have at least some understanding of the workflow and put effort in solving a steep learning curve. Of course translation quality might be poor in the beginning but everybody was a newcomer first. Usually it's good to setup some kind of rules for consistent translations were people can stick to. * Long-term vision: You will almost never find someone who will clearly state that he will be able to maintain a translation for the next few years. This is a volunteer project and life changes sometimes. But it is not a problem when different people translate the same module, neither for consistence nor for quality if done right. Reviewers will notice when there is an inconsistency within the strings and are able to point that out. I think most teams have no problem in sharing modules between different translators. => Assigning modules to a single person without giving others the chance to step up is a bad thing. * Personal differences: This happens, accept it. We don't need to be best friends all and we sure aren't. This is about getting work done which definitely fails here as the numbers show. So there is a problem and it is not a good idea to say everything is fine. As well as it is not true that everything is wrong. Marcel, I would love if you could point out how to solve this problem with real actions. You only talked about the past till now, please talk about the future. Thanks and regards, Johannes BTW, Marcel is missing as committer here: http://l10n.gnome.org/teams/sk Am Donnerstag, den 13.05.2010, 15:32 +0200 schrieb Marcel Telka: > On Thu, May 13, 2010 at 02:15:52PM +0200, Jiri Eischmann wrote: > > Compare logs under moduls in the Czech team and the Slovak team. Some > > translations are returned again and again. Why don't you make unclear > > or incorrect strings fuzzy and commit the translation to git? A > > translator can fix it later and users can use at least some > > translations. > > The translator is free to mark a problematic string fuzzy. Some > translators does that. > > > > > > This way works all reviewers in our team, not only me. To be exact I do > > > not review newly uploaded translations for some time. This is job for > > > our 4 reviewers. > > > > > > > returns a translation to a translator. This happens again and again > > > > until it's perfectly correct or more likely the translator gets > > > > > > Again, "perfectly correct" is not true. > > > > > Well, if you want to base your arguments on word nuances... we can call it a quality level > > which is discouraging for volunteers. > > Ok. This sounds more accurate. Thanks. > > > > OTOH, we have examples where translators complained about too loong time > > > between first submission and the final commit. When I sat down with the > > > translator and started to anlyze the Vertimus data we found that most of > > > the time was spent by either translating the module or reviewing it. > > > Overhead generated by my final check was about 15 %. After that the > > > translator admitted, that his copmlains were about feeling, not real > > > data. > > > How can translating slow down the process between uploading a > > > translation into Vertimus and getting to the git? If you don't > > > accept translations until they are >90 % it's the 60% of Empathy > > > case all over again. Instead of providing users at least a portion > > > of a translation you don't provide them anything. Not only for a few > > > months, but so far for years. For example I translated the Evolution > > > documentation for a year and half (it has more than 2000 strings and > > > strings in documentations are longer than in apps). If I had had to > > > wait almost two years until users can use my work I would have > > > probably given up very soon. > > Jiri, please do not write your sentences in a way they are looking as > mine. In this case it is very hard to find what is written by whom and I > can easily overlook your words. Thanks. > > Regarding your complains: I am not sure a half translated application is a > win for users. In addition, if the translation is not reviewed. > > For documentation, it might be different. But I am not sure too. > > > > Yeah, I have noticed. The problem is that you have not commited > > > almost anything for years. That's why the drop from 81 % down to 45 > > > %. As I said it's a very picky policy for the team which in such a > > > bad situation. > > The policy we are talking about now is established for about a year > (since February 2009). Before that we had only few members with very > limited free time. This was the reason for the drop. Not a policy. > > > > > I'm not a member of the Slovak team, so I can't take part in resolving > > > > this problem. But please take it seriously. From my point of view, there > > > > is no other real solution than changing the coordinator. I have followed > > > > the development in the team for quite a long time. There have been > > > > > > Thank you for following the development in our team. But I do not > > > understand how you follow it when you are not a member of our team and > > > you are not a member of the gnome-sk-list mailing list. You never > > > contacted me, you never asked me, IIRC. Thank you. > > > > > Do you know such a thing as a mailing list archive? You may be > > surprised, but they are available on the Internet. All messages in > > Vertimus are public as well. I have talked to many people from former, > > current members, members of other Slovak teams, and other people of > > the Slovak community. I have never wanted to make an intervention in > > your team. I thought it was a thing you had to resolve within your > > team. But I promised if they found out there was no way to resolve it > > within the team and had to go to public I would write what I have > > Apparently you talked only with people who supports Peter. And the > trigger was probably the contact from their side. This might be > objective, but also might not. > > > observed. As far as I know they initiated changes 5 months ago. You > > promised incremental changes and improvements, but the reality is that > > the situation is (surprisingly) about the same (well, all the process > > might be faster by 5 %). > > Thank you for measuring our speed up. > > > > > Because I don't want to send two responses I will briefly react to > > your second e-mail as well. You say there are 3 long-term translators > > and they support you. And you know what? I'm not surprised. One of my > > jobs is to look for new potential translators in Linux forums etc. In > > last two years, I have found several Slovak guys who wanted to give a > > hand. All of them either gave up immediatelly after they had found how > > it worked in the team or are pretty much inactive members. That's why > > I'm not surprised that the people who stayed in the team that long > > support you. Because those who disagreed are gone. As people who don't > > agree with the way the team works now will probably be gone sooner or > > later as well. > > I think you feed this in simplified way. You cannot easily have a team > with more than few people where everybody agree with everything. People > are different, they have different opinions, minds. If somebody who > disagree just bail out with no willing to help/improve it is his > decision. But if somebody want to help, he must accept some facts where > some level of disagreement must fly around. > > For example, I disagreed with GNOME move from CVS to SVN, but I accepted > that. I also disagreed with the move to git then, but I also accepted > that change. What should I have do? Should I left the GNOME and/or fight > for GNOME Board of Directors change? > > Or, when I asked for the gnome-sk-list mailig list creation. I was > forced to wait for several weeks until the mailing list is created. > Should I left or fight for GNOME sysadmins? > > I understand that most of us are volunteering this project (GTP) and > GNOME (mostly unpaid). I understand we all have our free time, I > understand we all cannot do everything now and here. > > > And please don't blame the number of translators in the team for the > > drop Slovak translations made in last years. As I said there is a > > reason why the team had just three members and even three members can > > do a lot if they are active and well-motivated and the process is > > fast(!). E.g. Czech translations of KDE are made basically by three > > guys and they are between 80 and 90 %. > > As I said above. The reason for drop was different. But apparently you > know reasons better than me. :-( > > Several years ago the GNOME was translated to Slovak by 2 key people > with occasional help from several others and we had 100 % translated. > But situation changed. The most active translator (and former > coordinator) left our two-man team and I started to have less free time > as I wanted to have. This is the reason for the drop. > > After years the team started to regenerate slowly. As I wrote earlier: > till February 2009 we had no special rules, no reviews. As translations > came in, they were integrated to the repository. >
Attachment:
signature.asc
Description: This is a digitally signed message part