From bgroh at redhat.com Thu Jul 1 01:13:50 2004 From: bgroh at redhat.com (Bernd Groh) Date: Thu, 01 Jul 2004 11:13:50 +1000 Subject: About the new Status Pages Message-ID: <40E3654E.7050807@redhat.com> Hi All, since there has been some confusion about the new status pages, I feel like I need to summarize what actually happened, and let me assure you, it wasn't a step away from teams. Established language teams are well considered by the new status pages, much more than previously. Yes, we are still missing team pages, and we do apologise for not having had the ressources to put them up yet, but it is our intention to do so. Things are moving towards teams, and we'd like to encourage them, however, we are reluctant to mandate things and tell you how things are going to be, since that's not entirely up to us, but also up to you. So, what is new? First new thing is that a module can be assigned to a Translator and there is a [Take]/[Release] mechanism in place. What exactly is a Translator in this respect? A Translator is a person translating a file at a given time (thanks, Josep ). What's it for? Two things. First, so other people know who's currently doing what, and second, to minimise conflicts because two translators are working on the same file at the same time. You say that wouldn't happen if you'd have a group and one coordinator to coordinate all translations of the group? For a small group that might be feasible, but if you have one coordinator and 70+ translators, things can get quite difficult to manage this way. Also, we would require the coordinator to be available at all time, we'd require the coordinator to make a decision, or we'd require 70 people to discuss about who's going to translate the file. Sometimes it is much easier if, given the translator can do a good translation of the file, whoever sees first that there is a file to be translated, that this translator just does the job. Sometimes, there can be too much talking about things, and it is, in fact, better to just do it. And there's nothing that says that that's not how the group wants to do things. Not all groups work in the same way. That might have an effect on consistency? If the group has already agreed on a certain terminology, and a person of that group simply does the job, without requiring too much talking about it, how? As said, different groups work differently, and I do not like the idea to build a system that is set to a certain way, I rather build a system that can accommodate a large range of behaviours of groups, or even of individuals. And yes, I am aware of the disadvantages of this system, but IMO, groups should form because groups want to form, and not because they have to form in order for the entire system to work, groups should form in the way they want to form, and not in one certain way, because that's the only way the system accommodates for it. How was the [Take]/[Release] mechanism intended to be used? A file should be [Take]n before starting the translation, before doing a last cvs up. Then the file should be worked on, and it should be commited whenever you stop translating it. If you intend to keep working on it soon, you keep the file, otherwise, you [Release] it. If you do commit a finished file, it'll be released automatically. This allows people to work independently, without requiring a group? Yes, it does. It doesn't encourage groups? No, it doesn't. It is not the job of a system to encourage groups, it is the job of people. People encourage other people. I'd encourage anyone to join a group, everyone should encourage everyone to join a group. If it is really the case that most people ask for groups, and want to work in groups, why should it even be necessary to mandate them? Shouldn't it then be the case that most people actually do work in groups? It is up to every individual to form a group, and to work in groups, it is, IMO, not up to one individual to make groups happen. What else is new? The system allows for a module to have a maintainer. What exactly is a Maintainer in this respect? A Maintainer is the person accountable for the translation of a file. A Maintainer is the person commited to providing a high-quality translation of that module to the user-community. Yes, the maintainer is also the one who takes the blame for a bad translation. As such, to compensate for the additional responsibilities, the maintainer also has additional privileges. The maintainer can manage who's translating the file. A maintainer is now informed if someone takes the file (thanks, Josep ), and can chose to release the module and take it herself/himself or to get someone else to take it. A Maintainer is also informed of all commits to the file. If a module has been finished, the module will automatically be set to QA and the maintainer is now the only person with commit access to this file, unless s/he [Approve]s it, or commits it, which we recognize as approval. How do we support established translation teams? By making them maintainers of modules, by letting them take over the responsibility they've been carrying in the past, and by now providing them with a mechanism to better manage the translation of a particular module, also with informing them if somebody else is working on the file. Do we support coordinators? Coordinators of small teams are invited to apply for maintainership of all modules of a certain language. In general, and if there are no objections from other members within the same language group, this will be granted. For large teams, it may be better to split maintainership to several individuals by coordinating/maintaining a group of modules, however, we'd still, given there are no objections, grant such request. If at any time, there are objections with regards to a certain maintainer, everyone objecting is invited to make their case. Every opinion will be heard, and we're happy to take concerns to a maintainer directly. That's about all. Again, apologies if the introduction of the new status pages has been confusing, it wasn't our intention, and we will discuss any further change on this list now. We'd also like to encourage people to speak up, and not just if things aren't the way they want them to be. After all, it is everyone's community. Regards, Bernd -- Dr. Bernd R. Groh Phone : +61 7 3514 8114 Software Engineer (Localization) Fax : +61 7 3514 8199 Red Hat Asia-Pacific Mobile: +61 403 851 269 Disclaimer: http://apac.redhat.com/disclaimer/ From s.mako at gmx.net Thu Jul 1 07:37:25 2004 From: s.mako at gmx.net (Zoltan Kota) Date: Thu, 1 Jul 2004 09:37:25 +0200 (CEST) Subject: Hungarian members Message-ID: Hi, I joined recently the translation project. How many hungarians are involved? Can anybody tell me? Zoltan From Viktor.Hauk at kurt.hu Thu Jul 1 08:26:38 2004 From: Viktor.Hauk at kurt.hu (Hauk Viktor) Date: Thu, 1 Jul 2004 10:26:38 +0200 Subject: Hungarian members Message-ID: <41765BD72F8FCE45B6D1A637500B1B363E6F4F@jupiter.KURTHQ.local> > Hi, > > I joined recently the translation project. How many > hungarians are involved? Can anybody tell me? > > Zoltan > > The Hungarian translation team is "led" by Tamas Szanto [tszanto at MOL.hu]...well he's the uy who did most of the translating. Can't exactly tell how many we are but any help is welcome :D With kind regards Viktor viktor.hauk at kurt.hu From sp at elte.hu Thu Jul 1 09:45:43 2004 From: sp at elte.hu (Sulyok Peti) Date: Thu, 01 Jul 2004 11:45:43 +0200 Subject: Hungarian members In-Reply-To: <41765BD72F8FCE45B6D1A637500B1B363E6F4F@jupiter.KURTHQ.local> References: <41765BD72F8FCE45B6D1A637500B1B363E6F4F@jupiter.KURTHQ.local> Message-ID: <1088675143.4071.7.camel@sutty.mshome.net> 2004-07-01, cs keltez?ssel 10:26-kor Hauk Viktor ezt ?rta: > > Hi, > > > > I joined recently the translation project. How many > > hungarians are involved? Can anybody tell me? > > > > Zoltan > > > > > The Hungarian translation team is "led" by Tamas Szanto > [tszanto at MOL.hu]...well he's the uy who did most of the translating. > Can't exactly tell how many we are but any help is welcome :D > Could you tell me some more about that team, because I could not establish connection to it when I started translating Fedora. I would also join if I knew how. I guess we are at least 5 and could ask for a fedora-trans-hu list. Regards, Peti sp at elte.hu -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ez az ?zenetr?sz digit?lis al??r?ssal van ell?tva URL: From hutuworm at hutuworm.org Thu Jul 1 09:54:16 2004 From: hutuworm at hutuworm.org (hutuworm) Date: Thu, 1 Jul 2004 17:54:16 +0800 Subject: About the new Status Pages Message-ID: <200407010954.i619sUe1005950@mx1.redhat.com> Bernd Groh, Thank you very much for your hard work and good job! :D I've just tried the updated status system, it really works well. Thank you. ======= 2004-07-01 09:13:50 Quote from your mail ======= >Hi All, > >since there has been some confusion about the new status pages, I feel >like I need to summarize what actually happened, and let me assure you, >it wasn't a step away from teams. Established language teams are well >considered by the new status pages, much more than previously. Yes, we >are still missing team pages, and we do apologise for not having had the >ressources to put them up yet, but it is our intention to do so. Things >are moving towards teams, and we'd like to encourage them, however, we >are reluctant to mandate things and tell you how things are going to be, >since that's not entirely up to us, but also up to you. > >So, what is new? > >First new thing is that a module can be assigned to a Translator and >there is a [Take]/[Release] mechanism in place. What exactly is a >Translator in this respect? A Translator is a person translating a file >at a given time (thanks, Josep ). What's it for? Two things. First, so >other people know who's currently doing what, and second, to minimise >conflicts because two translators are working on the same file at the >same time. You say that wouldn't happen if you'd have a group and one >coordinator to coordinate all translations of the group? For a small >group that might be feasible, but if you have one coordinator and 70+ >translators, things can get quite difficult to manage this way. Also, we >would require the coordinator to be available at all time, we'd require >the coordinator to make a decision, or we'd require 70 people to >discuss about who's going to translate the file. Sometimes it is much >easier if, given the translator can do a good translation of the file, >whoever sees first that there is a file to be translated, that this >translator just does the job. Sometimes, there can be too much talking >about things, and it is, in fact, better to just do it. And there's >nothing that says that that's not how the group wants to do things. Not >all groups work in the same way. That might have an effect on >consistency? If the group has already agreed on a certain terminology, >and a person of that group simply does the job, without requiring too >much talking about it, how? As said, different groups work differently, >and I do not like the idea to build a system that is set to a certain >way, I rather build a system that can accommodate a large range of >behaviours of groups, or even of individuals. And yes, I am aware of the >disadvantages of this system, but IMO, groups should form because groups >want to form, and not because they have to form in order for the entire >system to work, groups should form in the way they want to form, and not >in one certain way, because that's the only way the system accommodates >for it. > >How was the [Take]/[Release] mechanism intended to be used? A file >should be [Take]n before starting the translation, before doing a last >cvs up. Then the file should be worked on, and it should be commited >whenever you stop translating it. If you intend to keep working on it >soon, you keep the file, otherwise, you [Release] it. If you do commit a >finished file, it'll be released automatically. > >This allows people to work independently, without requiring a group? >Yes, it does. It doesn't encourage groups? No, it doesn't. It is not the >job of a system to encourage groups, it is the job of people. People >encourage other people. I'd encourage anyone to join a group, everyone >should encourage everyone to join a group. If it is really the case that >most people ask for groups, and want to work in groups, why should it >even be necessary to mandate them? Shouldn't it then be the case that >most people actually do work in groups? It is up to every individual to >form a group, and to work in groups, it is, IMO, not up to one >individual to make groups happen. > >What else is new? > >The system allows for a module to have a maintainer. What exactly is a >Maintainer in this respect? A Maintainer is the person accountable for >the translation of a file. A Maintainer is the person commited to >providing a high-quality translation of that module to the >user-community. Yes, the maintainer is also the one who takes the blame >for a bad translation. As such, to compensate for the additional >responsibilities, the maintainer also has additional privileges. The >maintainer can manage who's translating the file. A maintainer is now >informed if someone takes the file (thanks, Josep ), and can chose to >release the module and take it herself/himself or to get someone else to >take it. A Maintainer is also informed of all commits to the file. If a >module has been finished, the module will automatically be set to QA and >the maintainer is now the only person with commit access to this file, >unless s/he [Approve]s it, or commits it, which we recognize as approval. > >How do we support established translation teams? By making them >maintainers of modules, by letting them take over the responsibility >they've been carrying in the past, and by now providing them with a >mechanism to better manage the translation of a particular module, also >with informing them if somebody else is working on the file. Do we >support coordinators? Coordinators of small teams are invited to apply >for maintainership of all modules of a certain language. In general, and >if there are no objections from other members within the same language >group, this will be granted. For large teams, it may be better to split >maintainership to several individuals by coordinating/maintaining a >group of modules, however, we'd still, given there are no objections, >grant such request. If at any time, there are objections with regards to >a certain maintainer, everyone objecting is invited to make their case. >Every opinion will be heard, and we're happy to take concerns to a >maintainer directly. > >That's about all. Again, apologies if the introduction of the new status >pages has been confusing, it wasn't our intention, and we will discuss >any further change on this list now. We'd also like to encourage people >to speak up, and not just if things aren't the way they want them to be. >After all, it is everyone's community. > >Regards, >Bernd > >-- >Dr. Bernd R. Groh Phone : +61 7 3514 8114 >Software Engineer (Localization) Fax : +61 7 3514 8199 >Red Hat Asia-Pacific Mobile: +61 403 851 269 >Disclaimer: http://apac.redhat.com/disclaimer/ > > > >-- >Fedora-trans-list mailing list >Fedora-trans-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-trans-list > ================================================== hutuworm From bgroh at redhat.com Fri Jul 2 01:20:23 2004 From: bgroh at redhat.com (Bernd Groh) Date: Fri, 02 Jul 2004 11:20:23 +1000 Subject: About the new Status Pages In-Reply-To: <40E3654E.7050807@redhat.com> References: <40E3654E.7050807@redhat.com> Message-ID: <40E4B857.4090101@redhat.com> Hi again, > [snip] If a module has been finished, the module will automatically be > set to QA and the maintainer is now the only person with commit access > to this file, unless s/he [Approve]s it, or commits it, which we > recognize as approval. The [Approve] button is on the page for the individual module. If you click on the link for a module that is in QA, you'll see it next to the translation status. Bernd From bgroh at redhat.com Fri Jul 2 01:34:21 2004 From: bgroh at redhat.com (Bernd Groh) Date: Fri, 02 Jul 2004 11:34:21 +1000 Subject: Auto-Release after 1 week enabled Message-ID: <40E4BB9D.5030605@redhat.com> Hi All, since people can forget to release a module after they've stopped working on it, we've implemented a mechanism that releases a module after one week (for now) of no commit automatically. We start to send out reminders after 3 days of no commit, and do an automatic release every Monday Morning 6ish GMT (starting this coming Monday). Of course, we can further discuss what a good time-frame is or whether that's a good system at all, but for now we've put it in place. Regards, Bernd -- Dr. Bernd R. Groh Phone : +61 7 3514 8114 Software Engineer (Localization) Fax : +61 7 3514 8199 Red Hat Asia-Pacific Mobile: +61 403 851 269 Disclaimer: http://apac.redhat.com/disclaimer/ From rodolfo at heartsome.net Fri Jul 2 01:55:35 2004 From: rodolfo at heartsome.net (Rodolfo M. Raya) Date: Thu, 01 Jul 2004 22:55:35 -0300 Subject: Auto-Release after 1 week enabled In-Reply-To: <40E4BB9D.5030605@redhat.com> References: <40E4BB9D.5030605@redhat.com> Message-ID: <1088733334.15420.217.camel@elrond.maxprograms.com> On Thu, 2004-07-01 at 22:34, Bernd Groh wrote: > Hi All, > > since people can forget to release a module after they've stopped > working on it, we've implemented a mechanism that releases a module > after one week (for now) of no commit automatically. We start to send > out reminders after 3 days of no commit, and do an automatic release > every Monday Morning 6ish GMT (starting this coming Monday). Of course, > we can further discuss what a good time-frame is or whether that's a > good system at all, but for now we've put it in place. Hi, Could you change the system to release the file one week after the file was taken? One week seems OK to me, but count since the file is taken. I usually translate on weekends and take a couple of days for reviewing, this means I commit on Monday or Tuesday. If the system releases the file on Monday morning (Sunday night my time), it will be an annoyance. My 0.02 Rodolfo -- Rodolfo M. Raya Heartsome Holdings Pte. Ltd. From tome at users.ossm.org.mk Fri Jul 2 20:44:03 2004 From: tome at users.ossm.org.mk (=?koi8-r?Q?=F4=CF=CD=C9=D3=CC=C1=D7_?= =?koi8-r?Q?=ED=C1=D2=CB=CF=D7=D3=CB=C9?=) Date: Fri, 02 Jul 2004 22:44:03 +0200 Subject: Auto-Release after 1 week enabled In-Reply-To: <1088733334.15420.217.camel@elrond.maxprograms.com> References: <40E4BB9D.5030605@redhat.com> <1088733334.15420.217.camel@elrond.maxprograms.com> Message-ID: <1088801043.2582.6.camel@localhost.localdomain> On ???, 2004-07-02 at 03:55, Rodolfo M. Raya wrote: > Could you change the system to release the file one week after the file > was taken? One week after last commit is a perfect time. Greetings to this implementation. > I usually translate on weekends and take a couple of days for reviewing, > this means I commit on Monday or Tuesday. If the system releases the > file on Monday morning (Sunday night my time), it will be an annoyance. You're being very subjective here Rodolfo. Have in mind that not everyone translates during weekends. Even if you happen to lose a "Take" on a file, you can always Re-"Take" it. No big deal. This is a nice system that prevents "Take"s from being forgoten. We just need to be more careful when we "Take" a file. And, you can always make a slight change and commit just so the counter resets to zero. Regards From menthos at menthos.com Sun Jul 4 00:05:23 2004 From: menthos at menthos.com (Christian Rose) Date: Sun, 04 Jul 2004 02:05:23 +0200 Subject: Annoucement: New translation status page is installed In-Reply-To: <40D8D50F.8080505@redhat.com> References: <1087874101.17780.230.camel@sarah.brisbane.redhat.com> <200406221027.17982.rahal@arabeyes.org> <1087944558.4669.4086.camel@daim> <40D8D50F.8080505@redhat.com> Message-ID: <1088899522.7077.759.camel@stina.menthos.com> I realized I haven't answered this. As there was a comment about my supposed attitude towards new contributors, I probably should. ons 2004-06-23 klockan 02.55 skrev Bernd Groh: > >I'm also confused by the "Translator" field. For the anaconda sv.po, > >it's filled in with a name I've never heard of before. Even worse, this > >person's e-mail address is a Danish one, and the domain part is a very > >dirty word in Swedish... > > That would be the person who currently has anaconda assigned. Ok. > >Since 2000, I've been working from scratch on doing translations for Red > >Hat and now Fedora, with the goal of keeping them high quality and 100% > >for every release. We're currently two persons doing this work, and > >we've managed to do exactly this for a *lot* of releases by this time. > >We've recieved quite a lot of positive feedback about the quality, too. > > > >Thus it's not really exciting to see that any random bozo can suddenly > >take over control over a Swedish translation and fill in dirty words. > >I'm not amused. > > Do you want me to not give someone access because s/he's got a danish > email address and the domain name is a dirty word? Regardless of how > fluent this person may be in swedish, and how much this person would > like to participate? Do you know for a fact that this persons > translations are bad? If so, let me know, and I disable this persons access. Let me make some things clear: * I have nothing against Danish people, in fact, I live close to Denmark, I often visit Denmark, I regularily travel to GUADEC:s with the Danish contingent, and stay where they are staying, and enjoy beers and their company. Some of my best friends are Danish. That being said, when someone with a Danish mail address starts translating into Swedish, I raise an eyebrow. There can of course be many plausible explanations, but it's definately not what you'd expect at first. * Of course anyone is free to use a dirty word in their mail address. But when that dirty word is a Swedish one, the mail address is a Danish one, and the person is supposed to translate into Swedish, one can start to wonder if this guy is for real, and not just some bad joke someone felt like making when discovering a form field open for writing on a web page. * This is the first time I ever hear about this person. Swedish is not a big language, and free software translations for it is of course done by an even smaller community. I've been translating free software into Swedish for six years now, and am quite familiar with the few people that are working to do the same in other projects. Searching Google, I can find no references to a person with this name and mail address. Searching only for the name leaves me with quite a few hits, since the first name and last name are both common ones. But no match whatsoever has a connection to Linux or OSS/free software or translations. Given all of this, I find it hard to believe that this person is for real, and I find it quite insulting that you believe that this person would do a better job translating anaconda than me. Perhaps that's not what you really and honestly do believe, but then again your comment together with the fact that this person has taken the anaconda translation, and thus in fact is allowed to lock me out, would sure let one believe this. > I understand what you're saying, but I cannot at all agree with it in a > general sense. If you wish, I can make you the maintainer of every > swedish file, then you will even be notified if anyone commits a swedish > file. And while in a few languages it may be reasonable to not just give > anyone cvs access, in a lot it isn't, since there is noone who could > judge who should have access and who shouldn't. I personally prefer to > trust anyone to do the right thing by default, and if they don't, well, > let me know. As you've probably guessed, I, like most other maintainers, don't trust people to do the right by default. I want a mandatory intermediate step (review) to catch potential problems *before* they get committed. This is nothing really new, ask any software maintainer... It seems absurd that we are even arguing about this. Let me give an example of how I've learned the hard way not to trust people doing the right thing, even though it may not really be intentional at all. I don't believe people are automatically evil. I just believe people can make mistakes. Lots of free software use translation projects to organize translations. Some software maintainers think they can handle this organization perfectly well themselves though. Such an example is XMMS. I translated XMMS, but XMMS used to release not particularily often. I spend much time translating other projects aswell, and I don't always constantly monitor all the projects unless I know there's a release coming, and when of course it's then time to update. I had made the Swedish XMMS translation complete, sent it out for review by other translators several times, and incorporated the changes and suggestions. The result was a polished translation which I got several positive remarks for (which in case of a small language like Swedish is a lot). Suddenly one day there was a new version of XMMS that had been released. I wasn't aware that this release was coming. The XMMS developers had forgotten to inform translators. Worse, the Swedish translation had a lot of strange and sometimes amateurish translations in it. To make things worse, some people publically made fun of this, and as they knew I had been responsible for the Swedish XMMS translation in the past, pestered me about it. It turned out that some complete unknown guy had noticed that the Swedish translation of the development version wasn't complete at some time mid-cycle, completed it himself, and sent it to the software maintainers, who in the spirit of "ok, this looks more complete" committed it without asking any questions or informing anyone else, like perhaps me. Worse, it would take a whole year or so until they planned to do a new release, and this translation would be there for this whole time to make everyone either disgust it, or make fun of it. Certainly rather few people would enjoy it. This guy who completed the translation obviously wasn't at fault. He had good intentions, although his written language skills happened to be bad, and he just did whatever one would expect him to do and sent his work upstream. What was done wrong was at the software maintainer level -- since they didn't use a translation project structure with responsible teams and translators, but wanted to coordinate this themselves, they should have done exactly that. But they didn't, and just committed it. What scares me the most is that this is bound to happen again and again, not just with XMMS, but this time with the whole of Fedora, because the current structure by default allows anyone to commit whatever they want without even talking to anyone else first, before it's too late. A recipe for disaster. Christian From josep at imatge-sintetica.com Sun Jul 4 01:46:37 2004 From: josep at imatge-sintetica.com (Josep Puigdemont) Date: Sun, 04 Jul 2004 03:46:37 +0200 Subject: anaconda typo? Message-ID: <1088905596.1142.620.camel@phobos> Hi, translating anaconda.po, I found: #: ../iw/firewall_gui.py:143 msgid "" "Security Enhanced Linux (SELinux) provides finer-grained security controls " "than are available in a traditional Linux system. It can be set up in a " "disabled state, a state which only warns about things which would be denied, " "or a fully active state." I'm not a native english speaker, and thus not the best to mention this, but I think this sentence should read something like: "Security Enhanced Linux (SELinux) provides finer-grained security controls than _those_ available in a traditional Linux system." Regards, /Josep From s.mako at gmx.net Sun Jul 4 08:43:42 2004 From: s.mako at gmx.net (Zoltan Kota) Date: Sun, 4 Jul 2004 10:43:42 +0200 (CEST) Subject: Hungarian members In-Reply-To: <1088675143.4071.7.camel@sutty.mshome.net> Message-ID: On Thu, 1 Jul 2004, Sulyok Peti wrote: > > The Hungarian translation team is "led" by Tamas Szanto > > [tszanto at MOL.hu]...well he's the uy who did most of the translating. > > Can't exactly tell how many we are but any help is welcome :D > > > Could you tell me some more about that team, because I could not > establish connection to it when I started translating Fedora. > I would also join if I knew how. > > I guess we are at least 5 and could ask for a fedora-trans-hu list. Hi Peti, I don't know the past of the team. More important is the future. :-)) I suggest, let's go with the translations, let's go to communicate with each other and it will make the team. ;-) Zoli From menthos at menthos.com Sun Jul 4 10:19:37 2004 From: menthos at menthos.com (Christian Rose) Date: Sun, 04 Jul 2004 12:19:37 +0200 Subject: anaconda typo? In-Reply-To: <1088905596.1142.620.camel@phobos> References: <1088905596.1142.620.camel@phobos> Message-ID: <1088936377.7077.853.camel@stina.menthos.com> s?n 2004-07-04 klockan 03.46 skrev Josep Puigdemont: > translating anaconda.po, I found: I think it's usually good to report any message issues you may find in Bugzilla (https://bugzilla.redhat.com/bugzilla/). Then it won't get lost, since I doubt most anaconda developers are subscribed to this list. Cheers, Christian From menthos at menthos.com Sun Jul 4 12:21:07 2004 From: menthos at menthos.com (Christian Rose) Date: Sun, 04 Jul 2004 14:21:07 +0200 Subject: About the new Status Pages In-Reply-To: <40E3654E.7050807@redhat.com> References: <40E3654E.7050807@redhat.com> Message-ID: <1088943666.7077.907.camel@stina.menthos.com> Thanks Bernd for taking the time to write this explanatory letter. It definately helps having the points summarized. There is a lot in your mail that I think everyone agrees with, especially the good intentions. But I believe some of your arguments you're making for the policy you appearantly have already decided upon are very skewed and not based on reality. More on that below. tor 2004-07-01 klockan 03.13 skrev Bernd Groh: [ snip things about intentions that everyone agrees with ] > First new thing is that a module can be assigned to a Translator and > there is a [Take]/[Release] mechanism in place. What exactly is a > Translator in this respect? A Translator is a person translating a file > at a given time (thanks, Josep ). What's it for? Two things. First, so > other people know who's currently doing what, and second, to minimise > conflicts because two translators are working on the same file at the > same time. You say that wouldn't happen if you'd have a group and one > coordinator to coordinate all translations of the group? For a small > group that might be feasible, but if you have one coordinator and 70+ > translators, things can get quite difficult to manage this way. Also, we > would require the coordinator to be available at all time, we'd require > the coordinator to make a decision, or we'd require 70 people to > discuss about who's going to translate the file. Sometimes it is much > easier if, given the translator can do a good translation of the file, > whoever sees first that there is a file to be translated, that this > translator just does the job. Sometimes, there can be too much talking > about things, and it is, in fact, better to just do it. And there's > nothing that says that that's not how the group wants to do things. Not > all groups work in the same way. That might have an effect on > consistency? If the group has already agreed on a certain terminology, > and a person of that group simply does the job, without requiring too > much talking about it, how? As said, different groups work differently, > and I do not like the idea to build a system that is set to a certain > way, I rather build a system that can accommodate a large range of > behaviours of groups, or even of individuals. And yes, I am aware of the > disadvantages of this system, but IMO, groups should form because groups > want to form, and not because they have to form in order for the entire > system to work, groups should form in the way they want to form, and not > in one certain way, because that's the only way the system accommodates > for it. The first thing that struck me was the claim that there will be 70+ translators for any single language. Believe me, the largest language translation teams I know of aren't more than, say, a dozen to twenty people for any project. And then that's still an exceptionally huge team; almost all of them are much smaller, like one to five people. So giving an example of "70+ people" doesn't really look like it's even remotely connected to reality. It looks like the figure is intentionally blown out of proportion. Second, teams in practice usually annotate who is responsible for what themselves, sometimes only with a simple spoken agreement, sometimes with a list on a static web page, and sometimes even with more advanced systems, similar to the current Fedora status pages. It usually depends on the team's size and their structure what sort of method they want to use and feel comfortable with. Thus, there's really not an argument to be made that just because the current Fedora status pages implement this, it's automatically superior to what a team does for assignment (who's working on what) control, or even that there is a benefit for larger teams, because larger teams usually already have this in place. This is not new. The reason you got requests for this is probably because you haven't had a team policy in the past, so team agreement didn't always apply. That's fine, but don't make it sound like evidence of team agreement not working. Third, you make it sound like who's in charge of what usually changes every day. In fact, it's usually quite a static thing. When a person starts to translate a module, he usually keeps maintaining it, unless some unforeseen issue arises. Of course people do sometimes exchange modules, but that's almost always the exception. If you study teams empirically you'll find that almost all translators keep maintaining the same modules they've done previously. So requests for changing module maintainership is usually a rare thing. Fourth, you claim that all members of the team would fight for translating a new module, thus making the life of the coordinator difficult. This is almost never the case. It's difficult to get volunteers, and every volunteer can usually get all what they want in terms of getting their hands dirty without stepping on someone else's toes. The problem is almost always the opposite -- to get volunteers to work on a new module at all. Hence, the situation you describe with all members of a team fighting for a particular module isn't the common case at all. Fifth, you make it sound like saying "I will be working on this translation" in advance to the team would be as difficult as ending world hunger or something like that. Trust me, it really isn't. Most translators seem to be happy with and familiar enough to email communication to be able to send short mails in their native tounge for this to be a total non-issue. And, the assignments are almost always non-controversial, so there is rarely the big discussions you try to make a point of. Almost all this communication is a two-piece, really short one: "I will translate XYZ" and the reply "OK, noted". Again, you blow the issue out of proportion, and the argument doesn't seem to be based on reality. And last but not least, you fail to answer the question why you think translation is different enough from other forms of contributions, like software patches, where this anarchistic, no-prior-review-needed policy is definately not used. If you believe a mandated review and cooperation policy is bad for contributions, then why does every other form of significant contribution to a project require this? Given all of this, it sounds like you're making up arguments out of thin air to defend your policy, instead of arguments based on experience. I'm sorry to say that, but nevertheless that is the impression I get. Granted, you're willing to change minor details in how the translation system works according to feedback, but the most fundamental and pressing issue that almost all experienced translators complain about is the one you appearantly simply don't want to consider. Instead you make up fictive arguments to defend your stance, unwilling to take note of the massive complaints, or even the fact that one of the most wellknown volunteer translator groups have recently left the project because of this. I don't speak Arabic, but I know Arabeyes has been extremely efficient in producing close to complete translation coverage in virtually no time at all for almost all major open source software projects out there, and in having done so they are virtually one of a kind in translation experience, so what they have to say should at least be considered. The fact that they cite this flawed policy and the unwillingness to change it as the prime reason for leaving the Fedora project should at least ring a warning bell somewhere. Appearantly it doesn't, but you decide that the Fedora translation project should continue full steam ahead with an anarchistic policy that no other major translation project uses, unwilling to consider why this is the case, and a policy for which no good defensive arguments based on conditions in reality can be made. I would urge you to stop and reconsider before more teams lose their faith in the reasonability of mankind, and decide to leave the sinking ship. Christian From alan at redhat.com Sun Jul 4 13:05:51 2004 From: alan at redhat.com (Alan Cox) Date: Sun, 4 Jul 2004 09:05:51 -0400 Subject: anaconda typo? In-Reply-To: <1088905596.1142.620.camel@phobos> References: <1088905596.1142.620.camel@phobos> Message-ID: <20040704130550.GA23324@devserv.devel.redhat.com> On Sun, Jul 04, 2004 at 03:46:37AM +0200, Josep Puigdemont wrote: > I'm not a native english speaker, and thus not the best to mention this, > but I think this sentence should read something like: > > "Security Enhanced Linux (SELinux) provides finer-grained security > controls than _those_ available in a traditional Linux system." Correct. From alan at redhat.com Sun Jul 4 13:18:08 2004 From: alan at redhat.com (Alan Cox) Date: Sun, 4 Jul 2004 09:18:08 -0400 Subject: Annoucement: New translation status page is installed In-Reply-To: <1088899522.7077.759.camel@stina.menthos.com> References: <1087874101.17780.230.camel@sarah.brisbane.redhat.com> <200406221027.17982.rahal@arabeyes.org> <1087944558.4669.4086.camel@daim> <40D8D50F.8080505@redhat.com> <1088899522.7077.759.camel@stina.menthos.com> Message-ID: <20040704131808.GC23324@devserv.devel.redhat.com> On Sun, Jul 04, 2004 at 02:05:23AM +0200, Christian Rose wrote: > As you've probably guessed, I, like most other maintainers, don't trust > people to do the right by default. I want a mandatory intermediate step > (review) to catch potential problems *before* they get committed. This > is nothing really new, ask any software maintainer... It seems absurd > that we are even arguing about this. I'd agree with you for a lot of languages. When there is an established translation group anyone coming from outside even if they are a great linguist isn't going to be able to do the job well. There are too many "correct" ways to translate something to translate one file or even one project alone. For some languages this is really important because the culture cares rather a lot about such matters (Welsh is another such example). So I'd agree entirely with Christian's sentiment that where there is a *known* regular and active fedora translation project already accepted across the community of upstream packages (particularly desktop packages) then that appointed person should be doing the approval for translations and access to that translation. From dnielsen at breakmygentoo.net Mon Jul 5 08:24:28 2004 From: dnielsen at breakmygentoo.net (David Nielsen) Date: Mon, 05 Jul 2004 10:24:28 +0200 Subject: Danish translation team? Message-ID: <1089015868.3333.3.camel@localhost.localdomain> I've been lurking around the Fedora community for quite a while now, and after talking to Jesse Keating (Legacy) I was convinced to do my damnest to be helpful - so I'm offering my services to the translation team. Is there's a webpage around to help me get started translating the remains of the Fedora data pool? Regards David Nielsen From olganb at mail.ioffe.rssi.ru Mon Jul 5 06:10:39 2004 From: olganb at mail.ioffe.rssi.ru (Olga N. Budenkova) Date: Mon, 5 Jul 2004 10:10:39 +0400 Subject: RUSSIAN translators, please, answer me! In-Reply-To: <1088943666.7077.907.camel@stina.menthos.com> References: <40E3654E.7050807@redhat.com> <1088943666.7077.907.camel@stina.menthos.com> Message-ID: <502258515.20040705101039@mail.ioffe.rssi.ru> Hi all, I am awfully sorry, I was a little busy and out of this project, approximately from January (or it was December??). I see, that I missed a lot of interesting duscussions :). And some important modifications, too. I would like to get some information from/about RUSSIAN tranlsators, if there are any an to communicate with them. ? -- Best regards, Olga mailto:olganb at mail.ioffe.rssi.ru From andrewm at inventa.ru Mon Jul 5 15:03:23 2004 From: andrewm at inventa.ru (Andrew Martynov) Date: Mon, 05 Jul 2004 19:03:23 +0400 Subject: RUSSIAN translators, please, answer me! In-Reply-To: <502258515.20040705101039@mail.ioffe.rssi.ru> References: <40E3654E.7050807@redhat.com><1088943666.7077.907.camel@stina.menthos.com> <502258515.20040705101039@mail.ioffe.rssi.ru> Message-ID: <40E96DBB.4010304@inventa.ru> Hello, Olga! I`m a representative of Inventa translation team. Andrew Martynov Inventa http://www.rhd.ru Olga N. Budenkova wrote: > Hi all, > I am awfully sorry, I was a little busy and out of this project, > approximately from January (or it was December??). I see, that > I missed a lot of interesting duscussions :). And some important > modifications, too. > > I would like to get some information from/about RUSSIAN tranlsators, > if there are any an to communicate with them. > ? > > -- > Best regards, > Olga > mailto:olganb at mail.ioffe.rssi.ru > > > > -- > Fedora-trans-list mailing list > Fedora-trans-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-trans-list > From bgroh at redhat.com Mon Jul 5 23:23:51 2004 From: bgroh at redhat.com (Bernd Groh) Date: Tue, 06 Jul 2004 09:23:51 +1000 Subject: Auto-Release after 1 week enabled In-Reply-To: <1088733334.15420.217.camel@elrond.maxprograms.com> References: <40E4BB9D.5030605@redhat.com> <1088733334.15420.217.camel@elrond.maxprograms.com> Message-ID: <40E9E307.6070609@redhat.com> Hi Rodolfo, Rodolfo M. Raya schrieb: >On Thu, 2004-07-01 at 22:34, Bernd Groh wrote: > > >>Hi All, >> >>since people can forget to release a module after they've stopped >>working on it, we've implemented a mechanism that releases a module >>after one week (for now) of no commit automatically. We start to send >>out reminders after 3 days of no commit, and do an automatic release >>every Monday Morning 6ish GMT (starting this coming Monday). Of course, >>we can further discuss what a good time-frame is or whether that's a >>good system at all, but for now we've put it in place. >> >> > >Hi, > >Could you change the system to release the file one week after the file >was taken? > I'll put it up for discussion. >One week seems OK to me, but count since the file is taken. > >I usually translate on weekends and take a couple of days for reviewing, >this means I commit on Monday or Tuesday. If the system releases the >file on Monday morning (Sunday night my time), it will be an annoyance. > If you usually translate on the weekend, and take the file, let's say Friday or Saturday, then it won't be automatically released on Monday Morning, since you didn't have it for a week yet. It will only be released the Monday the week after. Your commit on Monday or Tuesday would let you keep it for another week though, given it's not finished. I simply wanted to release files of which I know people aren't really working on at the moment, that's why I've chosen commit, rather than take. But I'm happy to discuss it. Bernd > >My 0.02 >Rodolfo > > -- Dr. Bernd R. Groh Phone : +61 7 3514 8114 Software Engineer (Localization) Fax : +61 7 3514 8199 Red Hat Asia-Pacific Mobile: +61 403 851 269 Disclaimer: http://apac.redhat.com/disclaimer/ From rodolfo at heartsome.net Mon Jul 5 23:36:35 2004 From: rodolfo at heartsome.net (Rodolfo M. Raya) Date: Mon, 05 Jul 2004 20:36:35 -0300 Subject: Auto-Release after 1 week enabled In-Reply-To: <40E9E307.6070609@redhat.com> References: <40E4BB9D.5030605@redhat.com> <1088733334.15420.217.camel@elrond.maxprograms.com> <40E9E307.6070609@redhat.com> Message-ID: <1089070595.4676.233.camel@elrond.maxprograms.com> On Mon, 2004-07-05 at 20:23, Bernd Groh wrote: > Hi Rodolfo, Hi, > If you usually translate on the weekend, and take the file, let's say > Friday or Saturday, then it won't be automatically released on Monday > Morning, since you didn't have it for a week yet. It will only be > released the Monday the week after. OK. I understand now. I thought that the system would release the file 48 hours after I took it, instead of a week + 2 days. Thanks for clarifying. Regards, Rodolfo -- Rodolfo M. Raya Heartsome Holdings Pte. Ltd. From bgroh at redhat.com Tue Jul 6 05:03:55 2004 From: bgroh at redhat.com (Bernd Groh) Date: Tue, 06 Jul 2004 15:03:55 +1000 Subject: About the new Status Pages In-Reply-To: <1088943666.7077.907.camel@stina.menthos.com> References: <40E3654E.7050807@redhat.com> <1088943666.7077.907.camel@stina.menthos.com> Message-ID: <40EA32BB.9010901@redhat.com> Christian, Christian Rose schrieb: >Thanks Bernd for taking the time to write this explanatory letter. It >definately helps having the points summarized. > >There is a lot in your mail that I think everyone agrees with, >especially the good intentions. But I believe some of your arguments >you're making for the policy you appearantly have already decided upon >are very skewed and not based on reality. More on that below. > As said, and that's why I am a little surprised by your email, I am actually in favour of not just giving anyone cvs access for a certain language, if 1) the group wants it, and 2) somebody makes herself/himself accountable for such decision. If a language group wouldn't want to restrict cvs access to "newcomers", nobody of that language group would actually be willing to be accountable for such decision, or there isn't any language team in place yet, I do not see why I should not give someone of that language group cvs access. What is wrong with that model? If 1) the group wants it, and 2) somebody makes herself/himself accountable for such decision, I do agree completely that cvs access should be restricted, and the group should decide when/if it is time to give a "newcomer" cvs access. I've said the exactly same before, and I say it here again, just in case it wasn't entirely clear where I stand, though it should be. >tor 2004-07-01 klockan 03.13 skrev Bernd Groh: >[ snip things about intentions that everyone agrees with ] > > >>First new thing is that a module can be assigned to a Translator and >>there is a [Take]/[Release] mechanism in place. What exactly is a >>Translator in this respect? A Translator is a person translating a file >>at a given time (thanks, Josep ). What's it for? Two things. First, so >>other people know who's currently doing what, and second, to minimise >>conflicts because two translators are working on the same file at the >>same time. You say that wouldn't happen if you'd have a group and one >>coordinator to coordinate all translations of the group? For a small >>group that might be feasible, but if you have one coordinator and 70+ >>translators, things can get quite difficult to manage this way. Also, we >>would require the coordinator to be available at all time, we'd require >>the coordinator to make a decision, or we'd require 70 people to >>discuss about who's going to translate the file. Sometimes it is much >>easier if, given the translator can do a good translation of the file, >>whoever sees first that there is a file to be translated, that this >>translator just does the job. Sometimes, there can be too much talking >>about things, and it is, in fact, better to just do it. And there's >>nothing that says that that's not how the group wants to do things. Not >>all groups work in the same way. That might have an effect on >>consistency? If the group has already agreed on a certain terminology, >>and a person of that group simply does the job, without requiring too >>much talking about it, how? As said, different groups work differently, >>and I do not like the idea to build a system that is set to a certain >>way, I rather build a system that can accommodate a large range of >>behaviours of groups, or even of individuals. And yes, I am aware of the >>disadvantages of this system, but IMO, groups should form because groups >>want to form, and not because they have to form in order for the entire >>system to work, groups should form in the way they want to form, and not >>in one certain way, because that's the only way the system accommodates >>for it. >> >> > >The first thing that struck me was the claim that there will be 70+ >translators for any single language. Believe me, the largest language >translation teams I know of aren't more than, say, a dozen to twenty >people for any project. > I can only go by how many people sign up to be a translator for a certain language, and we have language groups with well above 70 translators. > And then that's still an exceptionally huge >team; almost all of them are much smaller, like one to five people. So >giving an example of "70+ people" doesn't really look like it's even >remotely connected to reality. It looks like the figure is intentionally >blown out of proportion. > Well, it's not, and it certainly shouldn't look that way. My apologies if it appeared as if I'd intentionally blow things out of proportion, I simply did a count. >Second, teams in practice usually annotate who is responsible for what >themselves, sometimes only with a simple spoken agreement, sometimes >with a list on a static web page, and sometimes even with more advanced >systems, similar to the current Fedora status pages. It usually depends >on the team's size and their structure what sort of method they want to >use and feel comfortable with. > True. >Thus, there's really not an argument to be made that just because the >current Fedora status pages implement this, it's automatically superior >to what a team does for assignment (who's working on what) control, or > Christian, please, you know as well as I, that I never called any system to be superior to another, neither I made an argument for it, I simply said that there are different ways of doing things. >even that there is a benefit for larger teams, because larger teams >usually already have this in place. This is not new. The reason you got >requests for this is probably because you haven't had a team policy in >the past, so team agreement didn't always apply. That's fine, but don't >make it sound like evidence of team agreement not working. > Neither I said there is a benefit for larger teams, I simply said there could be, depending on how the team handles things. And yes, the reason for the requests might as well be because there wasn't a team policy in the past, however, even if, I cannot change the past, all I can do is to try and better things from how they are now. >Third, you make it sound like who's in charge of what usually changes >every day. > How? By introducing a Maintainer and stating that a maintainer should be a "permanent" entity? > In fact, it's usually quite a static thing. When a person >starts to translate a module, he usually keeps maintaining it, unless >some unforeseen issue arises. Of course people do sometimes exchange >modules, but that's almost always the exception. If you study teams >empirically you'll find that almost all translators keep maintaining the >same modules they've done previously. So requests for changing module >maintainership is usually a rare thing. > That's how it should be, and that's why I've said a Maintainer should be something "permanent". However, in our current reality, we do have to deal with more than one person working on one and the same module at the same time. Simply saying that it shouldn't be that way doesn't make it go away. Saying that it's because there aren't any teams and we shouldn't have done a, b, and c in the past, doesn't make it go away either. As said, I cannot change the past, all I can do is to try and better things from how they are now. All we did was adding visibility to what's going on, what was so wrong about that? >Fourth, you claim that all members of the team would fight for >translating a new module, thus making the life of the coordinator >difficult. > No, I don't. I can kind of see how you could get there, given I've said: "or we'd require 70 people to discuss about who's going to translate the file", but with this, I did not intend to say that members of a team would actually fight for translations, neither I was making any kind of claim, I simply meant to illustrate the responsibility a coordinator has, and the difficulties s/he could, in addition, face in a large team. All that was part of me making the point that, even though we'd like to have coordinators for every team, we'd like such role to be entirely voluntary, and not mandatory in order for the entire system to work. That's all. Again, I didn't mean to say the coordinator model doesn't work, neither that our model is better, not even that we do not want to have coordinators, all I meant is that I do not wish to build a system that is dependent on a coordinator or a team of a certain structure being in place, but supports it iff that should be the case. > This is almost never the case. It's difficult to get >volunteers, and every volunteer can usually get all what they want in >terms of getting their hands dirty without stepping on someone else's >toes. > I'd say this depends on the language and the people involved in that particular language, in general, I'd tend to agree with you, though. > The problem is almost always the opposite -- to get volunteers to >work on a new module at all. Hence, the situation you describe with all >members of a team fighting for a particular module isn't the common case >at all. > Christian, in fact, I do agree with you that it is hard to get good people taking on certain responsibilities, and this isn't just limited to translations, but even more so to maintaining modules and coordinating a language, or would you now disagree? Do you believe it is hard to get people working on a module, but actually easy to find maintainers, or even coordinators? I actually do agree with you, that, in general, it is hard to find either, and that exactly is why I don't want to build a system that is dependent on it. Why would you build a system that is dependent on something that, apparently, is hard to find? Why not simply support it if a given structure is in place or forms naturally, and voluntarily? Maybe it is just my opinion, but if nobody wants to be the coordinator of an entire language, I don't think the language should have one, though I'd hope it would be the case. Maybe I am wrong, but that's simply how I see things. >Fifth, you make it sound like saying "I will be working on this >translation" in advance to the team would be as difficult as ending >world hunger or something like that. > And you're telling me I blow things out of proportion? > Trust me, it really isn't. Most >translators seem to be happy with and familiar enough to email >communication to be able to send short mails in their native tounge for >this to be a total non-issue. And, the assignments are almost always > We do have quite active mailing lists for some languages, and yes, with 70+ subscribers (just to stick with that number, I could easily blow it even more out of proportion), and I doubt communicating via email in large and active mailing lists is an ideal situation. Again, I don't say it can't be done this way, neither I say our way is superior, I simply say that I prefer our way for mere reasons of scalability. That may as well be a non-issue, but not one I'd like to count on. >non-controversial, so there is rarely the big discussions you try to >make a point of. Almost all this communication is a two-piece, really >short one: "I will translate XYZ" and the reply "OK, noted". Again, you >blow the issue out of proportion, and the argument doesn't seem to be >based on reality. > In my experience, it's a short email "I will translate abc", "I will translate bcd", no "Noted" then replies "is anyone translating def"? or "who is translating bgr", maybe "I have translated xrt", then "sorry, xrt is finished now", maybe "what is available?", "what can I translate?", and just scale that out a bit now, and make a good argument of why I should use email communication to manage who's doing what? You say this is not based on reality? Sorry, but this is the reality I am facing. Yes, true, assignment is most of the time non-controversial, and if you read what I wrote, you'll see that I never said otherwise. Given everyone knows what everyone else is doing, why translate what someone else is translating already? But, if I don't know, I don't know, and an email is easily missed too, especially if you get many. Of course, that is all blown out of proportion and not based on reality, right? Or is your reality the only reality and every other "reality" is just made up and blown out of proportion? >And last but not least, you fail to answer the question why you think >translation is different enough from other forms of contributions, like >software patches, where this anarchistic, no-prior-review-needed policy >is definately not used. If you believe a mandated review and cooperation >policy is bad for contributions, then why does every other form of >significant contribution to a project require this? > Well, naturally, the most important thing is that the system is stable and works properly, and not reviewing software patches couldn't ensure that. Of course, it is most important that the systems works, and be it only in english. Or would you rather have a swedish system that crashes regularly, than an english one that works properly? I am not the only one who would agree that the software working properly is more important than the translation being perfect, or do you really want to say that this isn't so in reality? Now, I don't really believe a mandated review and cooperation policy is bad for contributions, I merely think that nobody should have to be a maintainer or coordinator for a language if nobody really wants to. I do think that review and coorporation is good, I simply don't think anyone should be made to do it. >Given all of this, it sounds like you're making up arguments out of thin >air to defend your policy, instead of arguments based on experience. I'm >sorry to say that, but nevertheless that is the impression I get. > Well, maybe you simply got the wrong impression, but I don't know why? :( I've made it clear where we want to head to, but it seems like you're still more concerned with what we've done before. But as said, I cannot change the past. We haven't changed or introduced any new policy, we've simply added a layer of visibility to how things are. I still fail to see what was so incredibly bad about this step, and that is a question you haven't answered yet. >Granted, you're willing to change minor details in how the translation >system works according to feedback, but the most fundamental and >pressing issue that almost all experienced translators complain about is >the one you appearantly simply don't want to consider. > First, how can I know that almost all experienced translators complain? It was only a handful of people who said anything on this list. If people don't speak up on this list, what am I supposed to do? Secondly, what fundamental issue am I not willing to consider? > Instead you make up fictive arguments to defend your stance, unwilling to take note of >the massive complaints, or even the fact that one of the most wellknown >volunteer translator groups have recently left the project because of >this. > First, it was the same handful of people who complained, and given the number of subscriptions, I can hardly call it massive. Secondly, I still don't know what stance you are talking about? What exactly is that stance of mine that is so massively criticised? All I did was adding a layer of visibility to our current system, and I still think it was an improvement to how things were. On a side note, the translator group you are referring to had their very own reasons for leaving. But, since we're at it, what am I supposed to do? Let's say, you, and you alone, take on all swedish modules. You do a good job, but now I have 11 translators signed up, of 2 I don't hear anything and the 8 others are complaining about you? Do you want me to just go, yes, he did all of the translations so far, and everyone else should just deal with it? What kind of policy is that? Yes, this is an exaggeration, simply to illustrate the problem of where to draw the line. Out of the arabic language group I had more people not in support of that group taking over maintainership than I had in favour. Tell me, what am I supposed to do? IMO, it is not up to me to make policy, the individuals of that language group should just come up with a solution by themselves, I cannot possibly be the judge, especially not given I don't speak the language. >[snip] Appearantly it doesn't, but you decide that the Fedora translation >project should continue full steam ahead with an anarchistic policy that >no other major translation project uses, unwilling to consider why this >is the case, and a policy for which no good defensive arguments based on >conditions in reality can be made. > What exactly are you talking about? Are you sure you didn't simply misunderstand the situation? >I would urge you to stop and reconsider before more teams lose their >faith in the reasonability of mankind, and decide to leave the sinking >ship. > Christian, I don't know what to say? I do listen to what the community is saying, and I do consider everything coming to my eyes or ears, the only problem I have is that I haven't got unlimited ressources. I don't know why you'd think otherwise, but as it seems, there is nothing I can do about it, and that's a shame. Regards, Bernd >Christian > > >-- >Fedora-trans-list mailing list >Fedora-trans-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-trans-list > > -- Dr. Bernd R. Groh Phone : +61 7 3514 8114 Software Engineer (Localization) Fax : +61 7 3514 8199 Red Hat Asia-Pacific Mobile: +61 403 851 269 Disclaimer: http://apac.redhat.com/disclaimer/ From bgroh at redhat.com Tue Jul 6 07:51:17 2004 From: bgroh at redhat.com (Bernd Groh) Date: Tue, 06 Jul 2004 17:51:17 +1000 Subject: Annoucement: New translation status page is installed In-Reply-To: <1088899522.7077.759.camel@stina.menthos.com> References: <1087874101.17780.230.camel@sarah.brisbane.redhat.com> <200406221027.17982.rahal@arabeyes.org> <1087944558.4669.4086.camel@daim> <40D8D50F.8080505@redhat.com> <1088899522.7077.759.camel@stina.menthos.com> Message-ID: <40EA59F5.5060400@redhat.com> Christian, just so you don't think I'd intentionally not answer this response of yours, to avoid an issue or for whatever reason. Christian Rose schrieb: >I realized I haven't answered this. As there was a comment about my >supposed attitude towards new contributors, I probably should. > >ons 2004-06-23 klockan 02.55 skrev Bernd Groh: > > >>>I'm also confused by the "Translator" field. For the anaconda sv.po, >>>it's filled in with a name I've never heard of before. Even worse, this >>>person's e-mail address is a Danish one, and the domain part is a very >>>dirty word in Swedish... >>> >>> >>That would be the person who currently has anaconda assigned. >> >> > >Ok. > > > > >>>Since 2000, I've been working from scratch on doing translations for Red >>>Hat and now Fedora, with the goal of keeping them high quality and 100% >>>for every release. We're currently two persons doing this work, and >>>we've managed to do exactly this for a *lot* of releases by this time. >>>We've recieved quite a lot of positive feedback about the quality, too. >>> >>>Thus it's not really exciting to see that any random bozo can suddenly >>>take over control over a Swedish translation and fill in dirty words. >>>I'm not amused. >>> >>> >>Do you want me to not give someone access because s/he's got a danish >>email address and the domain name is a dirty word? Regardless of how >>fluent this person may be in swedish, and how much this person would >>like to participate? Do you know for a fact that this persons >>translations are bad? If so, let me know, and I disable this persons access. >> >> > >Let me make some things clear: > >* I have nothing against Danish people, in fact, I live close to >Denmark, I often visit Denmark, I regularily travel to GUADEC:s with the >Danish contingent, and stay where they are staying, and enjoy beers and >their company. Some of my best friends are Danish. >That being said, when someone with a Danish mail address starts >translating into Swedish, I raise an eyebrow. There can of course be >many plausible explanations, but it's definately not what you'd expect >at first. > >* Of course anyone is free to use a dirty word in their mail address. >But when that dirty word is a Swedish one, the mail address is a Danish >one, and the person is supposed to translate into Swedish, one can start >to wonder if this guy is for real, and not just some bad joke someone >felt like making when discovering a form field open for writing on a web >page. > >* This is the first time I ever hear about this person. Swedish is not a >big language, and free software translations for it is of course done by >an even smaller community. I've been translating free software into >Swedish for six years now, and am quite familiar with the few people >that are working to do the same in other projects. >Searching Google, I can find no references to a person with this name >and mail address. Searching only for the name leaves me with quite a few >hits, since the first name and last name are both common ones. But no >match whatsoever has a connection to Linux or OSS/free software or >translations. > >Given all of this, I find it hard to believe that this person is for >real, and I find it quite insulting that you believe that this person >would do a better job translating anaconda than me. Perhaps that's not >what you really and honestly do believe, but then again your comment >together with the fact that this person has taken the anaconda >translation, and thus in fact is allowed to lock me out, would sure let >one believe this. > Maybe the fact that I've offered you the maintainership of all swedish modules, twice even, and now for the third time, since it's still yours for the taking if you want it, which would put you into the position to release the module from that person and take it yourself, or let someone else take it, should, IMO, not make you believe this. Or have you seen me offering the maintainership of the swedish modules to anyone you've never heard of? And no, I do not believe that this person would do a better job translating anaconda than you, fact is, I do not speak swedish and I cannot and will not make judgement. I know through third-party feedback that you've done an extremely good job keeping the swedish translations up to date and to a good quality in the past, and that exactly is why I've offered you the maintainership of the swedish modules, and we all would be happy if you'd do it. My statement didn't intend to say that the person who took anaconda has a right to look you out, I simply meant to say that you're invited to become a maintainer and release that person yourself, since I don't think it's my job to decide on who's allowed to do swedish translations and who isn't. I believe swedish speaking people should do that. I'm sorry if it felt like an insult to you, it wasn't meant to be one. >>I understand what you're saying, but I cannot at all agree with it in a >>general sense. If you wish, I can make you the maintainer of every >>swedish file, then you will even be notified if anyone commits a swedish >>file. And while in a few languages it may be reasonable to not just give >>anyone cvs access, in a lot it isn't, since there is noone who could >>judge who should have access and who shouldn't. I personally prefer to >>trust anyone to do the right thing by default, and if they don't, well, >>let me know. >> >> > >As you've probably guessed, I, like most other maintainers, don't trust >people to do the right by default. I want a mandatory intermediate step >(review) to catch potential problems *before* they get committed. This >is nothing really new, ask any software maintainer... It seems absurd >that we are even arguing about this. > As said, if there is a coordinator willing to make herself/himself accountable for this decision and the language group, in general, is in favour of that, I completely agree. If the language group prefers to have cvs access open, or there isn't an established group, I do not believe an intermediate step to be feasible. Who'd be to judge when cvs access should be granted? Now, I believe you are referring to the case where there is a coordinator willing to be accountable and the group being in favour of restricting access, right? If this is the case, I do agree with you, and I don't argue that point. If no, and your argument is a general one, then who should judge when cvs access is to be granted if there is nobody or nobody who wants to be responsible for such decision? Who is going to make such decision? >Let me give an example of how I've learned the hard way not to trust >people doing the right thing, even though it may not really be >intentional at all. I don't believe people are automatically evil. I >just believe people can make mistakes. > >Lots of free software use translation projects to organize translations. >Some software maintainers think they can handle this organization >perfectly well themselves though. Such an example is XMMS. I translated >XMMS, but XMMS used to release not particularily often. I spend much >time translating other projects aswell, and I don't always constantly >monitor all the projects unless I know there's a release coming, and >when of course it's then time to update. > >I had made the Swedish XMMS translation complete, sent it out for review >by other translators several times, and incorporated the changes and >suggestions. The result was a polished translation which I got several >positive remarks for (which in case of a small language like Swedish is >a lot). > >Suddenly one day there was a new version of XMMS that had been released. >I wasn't aware that this release was coming. The XMMS developers had >forgotten to inform translators. Worse, the Swedish translation had a >lot of strange and sometimes amateurish translations in it. To make >things worse, some people publically made fun of this, and as they knew >I had been responsible for the Swedish XMMS translation in the past, >pestered me about it. > >It turned out that some complete unknown guy had noticed that the >Swedish translation of the development version wasn't complete at some >time mid-cycle, completed it himself, and sent it to the software >maintainers, who in the spirit of "ok, this looks more complete" >committed it without asking any questions or informing anyone else, like >perhaps me. Worse, it would take a whole year or so until they planned >to do a new release, and this translation would be there for this whole >time to make everyone either disgust it, or make fun of it. Certainly >rather few people would enjoy it. > >This guy who completed the translation obviously wasn't at fault. He had >good intentions, although his written language skills happened to be >bad, and he just did whatever one would expect him to do and sent his >work upstream. >What was done wrong was at the software maintainer level -- since they >didn't use a translation project structure with responsible teams and >translators, but wanted to coordinate this themselves, they should have >done exactly that. But they didn't, and just committed it. > > >What scares me the most is that this is bound to happen again and again, >not just with XMMS, but this time with the whole of Fedora, because the >current structure by default allows anyone to commit whatever they want >without even talking to anyone else first, before it's too late. A >recipe for disaster. > In the new system, only if there is nobody maintaining the file. If there is a maintainer for a module, the maintainer is informed when someone takes the module, when someone does a commit. Even more, when the file is finished, the maintainer has to approve the module before others can take it again and commit changes to it. What is the major drama about having the changes in the cvs? If the translation is no good, you can always roll back. I prefer to have the changes in cvs, at least then everyone can have a look at the most recent changes without having to talk to the person who has the po-file in her/his inbox. A commit is not a final thing, it can easily be undone. Or do you always make sure that your most recent software changes work before you commit them? How do you do that with a larger addition? Do you wait till it's finished and not keep track of changes for days, but commit a whole bunch of changes at once? I prefer to commit whenever I do a minor change, or constantly commit even if I do a major change, even if things aren't working yet. And if I really should commit something that wasn't good, I simply get the previous version and keep working on that. Why would that be so wrong in our case? Or did I misunderstand what you were saying? Now, why is the new system compared to the previous system an even bigger recipe for disaster? Doesn't it actually help avoiding the problems you were just talking about? Regards, Bernd >Christian > > >-- >Fedora-trans-list mailing list >Fedora-trans-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-trans-list > > -- Dr. Bernd R. Groh Phone : +61 7 3514 8114 Software Engineer (Localization) Fax : +61 7 3514 8199 Red Hat Asia-Pacific Mobile: +61 403 851 269 Disclaimer: http://apac.redhat.com/disclaimer/ From pmmm at rnl.ist.utl.pt Tue Jul 6 09:56:21 2004 From: pmmm at rnl.ist.utl.pt (Pedro Morais) Date: Tue, 6 Jul 2004 10:56:21 +0100 Subject: Annoucement: New translation status page is installed In-Reply-To: <40EA59F5.5060400@redhat.com> References: <1087874101.17780.230.camel@sarah.brisbane.redhat.com> <1088899522.7077.759.camel@stina.menthos.com> <40EA59F5.5060400@redhat.com> Message-ID: <200407061056.21489.pmmm@rnl.ist.utl.pt> Em Ter?a, 6 de Julho de 2004 08:51, Bernd Groh escreveu: > If there is a maintainer for a module, the maintainer is informed when > someone takes the module, when someone does a commit. Even more, when > the file is finished, the maintainer has to approve the module before > others can take it again and commit changes to it. A small bug I forgot to mention (maybe it's solved by now): I'm the maintainer of pt (European) and I'm informed about and must aprove my own commits, I don't think in this case this step is necessary. Also, maybe the quality step mail should mention who was the translator involved? Pedro Morais From sarahs at redhat.com Tue Jul 6 10:16:30 2004 From: sarahs at redhat.com (Sarah Wang) Date: Tue, 06 Jul 2004 20:16:30 +1000 Subject: FC3 Translation key dates Message-ID: <1089108990.2253.45.camel@cpe-144-136-138-33.qld.bigpond.net.au> Hi all, The preliminary FC3 schedule is out and available at: http://fedora.redhat.com/participate/schedule/ I'd like to draw your attention to the following dates relating to translation: 25/Aug: String change deadline (in theory, no string change will occur after this date); 6/Sep: String built freeze (the absolute string freeze date); 16/Sep: Translation deadline (in theory, all translation should be completed by this date); 27/Sep: Translation built freeze (the absolute translation freeze date) The above dates may be changed, please watch the schedule page for most up to date information. Regards, Sarah From alan at redhat.com Tue Jul 6 15:28:09 2004 From: alan at redhat.com (Alan Cox) Date: Tue, 6 Jul 2004 11:28:09 -0400 Subject: About the new Status Pages In-Reply-To: <40EA32BB.9010901@redhat.com> References: <40E3654E.7050807@redhat.com> <1088943666.7077.907.camel@stina.menthos.com> <40EA32BB.9010901@redhat.com> Message-ID: <20040706152809.GD11736@devserv.devel.redhat.com> On Tue, Jul 06, 2004 at 03:03:55PM +1000, Bernd Groh wrote: > that cvs access should be restricted, and the group should decide > when/if it is time to give a "newcomer" cvs access. I've said the Cool. On behalf of the Welsh group please don't add sign any newcomers up without checking with me or Dafydd Harries . Point them at http://parnassus.ath.cx/~daf/gnome-cy Thanks From katzj at redhat.com Tue Jul 6 15:28:01 2004 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 06 Jul 2004 11:28:01 -0400 Subject: anaconda typo? In-Reply-To: <1088936377.7077.853.camel@stina.menthos.com> References: <1088905596.1142.620.camel@phobos> <1088936377.7077.853.camel@stina.menthos.com> Message-ID: <1089127681.22067.43.camel@bree.local.net> On Sun, 2004-07-04 at 12:19 +0200, Christian Rose wrote: > s?n 2004-07-04 klockan 03.46 skrev Josep Puigdemont: > > translating anaconda.po, I found: > > I think it's usually good to report any message issues you may find in > Bugzilla (https://bugzilla.redhat.com/bugzilla/). Then it won't get > lost, since I doubt most anaconda developers are subscribed to this > list. Even though I am subscribed to the list, if it doesn't end up in bugzilla, the chances of me losing track of it are extremely high (read: almost guaranteed). It's much harder for me to "lose" a bug :) Jeremy From katzj at redhat.com Tue Jul 6 15:42:11 2004 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 06 Jul 2004 11:42:11 -0400 Subject: Annoucement: New translation status page is installed In-Reply-To: <40EA59F5.5060400@redhat.com> References: <1087874101.17780.230.camel@sarah.brisbane.redhat.com> <200406221027.17982.rahal@arabeyes.org> <1087944558.4669.4086.camel@daim> <40D8D50F.8080505@redhat.com> <1088899522.7077.759.camel@stina.menthos.com> <40EA59F5.5060400@redhat.com> Message-ID: <1089128531.22067.53.camel@bree.local.net> On Tue, 2004-07-06 at 17:51 +1000, Bernd Groh wrote: > What is the major drama about having the changes in the cvs? If the > translation is no good, you can always roll back. I prefer to have the > changes in cvs, at least then everyone can have a look at the most recent > changes without having to talk to the person who has the po-file in > her/his inbox. A commit is not a final thing, it can easily be undone. That depends on when the commit is done. If the commit is done shortly before a freeze of some sort, there's a good chance that it _can't_ be easily undone. It first requires getting the maintainer of the module to respin when they thought they were already done. A lot of the QA which has been done at that point then also needs to be at least checked to see if it needs to be reverified or not. And if it's not noticed for a day or two (for whatever reason, that's not unreasonable) and you then hit the point at which the tree is frozen, then getting it changed is that much more difficult. > Or do you always > make sure that your most recent software changes work before you commit > them? How do you do that with a larger addition? Do you wait till it's > finished and not keep track of changes for days, but commit a whole > bunch of changes at once? The goal has to be to keep CVS working at all times. Otherwise, you kill testing. So yes, I tend to try to make sure that either a) my new stuff works or b) at least doesn't break anything new (perhaps the new functionality doesn't work, but old things should continue doing so). This is even more the case with translations since the code maintainers of a module aren't going to know/keep up with the status of the translations and so need them to be as "correct" as possible at all times since there's no controlling when they're going to do a build. Jeremy From bgroh at redhat.com Tue Jul 6 23:05:56 2004 From: bgroh at redhat.com (Bernd Groh) Date: Wed, 07 Jul 2004 09:05:56 +1000 Subject: Annoucement: New translation status page is installed In-Reply-To: <200407061056.21489.pmmm@rnl.ist.utl.pt> References: <1087874101.17780.230.camel@sarah.brisbane.redhat.com> <1088899522.7077.759.camel@stina.menthos.com> <40EA59F5.5060400@redhat.com> <200407061056.21489.pmmm@rnl.ist.utl.pt> Message-ID: <40EB3054.5010905@redhat.com> Hi Pedro, Pedro Morais schrieb: >Em Ter?a, 6 de Julho de 2004 08:51, Bernd Groh escreveu: > > >>If there is a maintainer for a module, the maintainer is informed when >>someone takes the module, when someone does a commit. Even more, when >>the file is finished, the maintainer has to approve the module before >>others can take it again and commit changes to it. >> >> > >A small bug I forgot to mention (maybe it's solved by now): >I'm the maintainer of pt (European) and I'm informed about and must aprove my >own commits, I don't think in this case this step is necessary. > You're right, if that's the case, it's a bug. I'll look into it, as soon as I get around to it. >Also, maybe the quality step mail should mention who was the translator >involved? > Agreed. Maybe the translator should be left in place even? Maybe even still have the right to make changes, even though the module is in QA? Would that be desireable? Or rather not? Regards, Bernd > > Pedro Morais > > >-- >Fedora-trans-list mailing list >Fedora-trans-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-trans-list > > -- Dr. Bernd R. Groh Phone : +61 7 3514 8114 Software Engineer (Localization) Fax : +61 7 3514 8199 Red Hat Asia-Pacific Mobile: +61 403 851 269 Disclaimer: http://apac.redhat.com/disclaimer/ From bgroh at redhat.com Tue Jul 6 23:34:25 2004 From: bgroh at redhat.com (Bernd Groh) Date: Wed, 07 Jul 2004 09:34:25 +1000 Subject: About the new Status Pages In-Reply-To: <20040706152809.GD11736@devserv.devel.redhat.com> References: <40E3654E.7050807@redhat.com> <1088943666.7077.907.camel@stina.menthos.com> <40EA32BB.9010901@redhat.com> <20040706152809.GD11736@devserv.devel.redhat.com> Message-ID: <40EB3701.7090006@redhat.com> Alan, I said that's what I'd like to see and that I do agree with it, I didn't say it's what's currently done. It's what I'd do if I had a say. But I believe I need to first get some more visibility into who the teams really are, before I really push for it. Another reason why I need to put up team pages, and I'm planning on doing it as soon as I get some time. However, I won't keep any "official" from acting on it anyway. :) Cheers, Bernd Alan Cox schrieb: >On Tue, Jul 06, 2004 at 03:03:55PM +1000, Bernd Groh wrote: > > >>that cvs access should be restricted, and the group should decide >>when/if it is time to give a "newcomer" cvs access. I've said the >> >> > >Cool. > >On behalf of the Welsh group please don't add sign any newcomers up without >checking with me or Dafydd Harries . Point them >at > http://parnassus.ath.cx/~daf/gnome-cy > > >Thanks > > >-- >Fedora-trans-list mailing list >Fedora-trans-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-trans-list > > -- Dr. Bernd R. Groh Phone : +61 7 3514 8114 Software Engineer (Localization) Fax : +61 7 3514 8199 Red Hat Asia-Pacific Mobile: +61 403 851 269 Disclaimer: http://apac.redhat.com/disclaimer/ From bgroh at redhat.com Wed Jul 7 00:10:28 2004 From: bgroh at redhat.com (Bernd Groh) Date: Wed, 07 Jul 2004 10:10:28 +1000 Subject: Annoucement: New translation status page is installed In-Reply-To: <1089128531.22067.53.camel@bree.local.net> References: <1087874101.17780.230.camel@sarah.brisbane.redhat.com> <200406221027.17982.rahal@arabeyes.org> <1087944558.4669.4086.camel@daim> <40D8D50F.8080505@redhat.com> <1088899522.7077.759.camel@stina.menthos.com> <40EA59F5.5060400@redhat.com> <1089128531.22067.53.camel@bree.local.net> Message-ID: <40EB3F74.3010107@redhat.com> Jeremy, Jeremy Katz schrieb: >On Tue, 2004-07-06 at 17:51 +1000, Bernd Groh wrote: > > >>What is the major drama about having the changes in the cvs? If the >>translation is no good, you can always roll back. I prefer to have the >>changes in cvs, at least then everyone can have a look at the most recent >>changes without having to talk to the person who has the po-file in >>her/his inbox. A commit is not a final thing, it can easily be undone. >> >> > >That depends on when the commit is done. If the commit is done shortly >before a freeze of some sort, there's a good chance that it _can't_ be >easily undone. It first requires getting the maintainer of the module >to respin when they thought they were already done. A lot of the QA >which has been done at that point then also needs to be at least checked >to see if it needs to be reverified or not. And if it's not noticed for >a day or two (for whatever reason, that's not unreasonable) and you then >hit the point at which the tree is frozen, then getting it changed is >that much more difficult. > Well taken. And I don't really have anything against QAing before a file is commited, iff there is a maintainer who is happy to QA it. If the maintainer just doesn't have the time, given it's all voluntary after all, and good translations are simply sitting in an inbox, rather than getting into the packages, than that's a situation I'd like to avoid. Or is it really the case that most committed translations are bad? >> Or do you always >>make sure that your most recent software changes work before you commit >>them? How do you do that with a larger addition? Do you wait till it's >>finished and not keep track of changes for days, but commit a whole >>bunch of changes at once? >> >> > >The goal has to be to keep CVS working at all times. Otherwise, you >kill testing. So yes, I tend to try to make sure that either a) my new >stuff works or b) at least doesn't break anything new (perhaps the new >functionality doesn't work, but old things should continue doing so). > For the case that my additions can break stuff that's tested, of course I do that too. For my own projects, I usually make sure that all my release branches are working at all time, but I am not that strict with HEAD, since I don't deploy HEAD. >This is even more the case with translations since the code maintainers >of a module aren't going to know/keep up with the status of the >translations and so need them to be as "correct" as possible at all >times since there's no controlling when they're going to do a build. > Do not disagree in the least. But why should commited translations by default be incorrect? And in particular, why should they now be more incorrect than before? Now at least a maintainer has the chance to see who is working on a module. Cheers, Bernd >Jeremy > > > > >-- >Fedora-trans-list mailing list >Fedora-trans-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-trans-list > > -- Dr. Bernd R. Groh Phone : +61 7 3514 8114 Software Engineer (Localization) Fax : +61 7 3514 8199 Red Hat Asia-Pacific Mobile: +61 403 851 269 Disclaimer: http://apac.redhat.com/disclaimer/ From pmmm at rnl.ist.utl.pt Wed Jul 7 02:20:02 2004 From: pmmm at rnl.ist.utl.pt (Pedro Morais) Date: Wed, 7 Jul 2004 03:20:02 +0100 Subject: Annoucement: New translation status page is installed In-Reply-To: <40EB3054.5010905@redhat.com> References: <1087874101.17780.230.camel@sarah.brisbane.redhat.com> <200407061056.21489.pmmm@rnl.ist.utl.pt> <40EB3054.5010905@redhat.com> Message-ID: <200407070320.02515.pmmm@rnl.ist.utl.pt> Em Quarta, 7 de Julho de 2004 00:05, Bernd Groh escreveu: > >Also, maybe the quality step mail should mention who was the translator > >involved? > > Agreed. Maybe the translator should be left in place even? Maybe even > still have the right to make changes, even though the module is in QA? > Would that be desireable? Or rather not? What I found weird was that after I had commited changes I received the mail saying that, and I thought, who commited that? If it said that ir was "morais" I would have noticed "uhm, it's the stuff I commited". -- Pedro Morais - morais at kde.org - http://www.rnl.ist.utl.pt/~pmmm/ From bgroh at redhat.com Wed Jul 7 02:27:59 2004 From: bgroh at redhat.com (Bernd Groh) Date: Wed, 07 Jul 2004 12:27:59 +1000 Subject: Annoucement: New translation status page is installed In-Reply-To: <200407070320.02515.pmmm@rnl.ist.utl.pt> References: <1087874101.17780.230.camel@sarah.brisbane.redhat.com> <200407061056.21489.pmmm@rnl.ist.utl.pt> <40EB3054.5010905@redhat.com> <200407070320.02515.pmmm@rnl.ist.utl.pt> Message-ID: <40EB5FAF.4040704@redhat.com> Pedro, completely agree with you. Bernd Pedro Morais schrieb: >Em Quarta, 7 de Julho de 2004 00:05, Bernd Groh escreveu: > > >>>Also, maybe the quality step mail should mention who was the translator >>>involved? >>> >>> >>Agreed. Maybe the translator should be left in place even? Maybe even >>still have the right to make changes, even though the module is in QA? >>Would that be desireable? Or rather not? >> >> > >What I found weird was that after I had commited changes I received the mail >saying that, and I thought, who commited that? >If it said that ir was "morais" I would have noticed "uhm, it's the stuff I >commited". > > > -- Dr. Bernd R. Groh Phone : +61 7 3514 8114 Software Engineer (Localization) Fax : +61 7 3514 8199 Red Hat Asia-Pacific Mobile: +61 403 851 269 Disclaimer: http://apac.redhat.com/disclaimer/ From jam at siriusbb.com Wed Jul 7 06:25:35 2004 From: jam at siriusbb.com (Jamil Ahmed) Date: Wed, 7 Jul 2004 12:25:35 +0600 Subject: How to update existing 100% translated files? Message-ID: <00e501c463eb$37cc0b40$0a01a8c0@Jamil> Hi, I am getting *HUGE* mails regarding the new status page. Sorry I couldn't get all of those... My question is how to update existing 100% translated files? Cause I can't commit files thru cvs if it is not assigned to me. And there is no [Take] option for the 100% translated files. :-( btw, I am working on Bengali/Bangla translation Thanks, `Jamil From sarahs at redhat.com Wed Jul 7 06:29:31 2004 From: sarahs at redhat.com (Sarah Wang) Date: Wed, 07 Jul 2004 16:29:31 +1000 Subject: How to update existing 100% translated files? In-Reply-To: <00e501c463eb$37cc0b40$0a01a8c0@Jamil> References: <00e501c463eb$37cc0b40$0a01a8c0@Jamil> Message-ID: <1089181771.2090.28.camel@sarah.brisbane.redhat.com> I'd say to apply to be "maintainer" :) Sarah On Wed, 2004-07-07 at 16:25, Jamil Ahmed wrote: > Hi, > > I am getting *HUGE* mails regarding the new status page. > Sorry I couldn't get all of those... > > My question is how to update existing 100% translated files? > Cause I can't commit files thru cvs if it is not assigned to me. > And there is no [Take] option for the 100% translated files. :-( > > btw, I am working on Bengali/Bangla translation > > Thanks, > `Jamil > > > > > -- > Fedora-trans-list mailing list > Fedora-trans-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-trans-list From jam at siriusbb.com Wed Jul 7 06:38:36 2004 From: jam at siriusbb.com (Jamil Ahmed) Date: Wed, 7 Jul 2004 12:38:36 +0600 Subject: How to update existing 100% translated files? References: <00e501c463eb$37cc0b40$0a01a8c0@Jamil> <1089181771.2090.28.camel@sarah.brisbane.redhat.com> Message-ID: <010001c463ed$08598520$0a01a8c0@Jamil> Okay, I mailed to i18n at redhat.com for Maintainer:*/bn ;-) Thanks, `Jamil ----- Original Message ----- From: "Sarah Wang" To: "Jamil Ahmed" ; "Fedora Translation Project List" Sent: Wednesday, July 07, 2004 12:29 PM Subject: Re: How to update existing 100% translated files? > I'd say to apply to be "maintainer" :) > > Sarah > > On Wed, 2004-07-07 at 16:25, Jamil Ahmed wrote: > > Hi, > > > > I am getting *HUGE* mails regarding the new status page. > > Sorry I couldn't get all of those... > > > > My question is how to update existing 100% translated files? > > Cause I can't commit files thru cvs if it is not assigned to me. > > And there is no [Take] option for the 100% translated files. :-( > > > > btw, I am working on Bengali/Bangla translation > > > > Thanks, > > `Jamil From ra at ra.is Wed Jul 7 18:18:44 2004 From: ra at ra.is (Richard Allen) Date: Wed, 7 Jul 2004 18:18:44 +0000 Subject: CVS commit problems ? In-Reply-To: <40EB5FAF.4040704@redhat.com> References: <1087874101.17780.230.camel@sarah.brisbane.redhat.com> <200407061056.21489.pmmm@rnl.ist.utl.pt> <40EB3054.5010905@redhat.com> <200407070320.02515.pmmm@rnl.ist.utl.pt> <40EB5FAF.4040704@redhat.com> Message-ID: <20040707181844.GA21156@ra.is> [ra at proxy anaconda]$ cvs commit -m "" cvs commit: Examining . Testing is.po... [anaconda/is.po] is not assigned to you. **** Access allowed: ra is in ACL for anaconda/po. cvs server: Pre-commit check failed cvs [server aborted]: correct above errors first! [ra at proxy anaconda]$ (thats the anaconda module) -- Rikki. -- RHCE, RHCX, HP-UX Certified Administrator. -- Solaris 7 Certified Systems and Network Administrator. Bell Labs Unix -- Reach out and grep someone. Those who do not understand Unix are condemned to reinvent it, poorly. From menthos at menthos.com Wed Jul 7 20:37:00 2004 From: menthos at menthos.com (Christian Rose) Date: Wed, 07 Jul 2004 22:37:00 +0200 Subject: Annoucement: New translation status page is installed In-Reply-To: <40EA59F5.5060400@redhat.com> References: <1087874101.17780.230.camel@sarah.brisbane.redhat.com> <200406221027.17982.rahal@arabeyes.org> <1087944558.4669.4086.camel@daim> <40D8D50F.8080505@redhat.com> <1088899522.7077.759.camel@stina.menthos.com> <40EA59F5.5060400@redhat.com> Message-ID: <1089232620.17538.361.camel@daim> tis 2004-07-06 klockan 09.51 skrev Bernd Groh: > >* This is the first time I ever hear about this person. Swedish is not a > >big language, and free software translations for it is of course done by > >an even smaller community. I've been translating free software into > >Swedish for six years now, and am quite familiar with the few people > >that are working to do the same in other projects. > >Searching Google, I can find no references to a person with this name > >and mail address. Searching only for the name leaves me with quite a few > >hits, since the first name and last name are both common ones. But no > >match whatsoever has a connection to Linux or OSS/free software or > >translations. > > > >Given all of this, I find it hard to believe that this person is for > >real, and I find it quite insulting that you believe that this person > >would do a better job translating anaconda than me. Perhaps that's not > >what you really and honestly do believe, but then again your comment > >together with the fact that this person has taken the anaconda > >translation, and thus in fact is allowed to lock me out, would sure let > >one believe this. > > Maybe the fact that I've offered you the maintainership of all swedish > modules, twice even, and now for the third time, since it's still yours > for the taking if you want it, which would put you into the position to > release the module from that person and take it yourself, or let someone > else take it, should, IMO, not make you believe this. IIRC you hadn't made any such offer at the time you replied that this unknown person was the new anaconda translator. And IIRC I have also replied stating that yes, I have been since the year 2000, and would like to still continue to be, the Swedish Fedora translation coordinator, and would like you to make the current access restrictions reflect that. And before you reply that you would like confirmation from the team, I'd like to make clear that the active translators are just me and G?ran Uddeborg, and we've already in the past agreed that I be the coordinator. And no, I don't count the unknown person with the dirty mail address on the web as an active contributor. > Or have you seen > me offering the maintainership of the swedish modules to anyone you've > never heard of? See my "perhaps that's not what you really believe" comment in what I wrote. With this I meant that I didn't believe you personally had intentionally assigned the module to someone else. It was a flaw in the new status pages/policy that allowed that to happen. Thus my whole remark was a reply to you defending that flaw, and the implications the flaw has in effect. > And no, I do not believe that this person would do a > better job translating anaconda than you, fact is, I do not speak > swedish and I cannot and will not make judgement. I know through > third-party feedback that you've done an extremely good job keeping the > swedish translations up to date and to a good quality in the past Nice to hear that the word is going around. [...] > My statement didn't > intend to say that the person who took anaconda has a right to look you > out, I simply meant to say that you're invited to become a maintainer > and release that person yourself, since I don't think it's my job to > decide on who's allowed to do swedish translations and who isn't. I > believe swedish speaking people should do that. Then we agree. Then I urge you to please scrap the "everyone can take a Swedish translation" functionality on the translation status pages. I would like new Swedish translation volunteers to contact me first and recieve my approval before they can contribute. And it's not that I'm intentionally evil or like bureaucracy. I don't. I simply want to know who wants to translate into Swedish. I want them to contact me, because I have other things to do aswell, and my time is precious to me. I probably cannot hunt down potential contributors, and I don't want to spend my time trying. If they want to contribute, they can contact me. If you say you don't want to restrict this, then you're contradicting yourself. You can't both say that you don't want to be the one that decides who's allowed to do Swedish translations, and then implement a free access for anyone system. Then you are in fact deciding on who's allowed to do Swedish translations. Unless you can agree on delegating that responsibility in the Swedish case to me, because then you are delegating that responsibility to a Swedish speaking person who can make an informed judgement and decision. A person that has already been taking that responsibility and accountability in the past, and will continue to do so. > I'm sorry if it felt like an insult to you, it wasn't meant to be one. Apology accepted. Christian From menthos at menthos.com Wed Jul 7 21:32:01 2004 From: menthos at menthos.com (Christian Rose) Date: Wed, 07 Jul 2004 23:32:01 +0200 Subject: The problems with free CVS committing In-Reply-To: <40EB3F74.3010107@redhat.com> References: <1087874101.17780.230.camel@sarah.brisbane.redhat.com> <200406221027.17982.rahal@arabeyes.org> <1087944558.4669.4086.camel@daim> <40D8D50F.8080505@redhat.com> <1088899522.7077.759.camel@stina.menthos.com> <40EA59F5.5060400@redhat.com> <1089128531.22067.53.camel@bree.local.net> <40EB3F74.3010107@redhat.com> Message-ID: <1089235920.17538.476.camel@daim> ons 2004-07-07 klockan 02.10 skrev Bernd Groh: > >>What is the major drama about having the changes in the cvs? If the > >>translation is no good, you can always roll back. I prefer to have the > >>changes in cvs, at least then everyone can have a look at the most recent > >>changes without having to talk to the person who has the po-file in > >>her/his inbox. A commit is not a final thing, it can easily be undone. > > > >That depends on when the commit is done. If the commit is done shortly > >before a freeze of some sort, there's a good chance that it _can't_ be > >easily undone. It first requires getting the maintainer of the module > >to respin when they thought they were already done. A lot of the QA > >which has been done at that point then also needs to be at least checked > >to see if it needs to be reverified or not. And if it's not noticed for > >a day or two (for whatever reason, that's not unreasonable) and you then > >hit the point at which the tree is frozen, then getting it changed is > >that much more difficult. > > Well taken. And I don't really have anything against QAing before a file > is commited, iff there is a maintainer who is happy to QA it. If the > maintainer just doesn't have the time, given it's all voluntary after > all, and good translations are simply sitting in an inbox, rather than > getting into the packages, than that's a situation I'd like to avoid. Or > is it really the case that most committed translations are bad? No it's not. And it's not the case that most of the time it rains in the desert either. Yet, you'll still see that most houses in the desert have waterproof roofs. Why is that? If we use your logic, this thing with having roofs would be totally unreasonable, or imply that it rained often in the desert. It's that way because we know for sure sometime it's bound to happen, and the drawbacks of not having the protection are typically considered more important and have more impact, than the benefits of not having the protection. It's the same with CVS access. No, most commits are perfectly fine. Yet, when someone commits a bad or broken translation, it often wastes other contributor's time and to a significant extent ruins their effort in the affected release. > >> Or do you always > >>make sure that your most recent software changes work before you commit > >>them? How do you do that with a larger addition? Do you wait till it's > >>finished and not keep track of changes for days, but commit a whole > >>bunch of changes at once? > > > >The goal has to be to keep CVS working at all times. Otherwise, you > >kill testing. So yes, I tend to try to make sure that either a) my new > >stuff works or b) at least doesn't break anything new (perhaps the new > >functionality doesn't work, but old things should continue doing so). > > For the case that my additions can break stuff that's tested, of course > I do that too. For my own projects, I usually make sure that all my > release branches are working at all time, but I am not that strict with > HEAD, since I don't deploy HEAD. FWIW, in Fedora for translators there is no distinction between HEAD and stable releases. It's all the same. Everything committed will be packaged in a product at some point, sometimes later, sometimes *very* soon. And usually it's impossible to know exactly when. Even if we know the rough schedule, maintainers can decide to package sooner or later, and there can be a large, and usually in advance unknown, difference in time between the first and the last one. > >This is even more the case with translations since the code maintainers > >of a module aren't going to know/keep up with the status of the > >translations and so need them to be as "correct" as possible at all > >times since there's no controlling when they're going to do a build. > > Do not disagree in the least. But why should commited translations by > default be incorrect? And in particular, why should they now be more > incorrect than before? Why should we have roofs on or houses even in areas where it hardly rains? Why does my car have crash zones? It surely must imply I'm a bad driver? Cars didn't use to have crash zones. Does it automatically imply people are worse drivers nowadays? Ok, enough of making fun of the funny logic; let's get to some of the real, hard reasons free CVS committing without prior review is for the most part a very bad strategy: 1) If the po file has syntactic errors, the software build will break. This will make software maintainers, many other contributors, and testers *very* unhappy. 2) If the po file has other problems, such as bad translations, it will go undetected for a potentially long time. Bad translations can be an as bad show-stopper to the end user perception of product quality as many other bugs, including crashes. Thus, just because the product doesn't crash, it doesn't mean that's all there is to QA. Far from it. 3) Prior reviewing is often a lot more likely to get done than post reviewing. Most people don't consider reviewing to be fun in itself, but if you know that there's a commit pending the review, you at least have an incentive to do the review, in order for the commit to get done. In practice, it's thus very difficult to get volunteers to do post reviewing, especially if they would have to figure out themselves that the commit happened in the first place, and how to get the file to review themselves afterwards. 4) Many teams have public mailing lists. This is a natural place to have reviews on, since anyone can do a review, and the review doesn't depend on a single person having to do it. Still, many problems are likely to be catched. Thus there's not necessarily the "getting stuck in somone's inbox" problem you're talking of. 5) If someone commits an erroneous file, someone has to notice it. And no, tracking CVS takes a nontrivial amount of time and effort. Not everyone is employed by a company to deal with this kind of things on their job time. Not many people consider having to constantly monitor other people's commits and check them afterwards for errors a fun thing to spend their time on. 6) If someone commits an erroneous file, someone has to fix it. And no, reverting things in CVS takes a nontrivial amount of time and effort. Not everyone is employed by a company to deal with this kind of things on their job time. Not many people consider having to revert other people's stuff a fun thing to spend their time on. Out of these, the points 1, 2, 5, and 6 should be obvious to anyone with any level of QA experience in free software. Christian From menthos at menthos.com Wed Jul 7 22:52:21 2004 From: menthos at menthos.com (Christian Rose) Date: Thu, 08 Jul 2004 00:52:21 +0200 Subject: About the new Status Pages In-Reply-To: <40EA32BB.9010901@redhat.com> References: <40E3654E.7050807@redhat.com> <1088943666.7077.907.camel@stina.menthos.com> <40EA32BB.9010901@redhat.com> Message-ID: <1089240740.17538.642.camel@daim> tis 2004-07-06 klockan 07.03 skrev Bernd Groh: > As said, and that's why I am a little surprised by your email, I am > actually in favour of not just giving anyone cvs access for a certain > language, if 1) the group wants it, and 2) somebody makes > herself/himself accountable for such decision. If a language group > wouldn't want to restrict cvs access to "newcomers", nobody of that > language group would actually be willing to be accountable for such > decision, or there isn't any language team in place yet, I do not see > why I should not give someone of that language group cvs access. What is > wrong with that model? If 1) the group wants it, and 2) somebody makes > herself/himself accountable for such decision, I do agree completely > that cvs access should be restricted, and the group should decide > when/if it is time to give a "newcomer" cvs access. I've said the > exactly same before, and I say it here again, just in case it wasn't > entirely clear where I stand, though it should be. Ok. You still base your argument though on that it's difficult to be a coordinator or find someone to be one. That's not my experience at all. More on that below. [...] > >>You say that wouldn't happen if you'd have a group and one > >>coordinator to coordinate all translations of the group? For a small > >>group that might be feasible, but if you have one coordinator and 70+ > >>translators, things can get quite difficult to manage this way. Also, we > >>would require the coordinator to be available at all time, we'd require > >>the coordinator to make a decision, or we'd require 70 people to > >>discuss about who's going to translate the file. [...] > > > >The first thing that struck me was the claim that there will be 70+ > >translators for any single language. Believe me, the largest language > >translation teams I know of aren't more than, say, a dozen to twenty > >people for any project. > > I can only go by how many people sign up to be a translator for a > certain language, and we have language groups with well above 70 > translators. Ok, you count teams different than I do. Given your explanation above, you count a team as everyone who has ever explained interest in a particular language and/or subscribed to a mailing list. I count a team as roughly the group of active translators. By active I meant those who have actually produced or updated at least one translation in recent time, ie. not someone only lurking on a mailing list, and not people that did their last translation update two years ago. There can, and usually is, a big difference in numbers. For practical purposes, I consider the way of counting the active contributors much more useful. Contribution counts. It's difficult to get a qualified opinion from people that are silently lurking on a mailing list, or (even worse) perhaps only posting noise to the list but not actively contributing, be it in translations or reviews. > > And then that's still an exceptionally huge > >team; almost all of them are much smaller, like one to five people. So > >giving an example of "70+ people" doesn't really look like it's even > >remotely connected to reality. It looks like the figure is intentionally > >blown out of proportion. > > Well, it's not, and it certainly shouldn't look that way. My apologies > if it appeared as if I'd intentionally blow things out of proportion, I > simply did a count. I'm sure you can count. So can I. The key point is the relevance of those numbers. For Swedish Fedora translations, there are two active contributors: G?ran and me. On the translation mailing list we use, there are on the other hand 55 subscribers. I counted them. Granted, many of them I've never seen posting to the list, and some are only contributing to other projects, such as the TP and GNOME/KDE etc. The people who are actively doing reviews are only a handful, a dozen at best. And I know for a fact that this situation is not unique. On the contrary, it's the common case to have a majority of silent bystanders and lurkers on a public mailing list, who hardly have any effect whatsoever on the daily actions and contributions, and often not even the discussions. > >Second, teams in practice usually annotate who is responsible for what > >themselves, sometimes only with a simple spoken agreement, sometimes > >with a list on a static web page, and sometimes even with more advanced > >systems, similar to the current Fedora status pages. It usually depends > >on the team's size and their structure what sort of method they want to > >use and feel comfortable with. [...] > >even that there is a benefit for larger teams, because larger teams > >usually already have this in place. This is not new. The reason you got > >requests for this is probably because you haven't had a team policy in > >the past, so team agreement didn't always apply. That's fine, but don't > >make it sound like evidence of team agreement not working. > > Neither I said there is a benefit for larger teams, I simply said there > could be, depending on how the team handles things. And for some teams it could be that there is no benefit at all, but rather a drawback, since instead of handling this on their own they must now have this system imposed on them, and keep having to ask you whenever it doesn't suit them, and hope that you will both agree to the change and have the time to do it. > >Third, you make it sound like who's in charge of what usually changes > >every day. > > How? By introducing a Maintainer and stating that a maintainer should be > a "permanent" entity? You made an argument by claiming it was difficult for a dingle coordinator to keep track of assignment changes, something I don't agree with is necessarily true, except for the biggest teams. > > In fact, it's usually quite a static thing. When a person > >starts to translate a module, he usually keeps maintaining it, unless > >some unforeseen issue arises. Of course people do sometimes exchange > >modules, but that's almost always the exception. If you study teams > >empirically you'll find that almost all translators keep maintaining the > >same modules they've done previously. So requests for changing module > >maintainership is usually a rare thing. > > That's how it should be, and that's why I've said a Maintainer should be > something "permanent". However, in our current reality, we do have to > deal with more than one person working on one and the same module at the > same time. Simply saying that it shouldn't be that way doesn't make it > go away. Saying that it's because there aren't any teams and we > shouldn't have done a, b, and c in the past, doesn't make it go away > either. As said, I cannot change the past, all I can do is to try and > better things from how they are now. All we did was adding visibility to > what's going on, what was so wrong about that? Because you used this opportunity not to try to rectify the lack of teams, but rather try to ensuring the lack of teams could be maintained for the future, by not changing the policy but rather have the new translation status pages make the policy even more prominent. And you're still not prepared to change the policy. > >Fourth, you claim that all members of the team would fight for > >translating a new module, thus making the life of the coordinator > >difficult. > > No, I don't. I can kind of see how you could get there, given I've said: > "or we'd require 70 people to discuss about who's going to translate the > file", but with this, I did not intend to say that members of a team > would actually fight for translations, neither I was making any kind of > claim, I simply meant to illustrate the responsibility a coordinator > has, and the difficulties s/he could, in addition, face in a large team. Hypotethical speculations at best. I could also claim any organization shouldn't have a responsible person, because there could be a danger of the members of the organization disagreeing with eachother. How novel. > All that was part of me making the point that, even though we'd like to > have coordinators for every team, we'd like such role to be entirely > voluntary, and not mandatory in order for the entire system to work. > That's all. Again, I didn't mean to say the coordinator model doesn't > work, neither that our model is better, not even that we do not want to > have coordinators, all I meant is that I do not wish to build a system > that is dependent on a coordinator or a team of a certain structure > being in place, but supports it iff that should be the case. > > > This is almost never the case. It's difficult to get > >volunteers, and every volunteer can usually get all what they want in > >terms of getting their hands dirty without stepping on someone else's > >toes > > I'd say this depends on the language and the people involved in that > particular language, in general, I'd tend to agree with you, though. > > > The problem is almost always the opposite -- to get volunteers to > >work on a new module at all. Hence, the situation you describe with all > >members of a team fighting for a particular module isn't the common case > >at all. > > Christian, in fact, I do agree with you that it is hard to get good > people taking on certain responsibilities, and this isn't just limited > to translations, but even more so to maintaining modules and > coordinating a language, or would you now disagree? Do you believe it is > hard to get people working on a module, but actually easy to find > maintainers, or even coordinators? I actually do agree with you, that, > in general, it is hard to find either, and that exactly is why I don't > want to build a system that is dependent on it. Why would you build a > system that is dependent on something that, apparently, is hard to > find? Why not simply support it if a given structure is in place or > forms naturally, and voluntarily? Maybe it is just my opinion, but if > nobody wants to be the coordinator of an entire language, I don't think > the language should have one, though I'd hope it would be the case. > Maybe I am wrong, but that's simply how I see things. You're still basing your argument on that it is difficult to find coordinators. My experience is that it simply isn't. In my experience it's sometimes even easier to find a coordinator, than someone willing to do the actual work of translating modules, because the latter is often much more work. :-) For a one person team, being the coordinator is no extra work at all. For a small team (2 to 4 people), being a coordinator is basically just a title. There's not much for the coordinator to do, other than noting who does what, which usually doesn't change that often. For a bigger team, the noting of who does what is of course a bigger challenge, and it grows further with the team size. But here comes the beauty: When the team size grows, the more likely you are to find someone who is willing to step up to do the work of coordinating. Pick any group of ten people, and count the number of times you'll get a group where not *anyone* would find it acceptable to be the one who keeps note of who maintains what, and occasionally be the one who has the final say on things. You're unlikely to get many such groups. There's also another thing with bigger groups. Having an official coordinator doesn't rule out the possibilities of delegating some of the work to others, and the bigger the group is, you're then again more likely to find people who can do those responsibilities. Given this and my own experience, I don't agree with it being hard to find coordinators, and I agree even less with taking this claim to be the foundation of a policy where you don't even *try* to have a coordinator by default. > > Trust me, it really isn't. Most > >translators seem to be happy with and familiar enough to email > >communication to be able to send short mails in their native tounge for > >this to be a total non-issue. And, the assignments are almost always > > > > We do have quite active mailing lists for some languages, and yes, with > 70+ subscribers (just to stick with that number, I could easily blow it > even more out of proportion), and I doubt communicating via email in > large and active mailing lists is an ideal situation. Again, I don't say > it can't be done this way, neither I say our way is superior, I simply > say that I prefer our way for mere reasons of scalability. That may as > well be a non-issue, but not one I'd like to count on. You should leave it up to the language team to decide. No solution fits every language team, as even you have pointed out. And the team keeping track of the assignment coordination themselves without having to bother you or anyone else in charge of the status pages works *especially* well for smaller teams, so there's no reason it shouldn't be the default. Let the teams who want it have the status pages assignment control, and leave the rest of the teams to coordinate their work in whatever way fits them best. > >non-controversial, so there is rarely the big discussions you try to > >make a point of. Almost all this communication is a two-piece, really > >short one: "I will translate XYZ" and the reply "OK, noted". Again, you > >blow the issue out of proportion, and the argument doesn't seem to be > >based on reality. > > In my experience, it's a short email "I will translate abc", "I will > translate bcd", no "Noted" then replies "is anyone translating def"? or > "who is translating bgr", maybe "I have translated xrt", then "sorry, > xrt is finished now", maybe "what is available?", "what can I > translate?", and just scale that out a bit now, and make a good argument > of why I should use email communication to manage who's doing what? You > say this is not based on reality? Sorry, but this is the reality I am > facing. Yes, true, assignment is most of the time non-controversial, and > if you read what I wrote, you'll see that I never said otherwise. Given > everyone knows what everyone else is doing, why translate what someone > else is translating already? But, if I don't know, I don't know, and an > email is easily missed too, especially if you get many. Of course, that > is all blown out of proportion and not based on reality, right? Or is > your reality the only reality and every other "reality" is just made up > and blown out of proportion? No, I base my view on my six years of experience with translation and translation coordination, both with smaller and bigger teams, and then the coordination a whole translation project. If there's something single important thing I've learned then that's that there is no single organizational structure and assignment policy that fits every team. Some teams are large, some very small, and some work for common, big languages spoken by hundreds of millions of people, while others for smaller, perhaps even minority languages. The reality you describe is the one for a big team for a big language, where there are many people involved and loosely organized, and many new volunteers joining at the same time. This is certainly a truth, but only one part of the truth. There are many teams aswell where the situation is almost *completely* the opposite, and where for example mail communication works just fine. The assignment control on the new translation status pages probably works well for such a team you describe, but it probably at the same time won't work very well for others, where it gets in the way of the already established and efficient procedure. Yet you want to squeeze all teams into using this by default. My opinion is that it should be optional, and only used if there's an explicit request to use it by the team. > >And last but not least, you fail to answer the question why you think > >translation is different enough from other forms of contributions, like > >software patches, where this anarchistic, no-prior-review-needed policy > >is definately not used. If you believe a mandated review and cooperation > >policy is bad for contributions, then why does every other form of > >significant contribution to a project require this? > > Well, naturally, the most important thing is that the system is stable > and works properly, and not reviewing software patches couldn't ensure > that. Of course, it is most important that the systems works, and be it > only in english. Or would you rather have a swedish system that crashes > regularly, than an english one that works properly? I am not the only > one who would agree that the software working properly is more important > than the translation being perfect, or do you really want to say that > this isn't so in reality? This statement that anything that builds and doesn't crash is just fine is so absurd from a QA point of view I won't even bother to respond. I trust you have no prior experience with any QA or the real implications and considerations of such processes, so I'll rest my case. Christian From bgroh at redhat.com Wed Jul 7 23:49:31 2004 From: bgroh at redhat.com (Bernd Groh) Date: Thu, 08 Jul 2004 09:49:31 +1000 Subject: Annoucement: New translation status page is installed In-Reply-To: <1089232620.17538.361.camel@daim> References: <1087874101.17780.230.camel@sarah.brisbane.redhat.com> <200406221027.17982.rahal@arabeyes.org> <1087944558.4669.4086.camel@daim> <40D8D50F.8080505@redhat.com> <1088899522.7077.759.camel@stina.menthos.com> <40EA59F5.5060400@redhat.com> <1089232620.17538.361.camel@daim> Message-ID: <40EC8C0B.1010103@redhat.com> Hi Christian, >IIRC you hadn't made any such offer at the time you replied that this >unknown person was the new anaconda translator. >And IIRC I have also replied stating that yes, I have been since the >year 2000, and would like to still continue to be, the Swedish Fedora >translation coordinator, and would like you to make the current access >restrictions reflect that. > Sorry if I missed that, I'll make sure it gets done today. >And before you reply that you would like confirmation from the team, I'd >like to make clear that the active translators are just me and G?ran >Uddeborg, and we've already in the past agreed that I be the >coordinator. And no, I don't count the unknown person with the dirty >mail address on the web as an active contributor. > No, no confirmation needed. >>Or have you seen >>me offering the maintainership of the swedish modules to anyone you've >>never heard of? >> >> > >See my "perhaps that's not what you really believe" comment in what I >wrote. With this I meant that I didn't believe you personally had >intentionally assigned the module to someone else. It was a flaw in the >new status pages/policy that allowed that to happen. >Thus my whole remark was a reply to you defending that flaw, and the >implications the flaw has in effect. > I believe we still disagree here, but, as said, I'm happy to discuss it. Before, everyone could commit, as such, everyone could be an anaconda translator at any given time. We've simply limited that to one at a given time, given there's no maintainer of the module. Of course, if there are "right" and "wrong" translators, it can happen that a "wrong" translator gets in before a "right" translator. However, I cannot make the decision of who's "right", and who's "wrong", I have to treat everyone the same by default, and then, add other options to be able to reflect other things, like maintainers and other mechanisms. But, I still need to support multiple self-maintained translators for a module, since that is part of our reality too. Alan suggested a [Steal] button, allowing others to steal a module. Would you support such feature? We could email the mailing-list of that language about the steal, so we don't have any "wrong" translators steal modules from "right" translators without having to justify themselves to the other translators of that language group. Would that be a feature you'd support? >>And no, I do not believe that this person would do a >>better job translating anaconda than you, fact is, I do not speak >>swedish and I cannot and will not make judgement. I know through >>third-party feedback that you've done an extremely good job keeping the >>swedish translations up to date and to a good quality in the past >> >> > >Nice to hear that the word is going around. > It is. :) >[...] > > >>My statement didn't >>intend to say that the person who took anaconda has a right to look you >>out, I simply meant to say that you're invited to become a maintainer >>and release that person yourself, since I don't think it's my job to >>decide on who's allowed to do swedish translations and who isn't. I >>believe swedish speaking people should do that. >> >> > >Then we agree. Then I urge you to please scrap the "everyone can take a >Swedish translation" functionality on the translation status pages. I >would like new Swedish translation volunteers to contact me first and >recieve my approval before they can contribute. > If new volunteers were to contact you first, would you still want the "everyone can take a swedish translation" functionality scraped? >And it's not that I'm intentionally evil or like bureaucracy. I don't. I >simply want to know who wants to translate into Swedish. I want them to >contact me, because I have other things to do aswell, and my time is >precious to me. I probably cannot hunt down potential contributors, and >I don't want to spend my time trying. If they want to contribute, they >can contact me. > For now, as maintainer, you'll be informed whenever someone takes a module, and whenever somebody commits. You'll have the right to step in at any time, release someone from a module, and take it yourself. For everything else, I'd like you to understand that it may take a little longer, but I am supporting it, and I do thank you for the effort you put into the swedish translations. >If you say you don't want to restrict this, then you're contradicting >yourself. You can't both say that you don't want to be the one that >decides who's allowed to do Swedish translations, and then implement a >free access for anyone system. Then you are in fact deciding on who's >allowed to do Swedish translations. > Well, I didn't implement a free access for anyone system, I simply didn't touch the system that was in place, since I didn't think it was up to me to change it. I still don't. But, I'd like to support active groups in favour of restricted access, and having a designated maintainer happy to be accountable for the decision to now restrict access. >Unless you can agree on delegating that responsibility in the Swedish >case to me, because then you are delegating that responsibility to a >Swedish speaking person who can make an informed judgement and decision. >A person that has already been taking that responsibility and >accountability in the past, and will continue to do so. > You do have my full support. >>I'm sorry if it felt like an insult to you, it wasn't meant to be one. >> >> > >Apology accepted. > Thank you! Bernd > > >Christian > > >-- >Fedora-trans-list mailing list >Fedora-trans-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-trans-list > > -- Dr. Bernd R. Groh Phone : +61 7 3514 8114 Software Engineer (Localization) Fax : +61 7 3514 8199 Red Hat Asia-Pacific Mobile: +61 403 851 269 Disclaimer: http://apac.redhat.com/disclaimer/ From bgroh at redhat.com Thu Jul 8 01:27:54 2004 From: bgroh at redhat.com (Bernd Groh) Date: Thu, 08 Jul 2004 11:27:54 +1000 Subject: The problems with free CVS committing In-Reply-To: <1089235920.17538.476.camel@daim> References: <1087874101.17780.230.camel@sarah.brisbane.redhat.com> <200406221027.17982.rahal@arabeyes.org> <1087944558.4669.4086.camel@daim> <40D8D50F.8080505@redhat.com> <1088899522.7077.759.camel@stina.menthos.com> <40EA59F5.5060400@redhat.com> <1089128531.22067.53.camel@bree.local.net> <40EB3F74.3010107@redhat.com> <1089235920.17538.476.camel@daim> Message-ID: <40ECA31A.4060301@redhat.com> Christian, Christian Rose schrieb: >ons 2004-07-07 klockan 02.10 skrev Bernd Groh: > > >>>>What is the major drama about having the changes in the cvs? If the >>>>translation is no good, you can always roll back. I prefer to have the >>>>changes in cvs, at least then everyone can have a look at the most recent >>>>changes without having to talk to the person who has the po-file in >>>>her/his inbox. A commit is not a final thing, it can easily be undone. >>>> >>>> >>>That depends on when the commit is done. If the commit is done shortly >>>before a freeze of some sort, there's a good chance that it _can't_ be >>>easily undone. It first requires getting the maintainer of the module >>>to respin when they thought they were already done. A lot of the QA >>>which has been done at that point then also needs to be at least checked >>>to see if it needs to be reverified or not. And if it's not noticed for >>>a day or two (for whatever reason, that's not unreasonable) and you then >>>hit the point at which the tree is frozen, then getting it changed is >>>that much more difficult. >>> >>> >>Well taken. And I don't really have anything against QAing before a file >>is commited, iff there is a maintainer who is happy to QA it. If the >>maintainer just doesn't have the time, given it's all voluntary after >>all, and good translations are simply sitting in an inbox, rather than >>getting into the packages, than that's a situation I'd like to avoid. Or >>is it really the case that most committed translations are bad? >> >> > >No it's not. > >And it's not the case that most of the time it rains in the desert >either. Yet, you'll still see that most houses in the desert have >waterproof roofs. Why is that? If we use your logic, this thing with >having roofs would be totally unreasonable, or imply that it rained >often in the desert. > >It's that way because we know for sure sometime it's bound to happen, >and the drawbacks of not having the protection are typically considered >more important and have more impact, than the benefits of not having the >protection. > In any case? Let's say I know it hardly ever rains, and I don't really have enough money to do both, put a waterproof roof on my house and feed my family. Am I really to chose the waterproof roof, given I know it hardly ever rains? It's all about making the most with the ressources you've got, isn't it? Of course, if I've got enough ressources, I'd defnitiely put a waterproof roof on my house, completely agree. >It's the same with CVS access. No, most commits are perfectly fine. Yet, >when someone commits a bad or broken translation, it often wastes other >contributor's time and to a significant extent ruins their effort in the >affected release. > Do not disagree, just the same as with above. >>>>Or do you always >>>>make sure that your most recent software changes work before you commit >>>>them? How do you do that with a larger addition? Do you wait till it's >>>>finished and not keep track of changes for days, but commit a whole >>>>bunch of changes at once? >>>> >>>> >>>The goal has to be to keep CVS working at all times. Otherwise, you >>>kill testing. So yes, I tend to try to make sure that either a) my new >>>stuff works or b) at least doesn't break anything new (perhaps the new >>>functionality doesn't work, but old things should continue doing so). >>> >>> >>For the case that my additions can break stuff that's tested, of course >>I do that too. For my own projects, I usually make sure that all my >>release branches are working at all time, but I am not that strict with >>HEAD, since I don't deploy HEAD. >> >> > >FWIW, in Fedora for translators there is no distinction between HEAD and >stable releases. It's all the same. Everything committed will be >packaged in a product at some point, sometimes later, sometimes *very* >soon. > True. I didn't really relate that comment to translations, given the comment I responded to wasn't related to translations at this point either. >And usually it's impossible to know exactly when. Even if we know the >rough schedule, maintainers can decide to package sooner or later, and >there can be a large, and usually in advance unknown, difference in time >between the first and the last one. > Completely agree. >>>This is even more the case with translations since the code maintainers >>>of a module aren't going to know/keep up with the status of the >>>translations and so need them to be as "correct" as possible at all >>>times since there's no controlling when they're going to do a build. >>> >>> >>Do not disagree in the least. But why should commited translations by >>default be incorrect? And in particular, why should they now be more >>incorrect than before? >> >> > >Why should we have roofs on or houses even in areas where it hardly >rains? Why does my car have crash zones? It surely must imply I'm a bad >driver? > If it is up to you to either get a good car, or one that'll do for what you need, and still allows you to feed your family, would you really get one that is better and more safe? Because it protects you, while your family starves? Yes, of course, if you can afford it, if you have enough ressources, why should you not get a safer car? But if you don't have the ressources? Now, given you do have the ressources, and it is no question to you to get the safer car, would you expect everyone else to get the safer car too? Regardless of whether they can afford it or not? >Cars didn't use to have crash zones. Does it automatically imply people >are worse drivers nowadays? > No, just as it doesn't imply that people who can't afford safe cars are any worse or better drivers than people who can afford safe cars. If safe cars are really that much better, why isn't everyone driving a safe car? >Ok, enough of making fun of the funny logic; let's get to some of the >real, hard reasons free CVS committing without prior review is for the >most part a very bad strategy: > Were you making fun? I didn't think so. I thought you were trying to illustrate some of your points with certain analogies, all missing on crucial point: Whether you can do something or not, is dependent on the ressources you've got. >1) If the po file has syntactic errors, the software build will break. >This will make software maintainers, many other contributors, and >testers *very* unhappy. > You mean the po-format, which should be taken care of, if you, for example, use KBabel. Ok, agreed, would make me *very* unhappy too. I believe a pre-commit step to simply check the format is ok should suffice. Good idea. >2) If the po file has other problems, such as bad translations, it will >go undetected for a potentially long time. > Why? You mean once it's in cvs, the maintainer is no longer willing to look at it? But s/he'll only look at it if it's in her/his inbox? >Bad translations can be an as bad show-stopper to the end user >perception of product quality as many other bugs, including crashes. >Thus, just because the product doesn't crash, it doesn't mean that's all >there is to QA. Far from it. > Completely agree. >3) Prior reviewing is often a lot more likely to get done than post >reviewing. Most people don't consider reviewing to be fun in itself, but >if you know that there's a commit pending the review, you at least have >an incentive to do the review, in order for the commit to get done. > Ok, I'll take that point. But at the same time, you will have to acknowledge that sometimes, maintainers just commit a file without looking at it, cos they want to get it in, but don't have the time to look at it right now. In which case, there was a bottleneck for no particular reason. >In practice, it's thus very difficult to get volunteers to do post >reviewing, especially if they would have to figure out themselves that >the commit happened in the first place, and how to get the file to >review themselves afterwards. > If there's a maintainer, s/he'll be notified of the commit, and even of the module being in QA. But, are you really saying that, in general, maintainers don't know how to do a cvs diff? Well, if that really is the case, then maybe we have to do something about it? I'm all up for getting maintainers up to speed on everything that relates to the management of translations, and I believe they should know all these things. >4) Many teams have public mailing lists. This is a natural place to have >reviews on, since anyone can do a review, and the review doesn't depend >on a single person having to do it. Still, many problems are likely to >be catched. >Thus there's not necessarily the "getting stuck in somone's inbox" >problem you're talking of. > Well, as said, if there's a certain process already in place for a certain group, then I'd like to support it. I have nothing against putting up a po-file for review, as long as I know there are people reviewing it. I do not in the least object to things getting done this way. However, that doesn't make me change my opinion about the just implemented system being a good thing and helpful. >5) If someone commits an erroneous file, someone has to notice it. And >no, tracking CVS takes a nontrivial amount of time and effort. Not >everyone is employed by a company to deal with this kind of things on >their job time. Not many people consider having to constantly monitor >other people's commits and check them afterwards for errors a fun thing >to spend their time on. > Yes, and that someone may as well be the end-user who files a bug report. I don't think anyone expects us to be perfectionists, as long as we respond to bugs and fix them as they occur. If you do have a hundered hours of free time on your hand (if anyone does) you're invited to make the translation as good as possible. However, we have to live with what we've got. In the end, it's all about how much ressources you've got. And if you haven't got enough, you just have to trade off some quality. I don't believe that ressources can be created out of nothing and people volunteering their time, can be *made* to volunteer even more. Yes, I'd like to encourage them, but putting mandates on volunteers is, IMO, not the smartest thing to do, and could, in effect, have the opposite effect. And yes, I acknowledge that I could be wrong. And true, not many people consider having to constantly monitor other people's commits and check them afterwards for errors a fun thing to spend their time on, but now at least maintainers know that other people are working on their files, which wasn't the case before. Also, not many people consider having to review po-files and commit them afterwards a fun thing to do, and in how is that any different? What makes it so much more fun having the po-file, reviewing, and then committing it? >6) If someone commits an erroneous file, someone has to fix it. And no, >reverting things in CVS takes a nontrivial amount of time and effort. >Not everyone is employed by a company to deal with this kind of things >on their job time. Not many people consider having to revert other >people's stuff a fun thing to spend their time on. > Well, it's just in case it's a rainy day, I doubt it'll happen very often, most of the time, so I believe, you'd just fix some strings and commit, without even requiring to roll back anything. And I do believe it won't happen anymore than before. If someone commited an erroneous file before, somebody had to fix it. In how is that any different now? If someone sends an erroneous file, somebody has to fix it too. I'll take your point that people are more likely to fix things that are in their inbox than already commited to cvs, but given they can commit the file without looking at it, I don't see that big a difference. However, and I said that before, if a group wants to do things this way, and really only commit once the translations are reviewed and stamped, I want to support that too. >Out of these, the points 1, 2, 5, and 6 should be obvious to anyone with >any level of QA experience in free software. > Well, maybe I simply lack QA experience? Maybe I really don't understand that a safer car is better than an unsafe car? But maybe, just maybe, there are other issue to consider than a safe car being better than an unsafe car, like, for example, whether you've got the ressources to afford a safe car? Regards, Bernd >Christian > > >-- >Fedora-trans-list mailing list >Fedora-trans-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-trans-list > > -- Dr. Bernd R. Groh Phone : +61 7 3514 8114 Software Engineer (Localization) Fax : +61 7 3514 8199 Red Hat Asia-Pacific Mobile: +61 403 851 269 Disclaimer: http://apac.redhat.com/disclaimer/ From bgroh at redhat.com Thu Jul 8 02:46:23 2004 From: bgroh at redhat.com (Bernd Groh) Date: Thu, 08 Jul 2004 12:46:23 +1000 Subject: About the new Status Pages In-Reply-To: <1089240740.17538.642.camel@daim> References: <40E3654E.7050807@redhat.com> <1088943666.7077.907.camel@stina.menthos.com> <40EA32BB.9010901@redhat.com> <1089240740.17538.642.camel@daim> Message-ID: <40ECB57F.5040507@redhat.com> Christian, I'll just address some points here. Christian Rose schrieb: >tis 2004-07-06 klockan 07.03 skrev Bernd Groh: > > >>As said, and that's why I am a little surprised by your email, I am >>actually in favour of not just giving anyone cvs access for a certain >>language, if 1) the group wants it, and 2) somebody makes >>herself/himself accountable for such decision. If a language group >>wouldn't want to restrict cvs access to "newcomers", nobody of that >>language group would actually be willing to be accountable for such >>decision, or there isn't any language team in place yet, I do not see >>why I should not give someone of that language group cvs access. What is >>wrong with that model? If 1) the group wants it, and 2) somebody makes >>herself/himself accountable for such decision, I do agree completely >>that cvs access should be restricted, and the group should decide >>when/if it is time to give a "newcomer" cvs access. I've said the >>exactly same before, and I say it here again, just in case it wasn't >>entirely clear where I stand, though it should be. >> >> > >Ok. You still base your argument though on that it's difficult to be a >coordinator or find someone to be one. That's not my experience at all. >More on that below. > Ok. > > >[...] > > >>>>You say that wouldn't happen if you'd have a group and one >>>>coordinator to coordinate all translations of the group? For a small >>>>group that might be feasible, but if you have one coordinator and 70+ >>>>translators, things can get quite difficult to manage this way. Also, we >>>>would require the coordinator to be available at all time, we'd require >>>>the coordinator to make a decision, or we'd require 70 people to >>>>discuss about who's going to translate the file. >>>> >>>> >[...] > > >>>The first thing that struck me was the claim that there will be 70+ >>>translators for any single language. Believe me, the largest language >>>translation teams I know of aren't more than, say, a dozen to twenty >>>people for any project. >>> >>> >>I can only go by how many people sign up to be a translator for a >>certain language, and we have language groups with well above 70 >>translators. >> >> > >Ok, you count teams different than I do. Given your explanation above, >you count a team as everyone who has ever explained interest in a >particular language and/or subscribed to a mailing list. > >I count a team as roughly the group of active translators. By active I >meant those who have actually produced or updated at least one >translation in recent time, ie. not someone only lurking on a mailing >list, and not people that did their last translation update two years >ago. > >There can, and usually is, a big difference in numbers. > >For practical purposes, I consider the way of counting the active >contributors much more useful. Contribution counts. It's difficult to >get a qualified opinion from people that are silently lurking on a >mailing list, or (even worse) perhaps only posting noise to the list but >not actively contributing, be it in translations or reviews. > > > > >>>And then that's still an exceptionally huge >>>team; almost all of them are much smaller, like one to five people. So >>>giving an example of "70+ people" doesn't really look like it's even >>>remotely connected to reality. It looks like the figure is intentionally >>>blown out of proportion. >>> >>> >>Well, it's not, and it certainly shouldn't look that way. My apologies >>if it appeared as if I'd intentionally blow things out of proportion, I >>simply did a count. >> >> > >I'm sure you can count. So can I. The key point is the relevance of >those numbers. > >For Swedish Fedora translations, there are two active contributors: >G?ran and me. On the translation mailing list we use, there are on the >other hand 55 subscribers. I counted them. Granted, many of them I've >never seen posting to the list, and some are only contributing to other >projects, such as the TP and GNOME/KDE etc. >The people who are actively doing reviews are only a handful, a dozen at >best. > >And I know for a fact that this situation is not unique. On the >contrary, it's the common case to have a majority of silent bystanders >and lurkers on a public mailing list, who hardly have any effect >whatsoever on the daily actions and contributions, and often not even >the discussions. > > > > >>>Second, teams in practice usually annotate who is responsible for what >>>themselves, sometimes only with a simple spoken agreement, sometimes >>>with a list on a static web page, and sometimes even with more advanced >>>systems, similar to the current Fedora status pages. It usually depends >>>on the team's size and their structure what sort of method they want to >>>use and feel comfortable with. >>> >>> >[...] > > >>>even that there is a benefit for larger teams, because larger teams >>>usually already have this in place. This is not new. The reason you got >>>requests for this is probably because you haven't had a team policy in >>>the past, so team agreement didn't always apply. That's fine, but don't >>>make it sound like evidence of team agreement not working. >>> >>> >>Neither I said there is a benefit for larger teams, I simply said there >>could be, depending on how the team handles things. >> >> > >And for some teams it could be that there is no benefit at all, but >rather a drawback, since instead of handling this on their own they must >now have this system imposed on them, and keep having to ask you >whenever it doesn't suit them, and hope that you will both agree to the >change and have the time to do it. > Ok, noted. And since I'd like to avoid this, I'd like to know what these drawbacks are. Since I believe the page, in general, is helpful. If there are groups that have an established way of doing things, and the page really does keep them from doing it how they've been doing a good job in the past, then let's talk about it. I want to hear all these cases, in details. >>>Third, you make it sound like who's in charge of what usually changes >>>every day. >>> >>> >>How? By introducing a Maintainer and stating that a maintainer should be >>a "permanent" entity? >> >> > >You made an argument by claiming it was difficult for a dingle >coordinator to keep track of assignment changes, something I don't agree >with is necessarily true, except for the biggest teams. > No, I didn't. I said exactly what you've just said. >>>In fact, it's usually quite a static thing. When a person >>>starts to translate a module, he usually keeps maintaining it, unless >>>some unforeseen issue arises. Of course people do sometimes exchange >>>modules, but that's almost always the exception. If you study teams >>>empirically you'll find that almost all translators keep maintaining the >>>same modules they've done previously. So requests for changing module >>>maintainership is usually a rare thing. >>> >>> >>That's how it should be, and that's why I've said a Maintainer should be >>something "permanent". However, in our current reality, we do have to >>deal with more than one person working on one and the same module at the >>same time. Simply saying that it shouldn't be that way doesn't make it >>go away. Saying that it's because there aren't any teams and we >>shouldn't have done a, b, and c in the past, doesn't make it go away >>either. As said, I cannot change the past, all I can do is to try and >>better things from how they are now. All we did was adding visibility to >>what's going on, what was so wrong about that? >> >> > >Because you used this opportunity not to try to rectify the lack of >teams, but rather try to ensuring the lack of teams could be maintained >for the future, by not changing the policy but rather have the new >translation status pages make the policy even more prominent. > >And you're still not prepared to change the policy. > It's not up to me to change any policy, though I'm still not entirely sure what policy you are referring to. Could you please, and I do apologise for not having understood it yet, be more explicit. Is it true that you are referring to me not mandating teams and a coordinator for each language? Is that the policy you are referring to? It's an honest question. >>>Fourth, you claim that all members of the team would fight for >>>translating a new module, thus making the life of the coordinator >>>difficult. >>> >>> >>No, I don't. I can kind of see how you could get there, given I've said: >>"or we'd require 70 people to discuss about who's going to translate the >>file", but with this, I did not intend to say that members of a team >>would actually fight for translations, neither I was making any kind of >>claim, I simply meant to illustrate the responsibility a coordinator >>has, and the difficulties s/he could, in addition, face in a large team. >> >> > >Hypotethical speculations at best. > >I could also claim any organization shouldn't have a responsible person, >because there could be a danger of the members of the organization >disagreeing with eachother. How novel. > In organizations, on a voluntary base, responsible people are usually responsible, because they want to be responsible, or because other people in the organization have encouraged them to be responsible, and I do welcome that. I didn't say language groups shouldn't have a coordinator, or did I? In fact, I said I'd like every language group to have a coordinator , and maintainers, iff there is someone who wants to be a coordinator, or a maintainer. So, in how is that statement of yours even closely related to what I said? >>All that was part of me making the point that, even though we'd like to >>have coordinators for every team, we'd like such role to be entirely >>voluntary, and not mandatory in order for the entire system to work. >>That's all. Again, I didn't mean to say the coordinator model doesn't >>work, neither that our model is better, not even that we do not want to >>have coordinators, all I meant is that I do not wish to build a system >>that is dependent on a coordinator or a team of a certain structure >>being in place, but supports it iff that should be the case. >> >> >> >>>This is almost never the case. It's difficult to get >>>volunteers, and every volunteer can usually get all what they want in >>>terms of getting their hands dirty without stepping on someone else's >>>toes >>> >>> >>I'd say this depends on the language and the people involved in that >>particular language, in general, I'd tend to agree with you, though. >> >> >> >>>The problem is almost always the opposite -- to get volunteers to >>>work on a new module at all. Hence, the situation you describe with all >>>members of a team fighting for a particular module isn't the common case >>>at all. >>> >>> >>Christian, in fact, I do agree with you that it is hard to get good >>people taking on certain responsibilities, and this isn't just limited >>to translations, but even more so to maintaining modules and >>coordinating a language, or would you now disagree? Do you believe it is >>hard to get people working on a module, but actually easy to find >>maintainers, or even coordinators? I actually do agree with you, that, >>in general, it is hard to find either, and that exactly is why I don't >>want to build a system that is dependent on it. Why would you build a >>system that is dependent on something that, apparently, is hard to >>find? Why not simply support it if a given structure is in place or >>forms naturally, and voluntarily? Maybe it is just my opinion, but if >>nobody wants to be the coordinator of an entire language, I don't think >>the language should have one, though I'd hope it would be the case. >>Maybe I am wrong, but that's simply how I see things. >> >> > >You're still basing your argument on that it is difficult to find >coordinators. My experience is that it simply isn't. In my experience >it's sometimes even easier to find a coordinator, than someone willing >to do the actual work of translating modules, because the latter is >often much more work. :-) > Ok, you've said you'd come to that, so I'll keep listening. :-) But, there are a lot of people who'd prefer more work over more responsibility. ;-) Or is it the case that coordinators are simply unaware of their responsibilities? >For a one person team, being the coordinator is no extra work at all. > Well, agree. >For a small team (2 to 4 people), being a coordinator is basically just >a title. There's not much for the coordinator to do, other than noting >who does what, which usually doesn't change that often. > So, you wouldn't say the coordinator has to coordinate the review process and make sure all work actually gets reviewed? If coordinator is nothing but a title, what exactly was it for again? >For a bigger team, the noting of who does what is of course a bigger >challenge, and it grows further with the team size. >But here comes the beauty: When the team size grows, the more likely you >are to find someone who is willing to step up to do the work of >coordinating. Pick any group of ten people, and count the number of >times you'll get a group where not *anyone* would find it acceptable to >be the one who keeps note of who maintains what, and occasionally be the >one who has the final say on things. You're unlikely to get many such >groups. > Well, that's great! But again, who is accountable for the quality of the translations? Surely, everyone is responsible, but who is accountable? Whom can I blame if the translations aren't good or not done? It sounds like the coordinator, apart from sometimes having the last say, does nothing but keeping track of who does what. Well, that part our new system can do too. Wouldn't it make a great coordinator on its own? Or is there more to a coordinator than you let on here? >There's also another thing with bigger groups. Having an official >coordinator doesn't rule out the possibilities of delegating some of the >work to others, and the bigger the group is, you're then again more >likely to find people who can do those responsibilities. > >Given this and my own experience, I don't agree with it being hard to >find coordinators, and I agree even less with taking this claim to be >the foundation of a policy where you don't even *try* to have a >coordinator by default. > That's fine, we don't all have to agree. And, btw, I don't take anything for the foundation of any policy, I simply don't have enough reason to support a change in policy to what you consider the best policy. But, I do listen to what you're saying, and you may just convince me one day. You haven't yet though. And, about us not trying to have a coordinator by default, we've only just started, and our apologies if it'll take a little longer than you'd like, but our ressources are limited, and there's nothing I can do about it. >>>Trust me, it really isn't. Most >>>translators seem to be happy with and familiar enough to email >>>communication to be able to send short mails in their native tounge for >>>this to be a total non-issue. And, the assignments are almost always >>> >>> >>> >>We do have quite active mailing lists for some languages, and yes, with >>70+ subscribers (just to stick with that number, I could easily blow it >>even more out of proportion), and I doubt communicating via email in >>large and active mailing lists is an ideal situation. Again, I don't say >>it can't be done this way, neither I say our way is superior, I simply >>say that I prefer our way for mere reasons of scalability. That may as >>well be a non-issue, but not one I'd like to count on. >> >> > >You should leave it up to the language team to decide. No solution fits >every language team, as even you have pointed out. > Well, I had some really good feedback so far, so let's just see what happens. And, btw, I've addressed that very issue before. :) >And the team keeping track of the assignment coordination themselves >without having to bother you or anyone else in charge of the status >pages works *especially* well for smaller teams, so there's no reason it >shouldn't be the default. > >Let the teams who want it have the status pages assignment control, and >leave the rest of the teams to coordinate their work in whatever way >fits them best. > I believe that's a fair suggestion, and one I myself made before, on this very list. And I'm happy to open it up for discussion. >>>non-controversial, so there is rarely the big discussions you try to >>>make a point of. Almost all this communication is a two-piece, really >>>short one: "I will translate XYZ" and the reply "OK, noted". Again, you >>>blow the issue out of proportion, and the argument doesn't seem to be >>>based on reality. >>> >>> >>In my experience, it's a short email "I will translate abc", "I will >>translate bcd", no "Noted" then replies "is anyone translating def"? or >>"who is translating bgr", maybe "I have translated xrt", then "sorry, >>xrt is finished now", maybe "what is available?", "what can I >>translate?", and just scale that out a bit now, and make a good argument >>of why I should use email communication to manage who's doing what? You >>say this is not based on reality? Sorry, but this is the reality I am >>facing. Yes, true, assignment is most of the time non-controversial, and >>if you read what I wrote, you'll see that I never said otherwise. Given >>everyone knows what everyone else is doing, why translate what someone >>else is translating already? But, if I don't know, I don't know, and an >>email is easily missed too, especially if you get many. Of course, that >>is all blown out of proportion and not based on reality, right? Or is >>your reality the only reality and every other "reality" is just made up >>and blown out of proportion? >> >> > >No, I base my view on my six years of experience with translation and >translation coordination, both with smaller and bigger teams, and then >the coordination a whole translation project. > >If there's something single important thing I've learned then that's >that there is no single organizational structure and assignment policy >that fits every team. Some teams are large, some very small, and some >work for common, big languages spoken by hundreds of millions of people, >while others for smaller, perhaps even minority languages. > >The reality you describe is the one for a big team for a big language, >where there are many people involved and loosely organized, and many new >volunteers joining at the same time. This is certainly a truth, but only >one part of the truth. >There are many teams aswell where the situation is almost *completely* >the opposite, and where for example mail communication works just fine. > >The assignment control on the new translation status pages probably >works well for such a team you describe, but it probably at the same >time won't work very well for others, where it gets in the way of the >already established and efficient procedure. > Well taken. >Yet you want to squeeze all teams into using this by default. > No. I've even made the suggestion on this very list to put certain teams on exclude lists, so they don't have to go through the newly implemented process. I've made that suggestion as soon as I realised that the new system might actually conflict with the way some smaller teams are handling things. >My opinion is that it should be optional, and only used if there's an >explicit request to use it by the team. > Noted. What do others think? >>>And last but not least, you fail to answer the question why you think >>>translation is different enough from other forms of contributions, like >>>software patches, where this anarchistic, no-prior-review-needed policy >>>is definately not used. If you believe a mandated review and cooperation >>>policy is bad for contributions, then why does every other form of >>>significant contribution to a project require this? >>> >>> >>Well, naturally, the most important thing is that the system is stable >>and works properly, and not reviewing software patches couldn't ensure >>that. Of course, it is most important that the systems works, and be it >>only in english. Or would you rather have a swedish system that crashes >>regularly, than an english one that works properly? I am not the only >>one who would agree that the software working properly is more important >>than the translation being perfect, or do you really want to say that >>this isn't so in reality? >> >> > >This statement that anything that builds and doesn't crash is just fine >is so absurd from a QA point of view I won't even bother to respond. I >trust you have no prior experience with any QA or the real implications >and considerations of such processes, so I'll rest my case. > What statement that anything that builds and doesn't crash is just fine? Where did I say that? Well, maybe I need to illustrate what I meant. Let's say you've got a certain package, translated into 32 different languages. Now, a not reviewed software patch gets in, and it's so bad that it effects the entire package. As a result, it becomes unusable. Now, the package itself, and all 32 different translations of the package become useless. Same thing, for one particular translation. Let's say a translation for a particular language is all bad. Result? The package becomes unusable for that particular language, but, the package still works, does what it's supposed to do, and supports 31 different languages. Tell me, same thing? One just as bad as the other? Of course, I want to have all 32 languages usable, but if I've got limited ressources, I wouldn't think twice where to put them. Then again, it's prolly all because I haven't got any prior experience with QA, or the real implications and considerations of such processes, right? Yes, I rest my case too. Regards, Bernd >Christian > > > >-- >Fedora-trans-list mailing list >Fedora-trans-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-trans-list > > -- Dr. Bernd R. Groh Phone : +61 7 3514 8114 Software Engineer (Localization) Fax : +61 7 3514 8199 Red Hat Asia-Pacific Mobile: +61 403 851 269 Disclaimer: http://apac.redhat.com/disclaimer/ From sarahs at redhat.com Thu Jul 8 03:18:01 2004 From: sarahs at redhat.com (Sarah Wang) Date: Thu, 08 Jul 2004 13:18:01 +1000 Subject: The problems with free CVS committing In-Reply-To: <40ECA31A.4060301@redhat.com> References: <1087874101.17780.230.camel@sarah.brisbane.redhat.com> <200406221027.17982.rahal@arabeyes.org> <1087944558.4669.4086.camel@daim> <40D8D50F.8080505@redhat.com> <1088899522.7077.759.camel@stina.menthos.com> <40EA59F5.5060400@redhat.com> <1089128531.22067.53.camel@bree.local.net> <40EB3F74.3010107@redhat.com> <1089235920.17538.476.camel@daim> <40ECA31A.4060301@redhat.com> Message-ID: <1089256680.2257.10.camel@cpe-144-136-137-80.qld.bigpond.net.au> On Thu, 2004-07-08 at 11:27, Bernd Groh wrote: > >1) If the po file has syntactic errors, the software build will break. > >This will make software maintainers, many other contributors, and > >testers *very* unhappy. > > > > You mean the po-format, which should be taken care of, if you, for > example, use KBabel. Ok, agreed, would make me *very* unhappy too. I > believe a pre-commit step to simply check the format is ok should > suffice. Good idea. The pre-commit syntax check is already in place. If "msgfmt" of the po file produce errors, the commit is not allowed. Sarah From katzj at redhat.com Thu Jul 8 03:50:26 2004 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 07 Jul 2004 23:50:26 -0400 Subject: The problems with free CVS committing In-Reply-To: <1089256680.2257.10.camel@cpe-144-136-137-80.qld.bigpond.net.au> References: <1087874101.17780.230.camel@sarah.brisbane.redhat.com> <200406221027.17982.rahal@arabeyes.org> <1087944558.4669.4086.camel@daim> <40D8D50F.8080505@redhat.com> <1088899522.7077.759.camel@stina.menthos.com> <40EA59F5.5060400@redhat.com> <1089128531.22067.53.camel@bree.local.net> <40EB3F74.3010107@redhat.com> <1089235920.17538.476.camel@daim> <40ECA31A.4060301@redhat.com> <1089256680.2257.10.camel@cpe-144-136-137-80.qld.bigpond.net.au> Message-ID: <1089258626.31997.80.camel@bree.local.net> On Thu, 2004-07-08 at 13:18 +1000, Sarah Wang wrote: > The pre-commit syntax check is already in place. If "msgfmt" of the po > file produce errors, the commit is not allowed. Since when? I know I saw problems related to this in anaconda as recently as a week or two ago... Jeremy From sarahs at redhat.com Thu Jul 8 04:05:20 2004 From: sarahs at redhat.com (Sarah Wang) Date: Thu, 08 Jul 2004 14:05:20 +1000 Subject: The problems with free CVS committing In-Reply-To: <1089258626.31997.80.camel@bree.local.net> References: <1087874101.17780.230.camel@sarah.brisbane.redhat.com> <200406221027.17982.rahal@arabeyes.org> <1087944558.4669.4086.camel@daim> <40D8D50F.8080505@redhat.com> <1088899522.7077.759.camel@stina.menthos.com> <40EA59F5.5060400@redhat.com> <1089128531.22067.53.camel@bree.local.net> <40EB3F74.3010107@redhat.com> <1089235920.17538.476.camel@daim> <40ECA31A.4060301@redhat.com> <1089256680.2257.10.camel@cpe-144-136-137-80.qld.bigpond.net.au> <1089258626.31997.80.camel@bree.local.net> Message-ID: <1089259520.2257.14.camel@cpe-144-136-137-80.qld.bigpond.net.au> You meant those newly added po files with "Project-Id-Version: PACKAGE VERSION\n" unchanged? "msgfmt" will not produce error message because of it. the Pre commit check only stop committing files with "msgfmt" errors. Sarah On Thu, 2004-07-08 at 13:50, Jeremy Katz wrote: > On Thu, 2004-07-08 at 13:18 +1000, Sarah Wang wrote: > > The pre-commit syntax check is already in place. If "msgfmt" of the po > > file produce errors, the commit is not allowed. > > Since when? I know I saw problems related to this in anaconda as > recently as a week or two ago... > > Jeremy > > > -- > Fedora-trans-list mailing list > Fedora-trans-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-trans-list From bgroh at redhat.com Thu Jul 8 04:06:00 2004 From: bgroh at redhat.com (Bernd Groh) Date: Thu, 08 Jul 2004 14:06:00 +1000 Subject: About the new Status Pages In-Reply-To: <40ECB57F.5040507@redhat.com> References: <40E3654E.7050807@redhat.com> <1088943666.7077.907.camel@stina.menthos.com> <40EA32BB.9010901@redhat.com> <1089240740.17538.642.camel@daim> <40ECB57F.5040507@redhat.com> Message-ID: <40ECC828.8000102@redhat.com> I've just realised that I said something that was not entirely correct. >> Yet you want to squeeze all teams into using this by default. >> > > No. I've even made the suggestion on this very list to put certain > teams on exclude lists, so they don't have to go through the newly > implemented process. I've made that suggestion as soon as I realised > that the new system might actually conflict with the way some smaller > teams are handling things. I did not make the suggestion to not make this the default, in was the opposite. I wanted to leave it the default, but wanted to allow teams to be excluded from the process, as such, teams wanting to be excluded from the process would have to request it. My apologies. And no, I didn't want to squeeze all teams through that, I actually and honestly believed we were doing the right thing. If it had such a negative effect on some existing teams, I'm happy to do something about it. Thanks, Bernd From katzj at redhat.com Thu Jul 8 04:26:09 2004 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 08 Jul 2004 00:26:09 -0400 Subject: The problems with free CVS committing In-Reply-To: <1089259520.2257.14.camel@cpe-144-136-137-80.qld.bigpond.net.au> References: <1087874101.17780.230.camel@sarah.brisbane.redhat.com> <200406221027.17982.rahal@arabeyes.org> <1087944558.4669.4086.camel@daim> <40D8D50F.8080505@redhat.com> <1088899522.7077.759.camel@stina.menthos.com> <40EA59F5.5060400@redhat.com> <1089128531.22067.53.camel@bree.local.net> <40EB3F74.3010107@redhat.com> <1089235920.17538.476.camel@daim> <40ECA31A.4060301@redhat.com> <1089256680.2257.10.camel@cpe-144-136-137-80.qld.bigpond.net.au> <1089258626.31997.80.camel@bree.local.net> <1089259520.2257.14.camel@cpe-144-136-137-80.qld.bigpond.net.au> Message-ID: <1089260769.31997.103.camel@bree.local.net> On Thu, 2004-07-08 at 14:05 +1000, Sarah Wang wrote: > You meant those newly added po files with "Project-Id-Version: PACKAGE > VERSION\n" unchanged? "msgfmt" will not produce error message because of > it. the Pre commit check only stop committing files with "msgfmt" > errors. No, there were actual msgfmt errors as well with format strings not matching up correctly. Jeremy From bgroh at redhat.com Thu Jul 8 04:33:51 2004 From: bgroh at redhat.com (Bernd Groh) Date: Thu, 08 Jul 2004 14:33:51 +1000 Subject: The problems with free CVS committing In-Reply-To: <1089260769.31997.103.camel@bree.local.net> References: <1087874101.17780.230.camel@sarah.brisbane.redhat.com> <200406221027.17982.rahal@arabeyes.org> <1087944558.4669.4086.camel@daim> <40D8D50F.8080505@redhat.com> <1088899522.7077.759.camel@stina.menthos.com> <40EA59F5.5060400@redhat.com> <1089128531.22067.53.camel@bree.local.net> <40EB3F74.3010107@redhat.com> <1089235920.17538.476.camel@daim> <40ECA31A.4060301@redhat.com> <1089256680.2257.10.camel@cpe-144-136-137-80.qld.bigpond.net.au> <1089258626.31997.80.camel@bree.local.net> <1089259520.2257.14.camel@cpe-144-136-137-80.qld.bigpond.net.au> <1089260769.31997.103.camel@bree.local.net> Message-ID: <40ECCEAF.8040504@redhat.com> Jeremy Katz schrieb: >On Thu, 2004-07-08 at 14:05 +1000, Sarah Wang wrote: > > >>You meant those newly added po files with "Project-Id-Version: PACKAGE >>VERSION\n" unchanged? "msgfmt" will not produce error message because of >>it. the Pre commit check only stop committing files with "msgfmt" >>errors. >> >> > >No, there were actual msgfmt errors as well with format strings not >matching up correctly. > If that's the case, we really need to fix this. Bernd > >Jeremy > > >-- >Fedora-trans-list mailing list >Fedora-trans-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-trans-list > > -- Dr. Bernd R. Groh Phone : +61 7 3514 8114 Software Engineer (Localization) Fax : +61 7 3514 8199 Red Hat Asia-Pacific Mobile: +61 403 851 269 Disclaimer: http://apac.redhat.com/disclaimer/ From sarahs at redhat.com Thu Jul 8 05:13:56 2004 From: sarahs at redhat.com (Sarah Wang) Date: Thu, 08 Jul 2004 15:13:56 +1000 Subject: The problems with free CVS committing In-Reply-To: <40ECCEAF.8040504@redhat.com> References: <1087874101.17780.230.camel@sarah.brisbane.redhat.com> <200406221027.17982.rahal@arabeyes.org> <1087944558.4669.4086.camel@daim> <40D8D50F.8080505@redhat.com> <1088899522.7077.759.camel@stina.menthos.com> <40EA59F5.5060400@redhat.com> <1089128531.22067.53.camel@bree.local.net> <40EB3F74.3010107@redhat.com> <1089235920.17538.476.camel@daim> <40ECA31A.4060301@redhat.com> <1089256680.2257.10.camel@cpe-144-136-137-80.qld.bigpond.net.au> <1089258626.31997.80.camel@bree.local.net> <1089259520.2257.14.camel@cpe-144-136-137-80.qld.bigpond.net.au> <1089260769.31997.103.camel@bree.local.net> <40ECCEAF.8040504@redhat.com> Message-ID: <1089263636.2257.21.camel@cpe-144-136-137-80.qld.bigpond.net.au> On Thu, 2004-07-08 at 14:33, Bernd Groh wrote: > >No, there were actual msgfmt errors as well with format strings not > >matching up correctly. > > > > If that's the case, we really need to fix this. > Totally agree. I'm not aware of any files with msgfmt errors being committed. I'm speaking from my own experience. Apart from msgfmt errors and "Project-id" line, I'd suggest "encoding" to be checked before committing as well. I understand all software po files are now using "UTF-8". Jeremy, any other things that may break a package that we need to do a pre-commit check? Sarah From keld at dkuug.dk Thu Jul 8 10:16:35 2004 From: keld at dkuug.dk (Keld =?iso-8859-1?Q?J=F8rn?= Simonsen) Date: Thu, 8 Jul 2004 12:16:35 +0200 Subject: Annoucement: New translation status page is installed In-Reply-To: <40EC8C0B.1010103@redhat.com> References: <1087874101.17780.230.camel@sarah.brisbane.redhat.com> <200406221027.17982.rahal@arabeyes.org> <1087944558.4669.4086.camel@daim> <40D8D50F.8080505@redhat.com> <1088899522.7077.759.camel@stina.menthos.com> <40EA59F5.5060400@redhat.com> <1089232620.17538.361.camel@daim> <40EC8C0B.1010103@redhat.com> Message-ID: <20040708101635.GB18913@rap.rap.dk> Hi, I dont get this new arrangement. I understand that with the new setup other people can steal the ownership of the translation files that I have done, if there are a few translations that have not been done for some days. That is not very desirable. I have maintained fedora7redhat translations for Danish for a couple of years now, and they have always been fully translated for each release. For the sake of the users it is better that there is an experienced translator that can assure consistency of the translations, than to get somebody afresh to do occational translations. It also breaks tradition in the open source community that one person "owns" maintenance of a file/project until it is given up, or a longer period of bad maintenance has occurred. Best regards keld From a.t.meinen at chello.nl Thu Jul 8 10:37:29 2004 From: a.t.meinen at chello.nl (Tino Meinen) Date: Thu, 08 Jul 2004 12:37:29 +0200 Subject: The problems with free CVS committing In-Reply-To: <1089263636.2257.21.camel@cpe-144-136-137-80.qld.bigpond.net.au> References: <1087874101.17780.230.camel@sarah.brisbane.redhat.com> <200406221027.17982.rahal@arabeyes.org> <1087944558.4669.4086.camel@daim> <40D8D50F.8080505@redhat.com> <1088899522.7077.759.camel@stina.menthos.com> <40EA59F5.5060400@redhat.com> <1089128531.22067.53.camel@bree.local.net> <40EB3F74.3010107@redhat.com> <1089235920.17538.476.camel@daim> <40ECA31A.4060301@redhat.com> <1089256680.2257.10.camel@cpe-144-136-137-80.qld.bigpond.net.au> <1089258626.31997.80.camel@bree.local.net> <1089259520.2257.14.camel@cpe-144-136-137-80.qld.bigpond.net.au> <1089260769.31997.103.camel@bree.local.net> <40ECCEAF.8040504@redhat.com> <1089263636.2257.21.camel@cpe-144-136-137-80.qld.bigpond.net.au> Message-ID: <1089283049.3336.2.camel@a141159.upc-a.chello.nl> Op do 08-07-2004, om 07:13 schreef Sarah Wang: > Apart from msgfmt errors and "Project-id" line, I'd suggest "encoding" > to be checked before committing as well. I understand all software po > files are now using "UTF-8". Really? Even the anaconda files? In the past UTF-8 was not allowed because of the text based installs. So is this now changed? Tino Meinen From katzj at redhat.com Thu Jul 8 15:59:03 2004 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 08 Jul 2004 11:59:03 -0400 Subject: The problems with free CVS committing In-Reply-To: <1089283049.3336.2.camel@a141159.upc-a.chello.nl> References: <1087874101.17780.230.camel@sarah.brisbane.redhat.com> <200406221027.17982.rahal@arabeyes.org> <1087944558.4669.4086.camel@daim> <40D8D50F.8080505@redhat.com> <1088899522.7077.759.camel@stina.menthos.com> <40EA59F5.5060400@redhat.com> <1089128531.22067.53.camel@bree.local.net> <40EB3F74.3010107@redhat.com> <1089235920.17538.476.camel@daim> <40ECA31A.4060301@redhat.com> <1089256680.2257.10.camel@cpe-144-136-137-80.qld.bigpond.net.au> <1089258626.31997.80.camel@bree.local.net> <1089259520.2257.14.camel@cpe-144-136-137-80.qld.bigpond.net.au> <1089260769.31997.103.camel@bree.local.net> <40ECCEAF.8040504@redhat.com> <1089263636.2257.21.camel@cpe-144-136-137-80.qld.bigpond.net.au> <1089283049.3336.2.camel@a141159.upc-a.chello.nl> Message-ID: <1089302343.2910.4.camel@bree.local.net> On Thu, 2004-07-08 at 12:37 +0200, Tino Meinen wrote: > Op do 08-07-2004, om 07:13 schreef Sarah Wang: > > Apart from msgfmt errors and "Project-id" line, I'd suggest "encoding" > > to be checked before committing as well. I understand all software po > > files are now using "UTF-8". > > Really? Even the anaconda files? In the past UTF-8 was not allowed > because of the text based installs. So is this now changed? Yes. It changed at least a year ago, maybe a little bit more now. Jeremy From katzj at redhat.com Thu Jul 8 16:01:01 2004 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 08 Jul 2004 12:01:01 -0400 Subject: The problems with free CVS committing In-Reply-To: <1089263636.2257.21.camel@cpe-144-136-137-80.qld.bigpond.net.au> References: <1087874101.17780.230.camel@sarah.brisbane.redhat.com> <200406221027.17982.rahal@arabeyes.org> <1087944558.4669.4086.camel@daim> <40D8D50F.8080505@redhat.com> <1088899522.7077.759.camel@stina.menthos.com> <40EA59F5.5060400@redhat.com> <1089128531.22067.53.camel@bree.local.net> <40EB3F74.3010107@redhat.com> <1089235920.17538.476.camel@daim> <40ECA31A.4060301@redhat.com> <1089256680.2257.10.camel@cpe-144-136-137-80.qld.bigpond.net.au> <1089258626.31997.80.camel@bree.local.net> <1089259520.2257.14.camel@cpe-144-136-137-80.qld.bigpond.net.au> <1089260769.31997.103.camel@bree.local.net> <40ECCEAF.8040504@redhat.com> <1089263636.2257.21.camel@cpe-144-136-137-80.qld.bigpond.net.au> Message-ID: <1089302461.2910.6.camel@bree.local.net> On Thu, 2004-07-08 at 15:13 +1000, Sarah Wang wrote: > On Thu, 2004-07-08 at 14:33, Bernd Groh wrote: > > >No, there were actual msgfmt errors as well with format strings not > > >matching up correctly. > > > > > > > If that's the case, we really need to fix this. > > > Totally agree. I'm not aware of any files with msgfmt errors being > committed. I'm speaking from my own experience. See revision 1.67 of anaconda/zh_CN.po > Apart from msgfmt errors and "Project-id" line, I'd suggest "encoding" > to be checked before committing as well. I understand all software po > files are now using "UTF-8". > > Jeremy, any other things that may break a package that we need to do a > pre-commit check? Those are the things I can think of having hit in the past Jeremy From alan at redhat.com Thu Jul 8 18:26:50 2004 From: alan at redhat.com (Alan Cox) Date: Thu, 8 Jul 2004 14:26:50 -0400 Subject: The problems with free CVS committing In-Reply-To: <1089258626.31997.80.camel@bree.local.net> References: <1087944558.4669.4086.camel@daim> <40D8D50F.8080505@redhat.com> <1088899522.7077.759.camel@stina.menthos.com> <40EA59F5.5060400@redhat.com> <1089128531.22067.53.camel@bree.local.net> <40EB3F74.3010107@redhat.com> <1089235920.17538.476.camel@daim> <40ECA31A.4060301@redhat.com> <1089256680.2257.10.camel@cpe-144-136-137-80.qld.bigpond.net.au> <1089258626.31997.80.camel@bree.local.net> Message-ID: <20040708182650.GA8392@devserv.devel.redhat.com> On Wed, Jul 07, 2004 at 11:50:26PM -0400, Jeremy Katz wrote: > On Thu, 2004-07-08 at 13:18 +1000, Sarah Wang wrote: > > The pre-commit syntax check is already in place. If "msgfmt" of the po > > file produce errors, the commit is not allowed. > > Since when? I know I saw problems related to this in anaconda as > recently as a week or two ago... msgfmt checks are incomplete but it does catch some of the more glaring screwups From bgroh at redhat.com Thu Jul 8 22:43:18 2004 From: bgroh at redhat.com (Bernd Groh) Date: Fri, 09 Jul 2004 08:43:18 +1000 Subject: Annoucement: New translation status page is installed In-Reply-To: <20040708101635.GB18913@rap.rap.dk> References: <1087874101.17780.230.camel@sarah.brisbane.redhat.com> <200406221027.17982.rahal@arabeyes.org> <1087944558.4669.4086.camel@daim> <40D8D50F.8080505@redhat.com> <1088899522.7077.759.camel@stina.menthos.com> <40EA59F5.5060400@redhat.com> <1089232620.17538.361.camel@daim> <40EC8C0B.1010103@redhat.com> <20040708101635.GB18913@rap.rap.dk> Message-ID: <40EDCE06.6050304@redhat.com> Hi Keld, Keld J?rn Simonsen schrieb: >Hi, > >I dont get this new arrangement. I understand that with the new setup >other people can steal the ownership of the translation files that I >have done, if there are a few translations that have not been done for >some days. That is not very desirable. > We haven't really changed all that much. Previously, everyone could commit at any time. As such, everyone could "steal" anyones translations at all time, and worse, nobody even knew about it. I, personally, found that not to be very desireable. We are now in the process of making things more desireable. As a first step, we've added a layer of visibility to how things are. So, even though somebody else might have taken modules you've translated before, and you didn't know about it, what has changed is that now, you do know about it, since everyone can see who's currently doing what. > I have maintained fedora7redhat >translations for Danish for a couple of years now, and they have always >been fully translated for each release. For the sake of the users it is >better that there is an experienced translator that can assure >consistency of the translations, than to get somebody afresh to do >occational translations. > Completely agree. That's why we've also introduced a Maintainer. A Translator doesn't really "own" a file, the Maintainer does. If you've been translating, in fact, maintaining a certain module in the past, we'd make you the Maintainer of that module. This gives you an even greater visibility into who's currently working on the file, since you'll be notified if someone takes the module or commits the file. As Maintainer, you are allowed to step in at any time, and release the module from the current translator, and either let somebody else take it, or take it yourself. Previously, there was no way for you to keep another translator from committing a file you've been working on, and worse, you wouldn't even have known about it. >It also breaks tradition in the open source community that one person >"owns" maintenance of a file/project until it is given up, or a longer >period of bad maintenance has occurred. > That is the same with a Maintainer in our case. But, even though only one person "owns" a file, several other people can "contribute" to the file. In order to reduce conflicts, we allow only one other person to contribute at any given time, and we allow the Maintainer to cancel someones contributions at any time. There's still a lot we need to do, but that's how we've started. Best Regards, Bernd >Best regards >keld > > >-- >Fedora-trans-list mailing list >Fedora-trans-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-trans-list > > -- Dr. Bernd R. Groh Phone : +61 7 3514 8114 Software Engineer (Localization) Fax : +61 7 3514 8199 Red Hat Asia-Pacific Mobile: +61 403 851 269 Disclaimer: http://apac.redhat.com/disclaimer/ From sarahs at redhat.com Thu Jul 8 23:12:05 2004 From: sarahs at redhat.com (Sarah Wang) Date: Fri, 09 Jul 2004 09:12:05 +1000 Subject: The problems with free CVS committing In-Reply-To: <1089302461.2910.6.camel@bree.local.net> References: <1087874101.17780.230.camel@sarah.brisbane.redhat.com> <200406221027.17982.rahal@arabeyes.org> <1087944558.4669.4086.camel@daim> <40D8D50F.8080505@redhat.com> <1088899522.7077.759.camel@stina.menthos.com> <40EA59F5.5060400@redhat.com> <1089128531.22067.53.camel@bree.local.net> <40EB3F74.3010107@redhat.com> <1089235920.17538.476.camel@daim> <40ECA31A.4060301@redhat.com> <1089256680.2257.10.camel@cpe-144-136-137-80.qld.bigpond.net.au> <1089258626.31997.80.camel@bree.local.net> <1089259520.2257.14.camel@cpe-144-136-137-80.qld.bigpond.net.au> <1089260769.31997.103.camel@bree.local.net> <40ECCEAF.8040504@redhat.com> <1089263636.2257.21.camel@cpe-144-136-137-80.qld.bigpond.net.au> <1089302461.2910.6.camel@bree.local.net> Message-ID: <1089328324.2108.4.camel@sarah.brisbane.redhat.com> > See revision 1.67 of anaconda/zh_CN.po [sarahs at sarah anaconda]$ cvs up -r1.67 zh_CN.po Enter passphrase for key '/home/sarahs/.ssh/id_dsa': P zh_CN.po [sarahs at sarah anaconda]$ msgfmt -v -o /dev/null zh_CN.po 1499 translated messages. ? Sarah From bgroh at redhat.com Fri Jul 9 00:56:47 2004 From: bgroh at redhat.com (Bernd Groh) Date: Fri, 09 Jul 2004 10:56:47 +1000 Subject: The problems with free CVS committing In-Reply-To: <20040708182650.GA8392@devserv.devel.redhat.com> References: <1087944558.4669.4086.camel@daim> <40D8D50F.8080505@redhat.com> <1088899522.7077.759.camel@stina.menthos.com> <40EA59F5.5060400@redhat.com> <1089128531.22067.53.camel@bree.local.net> <40EB3F74.3010107@redhat.com> <1089235920.17538.476.camel@daim> <40ECA31A.4060301@redhat.com> <1089256680.2257.10.camel@cpe-144-136-137-80.qld.bigpond.net.au> <1089258626.31997.80.camel@bree.local.net> <20040708182650.GA8392@devserv.devel.redhat.com> Message-ID: <40EDED4F.5060400@redhat.com> Alan Cox schrieb: >On Wed, Jul 07, 2004 at 11:50:26PM -0400, Jeremy Katz wrote: > > >>On Thu, 2004-07-08 at 13:18 +1000, Sarah Wang wrote: >> >> >>>The pre-commit syntax check is already in place. If "msgfmt" of the po >>>file produce errors, the commit is not allowed. >>> >>> >>Since when? I know I saw problems related to this in anaconda as >>recently as a week or two ago... >> >> > >msgfmt checks are incomplete but it does catch some of the more glaring >screwups > If there are still problems with files where msgfmt doesn't produce any errors, maybe we can extend the pre-commit check, to really cover everything that could cause a problem? Bernd > > >-- >Fedora-trans-list mailing list >Fedora-trans-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-trans-list > > -- Dr. Bernd R. Groh Phone : +61 7 3514 8114 Software Engineer (Localization) Fax : +61 7 3514 8199 Red Hat Asia-Pacific Mobile: +61 403 851 269 Disclaimer: http://apac.redhat.com/disclaimer/ From katzj at redhat.com Fri Jul 9 03:13:09 2004 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 08 Jul 2004 23:13:09 -0400 Subject: The problems with free CVS committing In-Reply-To: <1089328324.2108.4.camel@sarah.brisbane.redhat.com> References: <1087874101.17780.230.camel@sarah.brisbane.redhat.com> <200406221027.17982.rahal@arabeyes.org> <1087944558.4669.4086.camel@daim> <40D8D50F.8080505@redhat.com> <1088899522.7077.759.camel@stina.menthos.com> <40EA59F5.5060400@redhat.com> <1089128531.22067.53.camel@bree.local.net> <40EB3F74.3010107@redhat.com> <1089235920.17538.476.camel@daim> <40ECA31A.4060301@redhat.com> <1089256680.2257.10.camel@cpe-144-136-137-80.qld.bigpond.net.au> <1089258626.31997.80.camel@bree.local.net> <1089259520.2257.14.camel@cpe-144-136-137-80.qld.bigpond.net.au> <1089260769.31997.103.camel@bree.local.net> <40ECCEAF.8040504@redhat.com> <1089263636.2257.21.camel@cpe-144-136-137-80.qld.bigpond.net.au> <1089302461.2910.6.camel@bree.local.net> <1089328324.2108.4.camel@sarah.brisbane.redhat.com> Message-ID: <1089342789.5368.4.camel@bree.local.net> On Fri, 2004-07-09 at 09:12 +1000, Sarah Wang wrote: > > See revision 1.67 of anaconda/zh_CN.po > > [sarahs at sarah anaconda]$ cvs up -r1.67 zh_CN.po > Enter passphrase for key '/home/sarahs/.ssh/id_dsa': > P zh_CN.po > [sarahs at sarah anaconda]$ msgfmt -v -o /dev/null zh_CN.po > 1499 translated messages. Add --check (or at least --check-format). Otherwise, you don't get checking for format strings matching between the msgid and the translated string. Jeremy From sarahs at redhat.com Fri Jul 9 07:16:27 2004 From: sarahs at redhat.com (Sarah Wang) Date: Fri, 09 Jul 2004 17:16:27 +1000 Subject: The problems with free CVS committing In-Reply-To: <1089342789.5368.4.camel@bree.local.net> References: <1087874101.17780.230.camel@sarah.brisbane.redhat.com> <200406221027.17982.rahal@arabeyes.org> <1087944558.4669.4086.camel@daim> <40D8D50F.8080505@redhat.com> <1088899522.7077.759.camel@stina.menthos.com> <40EA59F5.5060400@redhat.com> <1089128531.22067.53.camel@bree.local.net> <40EB3F74.3010107@redhat.com> <1089235920.17538.476.camel@daim> <40ECA31A.4060301@redhat.com> <1089256680.2257.10.camel@cpe-144-136-137-80.qld.bigpond.net.au> <1089258626.31997.80.camel@bree.local.net> <1089259520.2257.14.camel@cpe-144-136-137-80.qld.bigpond.net.au> <1089260769.31997.103.camel@bree.local.net> <40ECCEAF.8040504@redhat.com> <1089263636.2257.21.camel@cpe-144-136-137-80.qld.bigpond.net.au> <1089302461.2910.6.camel@bree.local.net> <1089328324.2108.4.camel@sarah.brisbane.redhat.com> <1089342789.5368.4.camel@bree.local.net> Message-ID: <1089357387.2092.27.camel@sarah.brisbane.redhat.com> On Fri, 2004-07-09 at 13:13, Jeremy Katz wrote: > On Fri, 2004-07-09 at 09:12 +1000, Sarah Wang wrote: > > > See revision 1.67 of anaconda/zh_CN.po > > > > [sarahs at sarah anaconda]$ cvs up -r1.67 zh_CN.po > > Enter passphrase for key '/home/sarahs/.ssh/id_dsa': > > P zh_CN.po > > [sarahs at sarah anaconda]$ msgfmt -v -o /dev/null zh_CN.po > > 1499 translated messages. > > Add --check (or at least --check-format). Otherwise, you don't get > checking for format strings matching between the msgid and the > translated string. My apologies. Sarah From keld at dkuug.dk Fri Jul 9 09:59:43 2004 From: keld at dkuug.dk (Keld =?iso-8859-1?Q?J=F8rn?= Simonsen) Date: Fri, 9 Jul 2004 11:59:43 +0200 Subject: Annoucement: New translation status page is installed In-Reply-To: <40EDCE06.6050304@redhat.com> References: <1087874101.17780.230.camel@sarah.brisbane.redhat.com> <200406221027.17982.rahal@arabeyes.org> <1087944558.4669.4086.camel@daim> <40D8D50F.8080505@redhat.com> <1088899522.7077.759.camel@stina.menthos.com> <40EA59F5.5060400@redhat.com> <1089232620.17538.361.camel@daim> <40EC8C0B.1010103@redhat.com> <20040708101635.GB18913@rap.rap.dk> <40EDCE06.6050304@redhat.com> Message-ID: <20040709095943.GB17486@rap.rap.dk> On Fri, Jul 09, 2004 at 08:43:18AM +1000, Bernd Groh wrote: > Hi Keld, > > Keld J?rn Simonsen schrieb: > > >I have maintained fedora7redhat > >translations for Danish for a couple of years now, and they have always > >been fully translated for each release. For the sake of the users it is > >better that there is an experienced translator that can assure > >consistency of the translations, than to get somebody afresh to do > >occational translations. > > > > Completely agree. That's why we've also introduced a Maintainer. A > Translator doesn't really "own" a file, the Maintainer does. If you've > been translating, in fact, maintaining a certain module in the past, > we'd make you the Maintainer of that module. This gives you an even > greater visibility into who's currently working on the file, since > you'll be notified if someone takes the module or commits the file. As > Maintainer, you are allowed to step in at any time, and release the > module from the current translator, and either let somebody else take > it, or take it yourself. Previously, there was no way for you to keep > another translator from committing a file you've been working on, and > worse, you wouldn't even have known about it. OK, so I will stand as the maintainer of all the modules that I have translated till now? best regards keld From alan at redhat.com Fri Jul 9 16:50:07 2004 From: alan at redhat.com (Alan Cox) Date: Fri, 9 Jul 2004 12:50:07 -0400 Subject: The problems with free CVS committing In-Reply-To: <40EDED4F.5060400@redhat.com> References: <1088899522.7077.759.camel@stina.menthos.com> <40EA59F5.5060400@redhat.com> <1089128531.22067.53.camel@bree.local.net> <40EB3F74.3010107@redhat.com> <1089235920.17538.476.camel@daim> <40ECA31A.4060301@redhat.com> <1089256680.2257.10.camel@cpe-144-136-137-80.qld.bigpond.net.au> <1089258626.31997.80.camel@bree.local.net> <20040708182650.GA8392@devserv.devel.redhat.com> <40EDED4F.5060400@redhat.com> Message-ID: <20040709165007.GC7379@devserv.devel.redhat.com> On Fri, Jul 09, 2004 at 10:56:47AM +1000, Bernd Groh wrote: > >msgfmt checks are incomplete but it does catch some of the more glaring > >screwups > > > > If there are still problems with files where msgfmt doesn't produce any > errors, maybe we can extend the pre-commit check, to really cover > everything that could cause a problem? It will never cover everything - for example Evolution has strings where an incorrect new string in the .po file will crash Evolution but the .po file will by any test itself be valid From frolix68 at yahoo.gr Fri Jul 9 18:29:24 2004 From: frolix68 at yahoo.gr (=?iso-8859-7?q?Nikos=20Charonitakis?=) Date: Fri, 9 Jul 2004 19:29:24 +0100 (BST) Subject: The problems with free CVS committing In-Reply-To: <20040709165007.GC7379@devserv.devel.redhat.com> Message-ID: <20040709182924.20932.qmail@web40001.mail.yahoo.com> --- Alan Cox ??????: > On Fri, Jul 09, 2004 at 10:56:47AM +1000, Bernd Groh > wrote: > > >msgfmt checks are incomplete but it does catch > some of the more glaring > > >screwups > > > > > > > If there are still problems with files where > msgfmt doesn't produce any > > errors, maybe we can extend the pre-commit check, > to really cover > > everything that could cause a problem? > > It will never cover everything - for example > Evolution has strings where > an incorrect new string in the .po file will crash > Evolution but the .po file > will by any test itself be valid can you give an example of such an error string? what's the "scpecial" thing about it? > > > -- > Fedora-trans-list mailing list > Fedora-trans-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-trans-list > ____________________________________________________________ Do You Yahoo!? ????????? ?? ?????? @yahoo.gr ????????? ??? ??? http://www.otenet.gr From alan at redhat.com Sat Jul 10 13:26:18 2004 From: alan at redhat.com (Alan Cox) Date: Sat, 10 Jul 2004 09:26:18 -0400 Subject: The problems with free CVS committing In-Reply-To: <20040709182924.20932.qmail@web40001.mail.yahoo.com> References: <20040709165007.GC7379@devserv.devel.redhat.com> <20040709182924.20932.qmail@web40001.mail.yahoo.com> Message-ID: <20040710132618.GA15163@devserv.devel.redhat.com> On Fri, Jul 09, 2004 at 07:29:24PM +0100, Nikos Charonitakis wrote: > can you give an example of such an error > string? > what's the "scpecial" thing about it? Some of the strings are used solely for internal stuff (gtk has a much clearer example - a string which indicates left->right or right->left rendering). Several applications have strings to translate of the form "%-8s blah" and while msgfmt will accept "blah %8s" as valid and it is valid .po it may break assumptions in the app only documented in comments in the po file. These cases are rare fortunately From josep at imatge-sintetica.com Sun Jul 11 00:03:55 2004 From: josep at imatge-sintetica.com (Josep Puigdemont) Date: Sun, 11 Jul 2004 02:03:55 +0200 Subject: About the new Status Pages In-Reply-To: <40E3654E.7050807@redhat.com> References: <40E3654E.7050807@redhat.com> Message-ID: <1089504235.1146.96.camel@phobos> On Thu, 2004-07-01 at 03:13, Bernd Groh wrote: > support coordinators? Coordinators of small teams are invited to apply > for maintainership of all modules of a certain language. In general, and > if there are no objections from other members within the same language > group, this will be granted. For large teams, it may be better to split If no one objects to it, I'd like to apply for coordinator of the Catalan (ca) translation team, or for maintainership of all modules of ca. I'd appreciate if new Catalan translators willing to collaborate were pointed to: http://www.softcatala.org/projectes/fedora/ (provided this is possible :) We are a team of 10-15 members, with 3 or 4 actively translating and some others helping a lot with reviews and occasionally with translations. We've been coordinating ourselves without a problem through our own list at fedora at softcatala.net (CC'd). Since FC2 beta versions we've been working on the translation, and I've been committing translations on behalf of other team members. Regards, Josep Puigdemont ----------- Have you visited Forum Barcelona 2004 yet? http://www.barcelona2004.org/ From josep at imatge-sintetica.com Sun Jul 11 00:55:40 2004 From: josep at imatge-sintetica.com (Josep Puigdemont) Date: Sun, 11 Jul 2004 02:55:40 +0200 Subject: anaconda typo? In-Reply-To: <1089127681.22067.43.camel@bree.local.net> References: <1088905596.1142.620.camel@phobos> <1088936377.7077.853.camel@stina.menthos.com> <1089127681.22067.43.camel@bree.local.net> Message-ID: <1089507340.1168.99.camel@phobos> On Tue, 2004-07-06 at 17:28, Jeremy Katz wrote: > On Sun, 2004-07-04 at 12:19 +0200, Christian Rose wrote: > > s?n 2004-07-04 klockan 03.46 skrev Josep Puigdemont: > > > translating anaconda.po, I found: > > > > I think it's usually good to report any message issues you may find in > > Bugzilla (https://bugzilla.redhat.com/bugzilla/). Then it won't get > > lost, since I doubt most anaconda developers are subscribed to this > > list. > > Even though I am subscribed to the list, if it doesn't end up in > bugzilla, the chances of me losing track of it are extremely high (read: > almost guaranteed). It's much harder for me to "lose" a bug :) > Sure, sorry for polluting here :) I just wanted to know what did the others thing about it. I filed the bug #127617 regarding this issue. Regards, /Josep From xamc at rumos.pt Sun Jul 11 22:03:08 2004 From: xamc at rumos.pt (Alexandre Costa) Date: Sun, 11 Jul 2004 23:03:08 +0100 Subject: Fw: Typo in man page.. Message-ID: <001901c46792$da058ee0$6e00a8c0@DARKFOX> Hi all.. here is a typo in the english manpage of bash.. I already mailed it to bugbash and the ppl responsible for bash, but in any case, here it is.. > Hi there.. sorry to bother you all, but i've found a typo in the bash > manpage which seems to be constant around all the distrubutions and version > of linux i've managed to see. > > The typo is in the area prompting (got there with /^PROMPTING) and a little > below is the \V - "\V the release of bash, version + patchelvel (e.g., > 2.00.0)" where i believe "patchelvel" should be patchlevel. > > My version of bash is as it follows, but i believe some other versions have > the same typo. > > bash --version > GNU bash, version 2.05b.0(1)-release (i386-redhat-linux-gnu) > Copyright (C) 2002 Free Software Foundation, Inc. > > Tnx. Rumos S.A. (pt) trainner - www.rumos.pt RedHat's RHCE, RHCX. - www.europe.redhat.com. Fedora Translator : fedora-trans-pt at redhat.com Hero do Castanheiro, IT implementer - www.herodocastanheiro.pt ** Gnu. Its not about taking. It's about giving. ** From andrewm at inventa.ru Tue Jul 13 08:20:34 2004 From: andrewm at inventa.ru (Andrew Martynov) Date: Tue, 13 Jul 2004 12:20:34 +0400 Subject: Maintainer and [Take] button Message-ID: <40F39B52.1030604@inventa.ru> Hello, Bernd! I`m maintainer of Russian translation. I accidentally made commit to cvs without pressing [Take] before. Commit was successful. Is that method of commit allowed by policy or it was keeped as backdoor? Regards, Andrew Martynov P.S. Status page of modules is updated too slowly for last days ( it takes from 2 to 15 minutes ) From bgroh at redhat.com Tue Jul 13 09:27:08 2004 From: bgroh at redhat.com (Bernd Groh) Date: Tue, 13 Jul 2004 19:27:08 +1000 Subject: Maintainer and [Take] button In-Reply-To: <40F39B52.1030604@inventa.ru> References: <40F39B52.1030604@inventa.ru> Message-ID: <40F3AAEC.9040904@redhat.com> Hi Andrew, Andrew Martynov schrieb: > Hello, Bernd! > > I`m maintainer of Russian translation. > I accidentally made commit to cvs without pressing [Take] before. > > Commit was successful. > > Is that method of commit allowed by policy or it was keeped as backdoor? The maintainer has unrestricted commit access, independent of whether there is a current translator or not. We believed the maintainer should have this right. > Regards, > Andrew Martynov > > P.S. Status page of modules is updated too slowly for last days ( it > takes from 2 to 15 minutes ) That's strange, it never takes more than a minute for me? Could it be your connection? Or maybe there was something wrong with the server? I'll wait and see whether I get more feedback on this. Regards, Bernd > > > > > -- > Fedora-trans-list mailing list > Fedora-trans-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-trans-list -- Dr. Bernd R. Groh Phone : +61 7 3514 8114 Software Engineer (Localization) Fax : +61 7 3514 8199 Red Hat Asia-Pacific Mobile: +61 403 851 269 Disclaimer: http://apac.redhat.com/disclaimer/ From andrewm at inventa.ru Tue Jul 13 10:36:11 2004 From: andrewm at inventa.ru (Andrew Martynov) Date: Tue, 13 Jul 2004 14:36:11 +0400 Subject: Maintainer and [Take] button In-Reply-To: <40F3AAEC.9040904@redhat.com> References: <40F39B52.1030604@inventa.ru> <40F3AAEC.9040904@redhat.com> Message-ID: <40F3BB1B.6000509@inventa.ru> Hello, Bernd! I commit changes, then wait for 10-15 minutes, then done 'cvs up' - where no updates available and no locally modified files. Page was not still modified. Then I press [Take] button and after 1-2 minutes status page was updated. I suppose this is simple solitary case. Thank you, Andrew Martynov Bernd Groh wrote: > Hi Andrew, > > Andrew Martynov schrieb: > > > Hello, Bernd! > > > > I`m maintainer of Russian translation. > > I accidentally made commit to cvs without pressing [Take] before. > > > > Commit was successful. > > > > Is that method of commit allowed by policy or it was keeped as > backdoor? > > > The maintainer has unrestricted commit access, independent of whether > there is a current translator or not. We believed the maintainer should > have this right. > > > > Regards, > > Andrew Martynov > > > > P.S. Status page of modules is updated too slowly for last days ( it > > takes from 2 to 15 minutes ) > > > That's strange, it never takes more than a minute for me? Could it be > your connection? Or maybe there was something wrong with the server? > I'll wait and see whether I get more feedback on this. > > Regards, > Bernd > > > > > > > > > > > -- > > Fedora-trans-list mailing list > > Fedora-trans-list at redhat.com > > http://www.redhat.com/mailman/listinfo/fedora-trans-list > > > > -- > Dr. Bernd R. Groh Phone : +61 7 3514 8114 > Software Engineer (Localization) Fax : +61 7 3514 8199 > Red Hat Asia-Pacific Mobile: +61 403 851 269 > Disclaimer: http://apac.redhat.com/disclaimer/ > > > > -- > Fedora-trans-list mailing list > Fedora-trans-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-trans-list > From bgroh at redhat.com Tue Jul 13 11:33:45 2004 From: bgroh at redhat.com (Bernd Groh) Date: Tue, 13 Jul 2004 21:33:45 +1000 Subject: Maintainer and [Take] button In-Reply-To: <40F3BB1B.6000509@inventa.ru> References: <40F39B52.1030604@inventa.ru> <40F3AAEC.9040904@redhat.com> <40F3BB1B.6000509@inventa.ru> Message-ID: <40F3C899.8060902@redhat.com> Oh, sorry, you meant updated, as in shows up to date status information. The status is updated every 15 minutes, so yes, 2-15 minutes sounds about right. Cheers, Bernd Andrew Martynov schrieb: > Hello, Bernd! > > I commit changes, then wait for 10-15 minutes, > then done 'cvs up' - where no updates available and no locally > modified files. > Page was not still modified. > > Then I press [Take] button and after 1-2 minutes status page was updated. > > I suppose this is simple solitary case. > > Thank you, > Andrew Martynov > > Bernd Groh wrote: > >> Hi Andrew, >> >> Andrew Martynov schrieb: >> >> > Hello, Bernd! >> > >> > I`m maintainer of Russian translation. >> > I accidentally made commit to cvs without pressing [Take] before. >> > >> > Commit was successful. >> > >> > Is that method of commit allowed by policy or it was keeped as >> backdoor? >> >> >> The maintainer has unrestricted commit access, independent of whether >> there is a current translator or not. We believed the maintainer should >> have this right. >> >> >> > Regards, >> > Andrew Martynov >> > >> > P.S. Status page of modules is updated too slowly for last days ( it >> > takes from 2 to 15 minutes ) >> >> >> That's strange, it never takes more than a minute for me? Could it be >> your connection? Or maybe there was something wrong with the server? >> I'll wait and see whether I get more feedback on this. >> >> Regards, >> Bernd >> >> > >> > >> > >> > >> > -- >> > Fedora-trans-list mailing list >> > Fedora-trans-list at redhat.com >> > http://www.redhat.com/mailman/listinfo/fedora-trans-list >> >> >> >> -- >> Dr. Bernd R. Groh Phone : +61 7 3514 8114 >> Software Engineer (Localization) Fax : +61 7 3514 8199 >> Red Hat Asia-Pacific Mobile: +61 403 851 269 >> Disclaimer: http://apac.redhat.com/disclaimer/ >> >> >> >> -- >> Fedora-trans-list mailing list >> Fedora-trans-list at redhat.com >> http://www.redhat.com/mailman/listinfo/fedora-trans-list >> > > > > -- > Fedora-trans-list mailing list > Fedora-trans-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-trans-list -- Dr. Bernd R. Groh Phone : +61 7 3514 8114 Software Engineer (Localization) Fax : +61 7 3514 8199 Red Hat Asia-Pacific Mobile: +61 403 851 269 Disclaimer: http://apac.redhat.com/disclaimer/ From sp at elte.hu Tue Jul 13 21:06:34 2004 From: sp at elte.hu (Sulyok Peti) Date: Tue, 13 Jul 2004 23:06:34 +0200 Subject: HTML encoding Message-ID: <1089752793.6427.9.camel@sutty.mshome.net> Does anybody know why are the generated HTML pages encoded to ISO-8859-1? I think UTF-8 would be better, because it is the default encoding in Fedora and GNOME2. Is it possible to change this setting without hacking xmlto? Peti -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ez az ?zenetr?sz digit?lis al??r?ssal van ell?tva URL: From sp at elte.hu Wed Jul 14 04:16:29 2004 From: sp at elte.hu (Sulyok Peti) Date: Wed, 14 Jul 2004 06:16:29 +0200 Subject: HTML encoding In-Reply-To: <1089752793.6427.9.camel@sutty.mshome.net> References: <1089752793.6427.9.camel@sutty.mshome.net> Message-ID: <1089778588.7820.1.camel@sutty.mshome.net> Sorry. I wanted to send this message to the fedora-docs-list. 2004-07-13, k keltez?ssel 23:06-kor Sulyok Peti ezt ?rta: > Does anybody know why are the generated HTML pages encoded to > ISO-8859-1? I think UTF-8 would be better, because it is the default > encoding in Fedora and GNOME2. > > Is it possible to change this setting without hacking xmlto? > > Peti > > > ______________________________________________________________________ > -- > Fedora-trans-list mailing list > Fedora-trans-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-trans-list -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ez az ?zenetr?sz digit?lis al??r?ssal van ell?tva URL: From tome at users.ossm.org.mk Mon Jul 19 06:33:45 2004 From: tome at users.ossm.org.mk (=?koi8-r?Q?=F4=CF=CD=C9=D3=CC=C1=D7_?= =?koi8-r?Q?=ED=C1=D2=CB=CF=D7=D3=CB=C9?=) Date: Mon, 19 Jul 2004 08:33:45 +0200 Subject: New born mk.po has disappeared Message-ID: <1090218825.2619.4.camel@localhost.localdomain> Hello list, I recieve this when I try to checkot a file. [08:31:33][tome][~/fedora/translate] cvs co specspo/mk.po cvs server: warning: new-born specspo/mk.po has disappeared Anyone knows what this means? Thank you. -- ???????? ????????? take forceful action: Do something that should have been done a long time ago. From sarahs at redhat.com Mon Jul 19 06:44:43 2004 From: sarahs at redhat.com (Sarah Wang) Date: Mon, 19 Jul 2004 16:44:43 +1000 Subject: New born mk.po has disappeared In-Reply-To: <1090218825.2619.4.camel@localhost.localdomain> References: <1090218825.2619.4.camel@localhost.localdomain> Message-ID: <1090219483.2117.56.camel@localhost.localdomain> Hi, Specspo is not a separate module, so you cannot check it out separately. If you have already checked out translate module, just do "cvs up" in specspo directory will pick up that file. Regards, Sarah On Mon, 2004-07-19 at 16:33, ???????? ????????? wrote: > Hello list, > > I recieve this when I try to checkot a file. > > [08:31:33][tome][~/fedora/translate] cvs co specspo/mk.po > cvs server: warning: new-born specspo/mk.po has disappeared > > Anyone knows what this means? > > Thank you. > From tome at users.ossm.org.mk Mon Jul 19 07:07:18 2004 From: tome at users.ossm.org.mk (=?koi8-r?Q?=F4=CF=CD=C9=D3=CC=C1=D7_?= =?koi8-r?Q?=ED=C1=D2=CB=CF=D7=D3=CB=C9?=) Date: Mon, 19 Jul 2004 09:07:18 +0200 Subject: New born mk.po has disappeared In-Reply-To: <1090219483.2117.56.camel@localhost.localdomain> References: <1090218825.2619.4.camel@localhost.localdomain> <1090219483.2117.56.camel@localhost.localdomain> Message-ID: <1090220838.2619.8.camel@localhost.localdomain> On Mon, 2004-07-19 at 08:44, Sarah Wang wrote: > Specspo is not a separate module, so you cannot check it out separately. > If you have already checked out translate module, > just do "cvs up" in specspo directory will pick up that file. Oh, ok then. I was trying to do some translation while I'm at work and didn't want to checkout the whole 'translate' module. Guess I'll have to copy my translate/ folder structure from home. Oh well, thank you for your help. Tomislav -- ???????? ????????? The kernel license has expired From andrewm at inventa.ru Tue Jul 20 10:12:33 2004 From: andrewm at inventa.ru (Andrew Martynov) Date: Tue, 20 Jul 2004 14:12:33 +0400 Subject: Description of Status Pages Message-ID: <40FCF011.4060005@inventa.ru> Hello, Bernd! As I understand description of status pages is generated for specspo modules. But now this descriptions is not refreshed regulary as translation statistics. I found mistake in Russian translation of description of switchdesk module - it said about 'redhat-switch-printer' utility instead of 'switchdesk' utility. This translation was 'fuzzy' for FC2 and now it is corrected. http://elvis.redhat.com/cgi-bin/i18n-status?page=module&locale=ru&module=switchdesk&referrer=status&branch=HEAD&essential=0 Could you regenerate status pages descriptions again. In addition please note that some modules (for example, system-config-bind) has no translated description at status page, but specspo now has ( as redhat-config-bind ) http://elvis.redhat.com/cgi-bin/i18n-status?page=module&locale=ru&module=system-config-bind&referrer=status&branch=HEAD&essential=0 Regards, Andrew Martynov From bgroh at redhat.com Wed Jul 21 00:11:27 2004 From: bgroh at redhat.com (Bernd Groh) Date: Wed, 21 Jul 2004 10:11:27 +1000 Subject: Description of Status Pages In-Reply-To: <40FCF011.4060005@inventa.ru> References: <40FCF011.4060005@inventa.ru> Message-ID: <40FDB4AF.4000807@redhat.com> Hi Andrew, I'll regenerate the descriptions. Thanks, Bernd Andrew Martynov schrieb: > Hello, Bernd! > > As I understand description of status pages is generated for specspo > modules. > > But now this descriptions is not refreshed regulary as translation > statistics. > > I found mistake in Russian translation of description of switchdesk > module - it said about 'redhat-switch-printer' utility instead of > 'switchdesk' utility. This translation was 'fuzzy' for FC2 and now it > is corrected. > http://elvis.redhat.com/cgi-bin/i18n-status?page=module&locale=ru&module=switchdesk&referrer=status&branch=HEAD&essential=0 > > > Could you regenerate status pages descriptions again. > > In addition please note that some modules (for example, > system-config-bind) has no translated description at status page, > but specspo now has ( as redhat-config-bind ) > http://elvis.redhat.com/cgi-bin/i18n-status?page=module&locale=ru&module=system-config-bind&referrer=status&branch=HEAD&essential=0 > > > Regards, > Andrew Martynov > > > -- > Fedora-trans-list mailing list > Fedora-trans-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-trans-list -- Dr. Bernd R. Groh Phone : +61 7 3514 8114 Software Engineer (Localization) Fax : +61 7 3514 8199 Red Hat Asia-Pacific Mobile: +61 403 851 269 Disclaimer: http://apac.redhat.com/disclaimer/ From sarahs at redhat.com Thu Jul 22 07:24:35 2004 From: sarahs at redhat.com (Sarah Wang) Date: Thu, 22 Jul 2004 17:24:35 +1000 Subject: new package available for translation Message-ID: <1090481075.2828.32.camel@localhost.localdomain> Hi all, There is a new package available for translation: system-switch-im. To check out the po files, you can either re-check out the whole translate/ module, or change to your ~/translate/ directory and perform the following command: cvs co po_system-switch-im Regards, Sarah From pmmm at rnl.ist.utl.pt Thu Jul 22 09:18:02 2004 From: pmmm at rnl.ist.utl.pt (Pedro Morais) Date: Thu, 22 Jul 2004 10:18:02 +0100 Subject: new package available for translation In-Reply-To: <1090481075.2828.32.camel@localhost.localdomain> References: <1090481075.2828.32.camel@localhost.localdomain> Message-ID: <200407221018.02603.pmmm@rnl.ist.utl.pt> Em Quinta, 22 de Julho de 2004 08:24, Sarah Wang escreveu: > Hi all, > > There is a new package available for translation: system-switch-im. To > check out the po files, you can either re-check out the whole translate/ > module, or change to your ~/translate/ directory and perform the > following command: > > cvs co po_system-switch-im I've got maintainer status but: [system-switch-im/pt.po] is not assigned to you. **** Access allowed: morais is in ACL for system-switch-im/po. cvs server: Pre-commit check failed cvs [server aborted]: correct above errors first! > > Regards, > Sarah > > > > > -- > Fedora-trans-list mailing list > Fedora-trans-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-trans-list From fredrik at hansendata.se Thu Jul 22 09:15:25 2004 From: fredrik at hansendata.se (Fredrik Hansen) Date: Thu, 22 Jul 2004 11:15:25 +0200 (CEST) Subject: new package available for translation In-Reply-To: <1090481075.2828.32.camel@localhost.localdomain> References: <1090481075.2828.32.camel@localhost.localdomain> Message-ID: <49737.213.187.218.166.1090487725.squirrel@213.187.218.166> Sarah Wang said: > Hi all, > > There is a new package available for translation: system-switch-im. To > check out the po files, you can either re-check out the whole translate/ > module, or change to your ~/translate/ directory and perform the > following command: > > cvs co po_system-switch-im > > Regards, > Sarah Hi, I signed up quite recently, and I wonder where there is information on how to get started with translating. Maybe i should have gotten info when signing up or so, which seems most logical, but i'd never recieved any such info (spamfilter got it ?). Best Regards, Fredrik Hansen From menthos at menthos.com Thu Jul 22 21:56:18 2004 From: menthos at menthos.com (Christian Rose) Date: Thu, 22 Jul 2004 23:56:18 +0200 Subject: new package available for translation In-Reply-To: <49737.213.187.218.166.1090487725.squirrel@213.187.218.166> References: <1090481075.2828.32.camel@localhost.localdomain> <49737.213.187.218.166.1090487725.squirrel@213.187.218.166> Message-ID: <1090533378.17079.663.camel@daim> tor 2004-07-22 klockan 11.15 skrev Fredrik Hansen: > Hi, I signed up quite recently, and I wonder > where there is information on how to get started with translating. > Maybe i should have gotten info when signing up or so, which seems most > logical, but i'd never recieved any such info (spamfilter got it ?). What language do you intend to translate into? Christian From goeran at uddeborg.se Thu Jul 22 22:15:00 2004 From: goeran at uddeborg.se (=?iso-8859-1?q?G=F6ran_Uddeborg?=) Date: Fri, 23 Jul 2004 00:15:00 +0200 Subject: Direct link to translation status page for my language? Message-ID: <16640.15460.102619.845211@mimmi.uddeborg.se> I have a bookmark for the translation status page (http://elvis.redhat.com/cgi-bin/i18n-status). But I very rarely look at the status for any other language than my own (Swedish). I figured out that by adding "?locale=sv" to the URL, I could get the menu preset to Swedish so I only had to press the button. But pressing the button doesn't really add anything. I would prefer to directly bookmark the status page itself but haven't figured out a way to do that. Do I miss something, or isn't there a way to do that? From pmmm at rnl.ist.utl.pt Thu Jul 22 22:22:05 2004 From: pmmm at rnl.ist.utl.pt (Pedro Morais) Date: Thu, 22 Jul 2004 23:22:05 +0100 Subject: Direct link to translation status page for my language? In-Reply-To: <16640.15460.102619.845211@mimmi.uddeborg.se> References: <16640.15460.102619.845211@mimmi.uddeborg.se> Message-ID: <200407222322.05479.pmmm@rnl.ist.utl.pt> Em Quinta, 22 de Julho de 2004 23:15, G?ran Uddeborg escreveu: > I have a bookmark for the translation status page > (http://elvis.redhat.com/cgi-bin/i18n-status). But I very rarely look > at the status for any other language than my own (Swedish). I figured > out that by adding "?locale=sv" to the URL, I could get the menu > preset to Swedish so I only had to press the button. > > But pressing the button doesn't really add anything. I would prefer > to directly bookmark the status page itself but haven't figured out a > way to do that. Do I miss something, or isn't there a way to do that? Add ?locale=sv&page=status > > > -- > Fedora-trans-list mailing list > Fedora-trans-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-trans-list -- Pedro Morais - morais at kde.org - http://www.rnl.ist.utl.pt/~pmmm/ From goeran at uddeborg.se Fri Jul 23 10:14:51 2004 From: goeran at uddeborg.se (=?iso-8859-1?q?G=F6ran_Uddeborg?=) Date: Fri, 23 Jul 2004 12:14:51 +0200 Subject: Direct link to translation status page for my language? In-Reply-To: <200407222322.05479.pmmm@rnl.ist.utl.pt> References: <16640.15460.102619.845211@mimmi.uddeborg.se> <200407222322.05479.pmmm@rnl.ist.utl.pt> Message-ID: <16640.58651.58201.710723@musse.uddeborg.se> Pedro Morais writes: > Add ?locale=sv&page=status Thanks! From sarahs at redhat.com Tue Jul 27 03:53:48 2004 From: sarahs at redhat.com (Sarah Wang) Date: Tue, 27 Jul 2004 13:53:48 +1000 Subject: [Fwd: help] Message-ID: <1090900428.2263.0.camel@cpe-144-136-136-225.qld.bigpond.net.au> -------------- next part -------------- An embedded message was scrubbed... From: "Pawan Chitrakar" Subject: help Date: Sun, 25 Jul 2004 10:16:19 +0545 (NPT) Size: 2538 URL: From pmmm at rnl.ist.utl.pt Tue Jul 27 04:13:46 2004 From: pmmm at rnl.ist.utl.pt (Pedro Morais) Date: Tue, 27 Jul 2004 05:13:46 +0100 Subject: Specs i18n Message-ID: <200407270513.46203.pmmm@rnl.ist.utl.pt> When will the specs.po i18n be updated? (short answer for FC2: never) -- Pedro Morais - morais at kde.org - http://www.rnl.ist.utl.pt/~pmmm/ From amanlinux at netscape.net Tue Jul 27 04:29:41 2004 From: amanlinux at netscape.net (A S Alam) Date: Tue, 27 Jul 2004 00:29:41 -0400 Subject: [Fwd: help] Message-ID: <1E1074B6.5EE3129F.02E1C209@netscape.net> Sarah Wang wrote: > > >Subject: help >Date: Sun, 25 Jul 2004 10:16:19 +0545 (NPT) >From: "Pawan Chitrakar" >To: >CC: >i have just joined fedora translation project. > >i have checkout the module and work on translation but i would like to get >the glossary if possible to translate before begining the actual >translation. Can anyone please help me to get the glossary. > >and i would like to get some more information on commiting the translation >work in cvs. for commiting, use following check your files ,so that there is no problem at update msgfmt -cv np.po then update to cvs cvs up np.po if is M status of your file, then you can commit that files then cvs commit -m 'message' np.po > >My language is "ne" NEPALI > >Thank You, > >chautari > > OK Aman __________________________________________________________________ Switch to Netscape Internet Service. As low as $9.95 a month -- Sign up today at http://isp.netscape.com/register Netscape. Just the Net You Need. New! Netscape Toolbar for Internet Explorer Search from anywhere on the Web and block those annoying pop-ups. Download now at http://channels.netscape.com/ns/search/install.jsp From tome at users.ossm.org.mk Tue Jul 27 06:22:45 2004 From: tome at users.ossm.org.mk (=?UTF-8?B?0KLQvtC80LjRgdC70LDQsiDQnNCw0YDQutC+0LLRgdC60Lg=?=) Date: Tue, 27 Jul 2004 08:22:45 +0200 Subject: CVS question, concurrent translations Message-ID: <4105F4B5.8000503@users.ossm.org.mk> Hello, this is my question: Recently, two of our translation team members (I and another member) accidentaly worked on the same .po file. I didn't notice that he has already "Take"n the file. Sometime after, I did a "cvs up" and our translations didn't match. So I had some lines in the file which pointed my version and his versio delimited by ">>>>> his trans ===== my trans <<<<<<" and so on. It was hard to remove them manually, since a lot of work has been done. I solved this by deleting the .po file and did a "cvs up" again, which downloaded his version only. Is there a way to overwrite my changes when updating using some cvs commands? Thanks From alan at redhat.com Tue Jul 27 09:23:00 2004 From: alan at redhat.com (Alan Cox) Date: Tue, 27 Jul 2004 05:23:00 -0400 Subject: [Fwd: help] In-Reply-To: <1090900428.2263.0.camel@cpe-144-136-136-225.qld.bigpond.net.au> References: <1090900428.2263.0.camel@cpe-144-136-136-225.qld.bigpond.net.au> Message-ID: <20040727092300.GA16362@devserv.devel.redhat.com> On Tue, Jul 27, 2004 at 01:53:48PM +1000, Sarah Wang wrote: > i have checkout the module and work on translation but i would like to get > the glossary if possible to translate before begining the actual > translation. Can anyone please help me to get the glossary. Fedora itself doesn't have a glossary. If you also plan to translate the desktop then Sun contributed a good glossary to Gnome which may be an appropriate starting point (and if Gnome is already translated - a good reference) From rodolfo at heartsome.net Tue Jul 27 11:10:08 2004 From: rodolfo at heartsome.net (Rodolfo M. Raya) Date: Tue, 27 Jul 2004 08:10:08 -0300 Subject: CVS question, concurrent translations In-Reply-To: <4105F4B5.8000503@users.ossm.org.mk> References: <4105F4B5.8000503@users.ossm.org.mk> Message-ID: <1090926608.8082.17.camel@elrond.maxprograms.com> On Tue, 2004-07-27 at 03:22, ???????? ????????? wrote: > Hello, this is my question: > Recently, two of our translation team members (I and another member) > accidentaly worked on the same .po file. I didn't notice that he has > already "Take"n the file. Sometime after, I did a "cvs up" and our > translations didn't match. So I had some lines in the file which pointed > my version and his versio delimited by ">>>>> his trans ===== my trans > <<<<<<" and so on. It was hard to remove them manually, since a lot of > work has been done. I solved this by deleting the .po file and did a > "cvs up" again, which downloaded his version only. Is there a way to > overwrite my changes when updating using some cvs commands? > > Thanks Hi, CVS was designed to help developers working on the same file at the same time. Concurrency is the key in CVS. There were problems with your translation because the wrong operation was done. Both translators "uploaded" without checking the existence of changes in CVS repository. To avoid conflicts, the right procedure is: 1. checkout a module/file 2. work on the module/file and make all desired changes 3. compare modified module/file with latest version in CVS 4. if someone made changes in CVS after the file was checked out, perform a merge operation 5. commit modified/merged module/file to CVS repository Step 4 is the one you didn't do. There are very nice graphical tools that can be used with CVS. Eclipse (http://www.eclipse.org) will let you know when someone committed a file before you finished your changes. It can also assist you performing the necessary merge, avoiding those >>>>>, ==== and <<<< that ruined your file. As a matter of fact, it wasn't necessary at all to add take/release mechanism in the web site to avoid concurrent translations. CVS can handle that. Hope this helps, Rodolfo -- Rodolfo M. Raya Heartsome Holdings Pte. Ltd. From tome at users.ossm.org.mk Tue Jul 27 11:20:16 2004 From: tome at users.ossm.org.mk (=?UTF-8?B?0KLQvtC80LjRgdC70LDQsiDQnNCw0YDQutC+0LLRgdC60Lg=?=) Date: Tue, 27 Jul 2004 13:20:16 +0200 Subject: CVS question, concurrent translations In-Reply-To: <1090926608.8082.17.camel@elrond.maxprograms.com> References: <4105F4B5.8000503@users.ossm.org.mk> <1090926608.8082.17.camel@elrond.maxprograms.com> Message-ID: <41063A70.9000502@users.ossm.org.mk> Rodolfo M. Raya wrote: >Step 4 is the one you didn't do. > > How do you merge? From rodolfo at heartsome.net Tue Jul 27 11:51:44 2004 From: rodolfo at heartsome.net (Rodolfo M. Raya) Date: Tue, 27 Jul 2004 08:51:44 -0300 Subject: CVS question, concurrent translations In-Reply-To: <41063A70.9000502@users.ossm.org.mk> References: <4105F4B5.8000503@users.ossm.org.mk> <1090926608.8082.17.camel@elrond.maxprograms.com> <41063A70.9000502@users.ossm.org.mk> Message-ID: <1090929104.8082.36.camel@elrond.maxprograms.com> On Tue, 2004-07-27 at 08:20, ???????? ????????? wrote: > >Step 4 is the one you didn't do. > > > > > How do you merge? I use Eclipse for all CVS access. When a conflict is found, I open the file in a compare editor and copy the relevant changes from CVS to the local version. Once everything is cleared, I mark the file as merged and then commit. If you are not working within a comfortable graphical tool, you can verify if there are conflicts using "cvs -n" option before committing. In case of conflicts, you can use "cvs rdiff" and "cvs diff" to compare your local copy against the one in the repository. If you detect a conflict, you can checkout the offending module from CVS and do a split diff with VIM. It will highlight the differences and will help you detect what needs review. Anyway, it's a lot easier to use a graphical tool. Regards, Rodolfo -- Rodolfo M. Raya Heartsome Holdings Pte. Ltd. From tome at users.ossm.org.mk Tue Jul 27 11:57:10 2004 From: tome at users.ossm.org.mk (=?UTF-8?B?0KLQvtC80LjRgdC70LDQsiDQnNCw0YDQutC+0LLRgdC60Lg=?=) Date: Tue, 27 Jul 2004 13:57:10 +0200 Subject: CVS question, concurrent translations In-Reply-To: <1090929104.8082.36.camel@elrond.maxprograms.com> References: <4105F4B5.8000503@users.ossm.org.mk> <1090926608.8082.17.camel@elrond.maxprograms.com> <41063A70.9000502@users.ossm.org.mk> <1090929104.8082.36.camel@elrond.maxprograms.com> Message-ID: <41064316.9000400@users.ossm.org.mk> Rodolfo M. Raya wrote: >Anyway, it's a lot easier to use a graphical tool. > > Yeah, it is. But I was wondering if there was an automated way to resolve conflicts. Searching through the manual, I found that this has to be done by hand, which is very tiresome if many strings have conflicts. Thanks for your help, anyway. From sopwith at redhat.com Tue Jul 27 17:39:17 2004 From: sopwith at redhat.com (Elliot Lee) Date: Tue, 27 Jul 2004 13:39:17 -0400 Subject: Fedora Project Mailing Lists reminder Message-ID: This is a reminder of the mailing lists for the Fedora Project, and the purpose of each list. You can view this information at http://fedora.redhat.com/participate/communicate/ When you're using these mailing lists, please take the time to choose the one that is most appropriate to your post. If you don't know the right mailing list to use for a question or discussion, please contact me. This will help you get the best possible answer for your question, and keep other list subscribers happy! Mailing Lists Mailing lists are email addresses which send email to all users subscribed to the mailing list. Sending an email to a mailing list reaches all users interested in discussing a specific topic and users available to help other users with the topic. The following mailing lists are available. To subscribe, send email to -request at redhat.com (replace with the desired mailing list name such as fedora-list) with the word subscribe in the subject. fedora-announce-list - Announcements of changes and events. To stay aware of news, subscribe to this list. fedora-list - For users of releases. If you want help with a problem installing or using , this is the list for you. fedora-test-list - For testers of test releases. If you would like to discuss experiences using TEST releases, this is the list for you. fedora-devel-list - For developers, developers, developers. If you are interested in helping create releases, this is the list for you. fedora-docs-list - For participants of the docs project fedora-desktop-list - For discussions about desktop issues such as user interfaces, artwork, and usability fedora-config-list - For discussions about the development of configuration tools fedora-legacy-announce - For announcements about the Fedora Legacy Project fedora-legacy-list - For discussions about the Fedora Legacy Project fedora-selinux-list - For discussions about the Fedora SELinux Project fedora-de-list - For discussions about Fedora in the German language fedora-es-list - For discussions about Fedora in the Spanish language fedora-ja-list - For discussions about Fedora in the Japanese language fedora-i18n-list - For discussions about the internationalization of Fedora Core fedora-trans-list - For discussions about translating the software and documentation associated with the Fedora Project German: fedora-trans-de French: fedora-trans-fr Spanish: fedora-trans-es Italian: fedora-trans-it Brazilian Portuguese: fedora-trans-pt_br Japanese: fedora-trans-ja Korean: fedora-trans-ko Simplified Chinese: fedora-trans-zh_cn Traditional Chinese: fedora-trans-zh_tw From noriko at redhat.com Wed Jul 28 02:49:21 2004 From: noriko at redhat.com (Noriko Mizumoto) Date: Wed, 28 Jul 2004 12:49:21 +1000 Subject: CVS question, concurrent translations In-Reply-To: <4105F4B5.8000503@users.ossm.org.mk> References: <4105F4B5.8000503@users.ossm.org.mk> Message-ID: <41071431.6070807@redhat.com> Hi, If you are using KBabel; Setting => Dictionary setting => PO compendium Set your .po file as it's path. Close KBable once, restart and open his file downloaded from cvs. You can see your translation (per msgid) in the serching tab located in right hand side. Highlight the serching result and click "Copy serching result into msgstr" button in the tool bar. Since exact matching (100%) with msgid appearing at the top highlighted in the tab, only you have to do is click "Copy serching result into msgstr" for each string. eg. you have 50 changes, click 50 times. This also allows you to compare his translation conflicted and decide which is prefarable for you. Finally you commit the file. Hope this help. Noriko ???????? ????????? wrote: > Hello, this is my question: > Recently, two of our translation team members (I and another member) > accidentaly worked on the same .po file. I didn't notice that he has > already "Take"n the file. Sometime after, I did a "cvs up" and our > translations didn't match. So I had some lines in the file which pointed > my version and his versio delimited by ">>>>> his trans ===== my trans > <<<<<<" and so on. It was hard to remove them manually, since a lot of > work has been done. I solved this by deleting the .po file and did a > "cvs up" again, which downloaded his version only. Is there a way to > overwrite my changes when updating using some cvs commands? > > Thanks > > > -- > Fedora-trans-list mailing list > Fedora-trans-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-trans-list From goeran at uddeborg.se Wed Jul 28 13:39:59 2004 From: goeran at uddeborg.se (=?iso-8859-1?q?G=F6ran_Uddeborg?=) Date: Wed, 28 Jul 2004 15:39:59 +0200 Subject: Specs i18n In-Reply-To: <200407270513.46203.pmmm@rnl.ist.utl.pt> References: <200407270513.46203.pmmm@rnl.ist.utl.pt> Message-ID: <16647.44207.981119.979167@mimmi.uddeborg.se> Pedro Morais writes: > When will the specs.po i18n be updated? You're not the only one wondering. There is a bugzilla about it: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=107393 But it is almost a year old now. Some have cc:ed themselves, there has been some field modification and duplicates. But as far as can be seen from the outside, there hasn't been any real action. From tome at users.ossm.org.mk Wed Jul 28 15:56:25 2004 From: tome at users.ossm.org.mk (=?koi8-r?Q?=F4=CF=CD=C9=D3=CC=C1=D7_?= =?koi8-r?Q?=ED=C1=D2=CB=CF=D7=D3=CB=C9?=) Date: Wed, 28 Jul 2004 17:56:25 +0200 Subject: CVS question, concurrent translations In-Reply-To: <41071431.6070807@redhat.com> References: <4105F4B5.8000503@users.ossm.org.mk> <41071431.6070807@redhat.com> Message-ID: <1091030185.2425.0.camel@localhost.localdomain> On ???, 2004-07-28 at 04:49, Noriko Mizumoto wrote: > If you are using KBabel; > Setting => Dictionary setting => PO compendium > Set your .po file as it's path. > Close KBable once, restart and open his file downloaded from cvs. > You can see your translation (per msgid) in the serching tab located in > right hand side. > Highlight the serching result and click "Copy serching result into > msgstr" button in the tool bar. > Since exact matching (100%) with msgid appearing at the top highlighted > in the tab, only you have to do is click "Copy serching result into > msgstr" for each string. eg. you have 50 changes, click 50 times. > This also allows you to compare his translation conflicted and decide > which is prefarable for you. Thanks a lot. I guess this is what I was looking for. From katzj at redhat.com Wed Jul 28 17:44:00 2004 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 28 Jul 2004 13:44:00 -0400 Subject: Specs i18n In-Reply-To: <16647.44207.981119.979167@mimmi.uddeborg.se> References: <200407270513.46203.pmmm@rnl.ist.utl.pt> <16647.44207.981119.979167@mimmi.uddeborg.se> Message-ID: <1091036640.7155.12.camel@bree.local.net> On Wed, 2004-07-28 at 15:39 +0200, G?ran Uddeborg wrote: > Pedro Morais writes: > > When will the specs.po i18n be updated? [snip] > But it is almost a year old now. Some have cc:ed themselves, there > has been some field modification and duplicates. But as far as can be > seen from the outside, there hasn't been any real action. The problem is that as it currently stands, specspo is a completely broken process. Background: Specspo was intended to provide a solution to two different problems: 1) A unified location for our documentation team to proofread and edit the various textual areas of a specfile 2) A unified location for translations of these textual areas. Unfortunately, with the first of these, it basically means that there isn't a good canonical location. Changes would get made in specspo and then not pushed back into the spec file of the package itself. Then, merging in updated descriptions from spec files as well as new packages becomes something of a nightmare. So, to get out of this mess, I think that there are going to be some changes to how specspo works, it's just a matter of getting the round 'tuits to get the changes done (or even written up so that someone else can do it :-) On my list, hopefully in the next day or so for at least the writing it up part... Jeremy From andrewm at inventa.ru Thu Jul 29 06:56:28 2004 From: andrewm at inventa.ru (Andrew Martynov) Date: Thu, 29 Jul 2004 10:56:28 +0400 Subject: man & info pages Message-ID: <41089F9C.2030309@inventa.ru> Hello, Red Hat team! Does Red Hat internationalization/translation team plans to coordinate translation of "man" and "info" pages for packages related to Red Hat and Fedora distros. I think it is good idea to coordinate translation of core packages like RPM, BASH, KUDZU, NET-TOOLS. At this moment we has good mechanism of translation, notification of changes, team organization for user interface. Existing translation teams can also provide good quality of "man" and "info" pages. The only dificulty I see is to organize this process of translations. Best regards, Andrew Martynov From alan at redhat.com Thu Jul 29 13:45:12 2004 From: alan at redhat.com (Alan Cox) Date: Thu, 29 Jul 2004 09:45:12 -0400 Subject: man & info pages In-Reply-To: <41089F9C.2030309@inventa.ru> References: <41089F9C.2030309@inventa.ru> Message-ID: <20040729134512.GC12406@devserv.devel.redhat.com> On Thu, Jul 29, 2004 at 10:56:28AM +0400, Andrew Martynov wrote: > I think it is good idea to coordinate translation of core packages like > RPM, BASH, KUDZU, NET-TOOLS. Most of these are drawn from upstream (obviously kudzu is somewhat of an exception) and should probably be done upstream. The FSF has lists for translators that cover its projects. For rpm I suspect you want to send translations and any i18n fixes to jbj at redhat.com From fredrik at hansendata.se Thu Jul 29 14:24:02 2004 From: fredrik at hansendata.se (Fredrik Hansen) Date: Thu, 29 Jul 2004 16:24:02 +0200 (CEST) Subject: Off-topic: List causing trouble w squirrelmail In-Reply-To: <20040729134512.GC12406@devserv.devel.redhat.com> References: <41089F9C.2030309@inventa.ru> <20040729134512.GC12406@devserv.devel.redhat.com> Message-ID: <56167.213.187.218.166.1091111042.squirrel@213.187.218.166> Hi all, just a quick check: Seems like Squirrelmail(1.5.0) is having a bit of a problem with the mails on this list. I woulda done some rtfm if it wasnt that its just this list thats causing problems. And, yes ill ask on the squirrelmail list aswell, just wanted to check if im the only one bringing this subject up. Issues are: Deleting, wont do it. Viewing headers, complains about malformed headers. Anyone got the same experience? Best Regards, Fredrik Hansen and sorry for the offtopic Q. From josep at imatge-sintetica.com Fri Jul 30 22:32:58 2004 From: josep at imatge-sintetica.com (Josep Puigdemont) Date: Sat, 31 Jul 2004 00:32:58 +0200 Subject: CVS question, concurrent translations In-Reply-To: <41064316.9000400@users.ossm.org.mk> References: <4105F4B5.8000503@users.ossm.org.mk> <1090926608.8082.17.camel@elrond.maxprograms.com> <41063A70.9000502@users.ossm.org.mk> <1090929104.8082.36.camel@elrond.maxprograms.com> <41064316.9000400@users.ossm.org.mk> Message-ID: <1091226778.1252.7.camel@phobos> On dt, 2004-07-27 at 13:57, ???????? ????????? wrote: > Rodolfo M. Raya wrote: > > >Anyway, it's a lot easier to use a graphical tool. > > nooooo! 8) > > > Yeah, it is. But I was wondering if there was an automated way to > resolve conflicts. Searching through the manual, I found that this has > to be done by hand, which is very tiresome if many strings have conflicts. > Thanks for your help, anyway. > I use msgmerge: $ cvs update old.po $ msgmerge new.po old.po (this will output to standard output, you can use "-o output_file" too) CVS doesn't know a thing about the structure of a PO file, but msgmerge does, so you can rely better on it. /Josep