trans June 2004

trans@lists.fedoraproject.org

49 participants
49 discussions

Re: Fedora and Translation Teams
by Mohammed Elzubeir 26 Jun '04

26 Jun '04

On Fri, Jun 25, 2004 at 11:04:36PM +1000, Bernd Groh wrote: DISCLAIMER: This does not represent the views of Arabeyes and are only my personal views. > Wow! I am completely and utterly confused now. For the record, the main > change that has been undertaken is the [Take], [Release] mechanism, that > is to prevent two translators from comitting at the same time. Can It also prevents a team to exert control over their language's translation. > anyone tell me what exactly happened here? *confused* We did not What happened here is that I have been watching Youcef get ridiculed and treated as if he is the sole translator of Fedora, and as if he wants total control of the translation for himself. For your information, Dr. Groh, this is not the case. There is a large team that stands behind Youcef. If there are a couple members (some of which are redhat employees) who feel that Arabeyes is not worthy of translating Fedora, then so be it. I would personally propose to Arabeyes to drop its efforts with Fedora and let the chaos ensue. > introduce any new policy, we merely, as said, implemented a mechanism to > prevent two translators from comitting at the same time. And one thing I Read above -- it does more than just prevent two translators from committing at the same time. > should mention, since I am not clear whether it is clear or not, though > it should be, what I am saying here on list is *not* Fedora policy, it > is *my* opinion. I believe in my opinion and in my right to state it, > that I've implemented this new system for the Fedora project has > absolutely nothing to do with it. And I am telling you that this system is a bad system. You should consider looking at how other projects have successfully been doing this. Regards -- ------------------------------------------------------- | Mohammed Elzubeir | Visit us at: | | | http://www.arabeyes.org/ | | Arabeyes Project | Homepage: | | Unix the 'right' way | http://elzubeir.fakkir.net/ | -------------------------------------------------------

2 1

The GNOME model
by Christian Rose 25 Jun '04

25 Jun '04

I saw some posts mention the GNOME Translation Project (GTP) model as a reference. Some of them seemed entirely correct, some of them while partly correct also seemed based on slight misunderstandings. I'd like to take this oppurtunity to clear these things up. If nothing else, this could perhaps get some insight in how another community translation project works. There are some more or less defined goals with the model that the GTP uses: * We want to encourage translators to work together (we call these groupings "teams"), since this usually means more consistent terminology and better QA for the translations. * We recognize that sometimes bad and confusing translations can be worse than no translation at all, so we want to encourage QA and contributors working together in teams, which in itself encourages some level of basic QA. * We want to encourage new translators to get in contact with their team right from the start, since the team can help them get started, with instructions and help in their own language. Also, the teams usually know what terminology can be used, and the team also usually has some experience in translating and can help in any question, regarding from language difficulties to technical issues such as PO syntax etc. * We want to give the teams some freedom to decide how they want to organize their own work, since we recognize that no mandated policy fits every team. Some teams are small, some really big, and some prefer an open policy, while others a more strict one. * We want to make sure that no, or very few, conflicts arise, and that if they arise, they are resolved before the affected translations that may be results of this are being committed. There's often not many things that are as counterproductive as conflicts, be they accidental or intentional. To avoid accidental conflicts, we want the translators to form teams, one for each language. * We want to make sure that the ones deciding on the translations are as much as possible the ones with knowledge in the affected language, and not other people, such as software maintainers or GTP maintainers. It's close to impossible for someone not fluent in a language to differentiate a "good" translation from a "bad" one, so the teams are the ones to decide, since they have the knowledge of the language. * At the same time, we still want to make the entry level barrier for contribution as low as possible. The teams --------- The GNOME Translation Project (GTP) is divided into language teams. A "team" can be everything from a single person working for himself, to many dozens of translators working together. But there can only be one team for each language at any given time. Each team should have a coordinator. This is basically in practice just a title that gets listed together with the team entry on the GTP web pages. The coordinator for the most part just has to act as a contact person, so that people from the GNOME side of things has a person they can contact in case there's a general problem with those translations, but also so that new volunteers have someone to contact in case they want to get started translating into that language. Starting to translate a new language ------------------------------------ In the GTP, anyone is welcome to start translating a new language. All it basically takes is for someone to write to the project mailing list and say "I want to translate into the X language". Then we'll list a new X language team on the GTP web pages, with this person as the coordinator for that new team, and help this person get started. Starting to translate an existing language ------------------------------------------ On the GTP web pages, new volunteers are strongly encouraged to get in contact with their language team and its coordinator in case there already is a team. If they report that they haven't tried, we urge them to do so before continuing. The team can then help the volunteer to get started, and they also know if someone is already working on a particular translations, things to watch out for, etc. We also encourage software maintainers to do the same thing, i.e. point interested translation volunteers to the GTP and their language team¹. If someone reports that they have failed in getting in contact with the current team coordinator, either because the mail bounced, or because the current coordinator didn't respond, we formally give the current coordinator one week to respond and explain. If he or she hasn't responded in a week, we appoint someone else that has volunteered for this position as coordinator for that team. The coordinator's role ---------------------- The primary goal for a language team coordinator is to act as a contact person. However, with the position also comes some level of final say over the GNOME translations for this language, or other aspects covering the language team. This is rarely ever needed though, but it helps avoiding confusion should such situations occur. It's somewhat like the situation of being the maintainer for a piece of software. We don't want to allow coordinators to become "dictators" though. If someone reports that their coordinator is acting in such a way, we urge the coordinator to explain himself. Should the issues be for real we can opt to replace the coordinator, but fortunately that rarely happens. Almost all such cases seem to be based on misunderstandings, and are solved amicabilly for all parts. CVS access ---------- In GNOME, CVS accounts aren't restricted, not even translator ones. This has both benefits and drawbacks, but one effect is that we are somewhat more restrictive with giving out CVS accounts. A translator has to produce some translations before he or she can apply for and have a CVS account. This usually amounts to a handful of translations or something like that. We just want to make sure that the person's request is somewhat serious, and the best way to get a hint on that appears to be on whether there are already existing contributions. Also, the team coordinator must approve of the CVS account request for any member of his team. This is just to ensure that the team knows who will be committing translations for their language, and help avoid conflict situations later. We don't want to have potential conflicts occur in CVS, but rather have them resolved before that point. Also, in many cases we catch those situations where someone wanted to translate into a language but completely missed the fact that there is a team that does this and that he or she could join. Most people appear to be thankful for getting to know this. Once the person has a CVS account, it's personal and he or she can use it for both committing own translations and other people's translations, usually from the same team. Usually, at least one person in a team has a CVS account, and with big, productive teams there can be many in the same team that have access, and so the team as a whole can also help committing the translations of new members. Abuse ----- Obviously, no system or model is perfect. One area that we have recognized is that there is a possibility for a coordinator to abuse his or her situation. Fortunately, this rarely occurs, since most translators appear to be sensible people. And when it happens, we usually get to hear complaints about it, and can have an open discussion on how to solve it. Often the teams solve any such issues themselves. Drawbacks --------- There are some drawbacks I see with this model myself. First of all, the barrier of entry is not as low as it could be. It takes some mailing to get started: Subscribing to lists and getting contact with the potentially already existing team. Even worse when a coordinator or other people in the team should happen to not be reachable anymore; then the new volunteer must also report that before the situation can be fixed. Benefits -------- However, most translators seem to agree that the benefits outweigh the drawbacks. The benefits is the strong team community and team cooperation, and the encouragement for QA and terminology consistency built into the system. Also, since the teams usually gather experience with time, there is also a mentorship aspect, as older team members can help novice translators get started and also help later on, and this with instructions in their own language, a help which can be quite valuable. Usually all of this adds together, so that the whole translation becomes becomes like an ecosystem of its own, with the contributors in the seperate language teams getting more experienced, helping new ones get started, and then the new ones grow "old" one day and can help new ones, and so on, so this ensures a continuity effect that is most interesting and I believe also very beneficial to the project. So this is one model for organizing translators, and I believe that it is close to identical with the translation projects of many other big projects, such as KDE, Mozilla, OpenOffice.org or the Translation Project. Do I consider this model perfect? Obviously not. It has its drawbacks. But I don't think ignoring or downplaying the issues a model like this tries to solve is a good thing to do when organizing a new translation project. Also, I think the issues should be taken into careful consideration when designing a fundamentally different approach, since there is a substantial danger of just reexperiencing all the problems others has had before before they learned from it. Cheers, Christian ¹ I have even written a template that many GNOME software maintainers can opt to use to point new translation volunteers in the right direction: http://www.gnome.org/~menthos/package-translation-guide-template.html

1 0

Fedora and Translation Teams
by Mohammed Elzubeir 25 Jun '04

25 Jun '04

Salam, This is intended to all translators involved in Fedora, whether they are involved for Arabic or any other language. It is also intended for the people who shape the policies and tools used by and for the translators. To all Arabeyes members who are involved in translations, I would strongly advise you to join the fedora translation list [1] to voice your opinions, in order to allow the Fedora maintainers to better understand our requirements. Introduction ------------ Fedora recently announced [2] a new system which nullifies pre-existing language translation teams. This is not to say that they had such an explicit policy, in the past but they are now saying that it is definitely not the policy. What do they want to do then? They want to have translator per module. What does this mean? Simple. There is module A that translator X can take, translate, release. Translator Y comes along, takes A, translates, releases. The same goes for modules B, C, etc. Sounds good, eh? More people can easily contribute. What this will result in is complete and utter chaos. Allow me to elaborate. The Loss of Consistency ----------------------- There will be absolutely no conherence among translations. Each translator, depending on their language skills will have their own interpretation of strings. They will also have their own vocabulary that will most certainly conflict with someone else's in the overall translation. The Loss of Quality Control --------------------------- Since there is no group overseeing the quality of the translation, there are no assurances that the quality of translation is up to any standard. So who says what is standard? In the case of Arabic, the Arabeyes Project [3] has set up a committee (Quality Assurance Comittee [4]) that is specifically tasked with overseeing such standardizations across all translation projects. This is something that other projects can learn from. However, with such a scheme standards published by the QAC have no means of being implemented. The Loss of Communication ------------------------- Since there is no group, each individual translator is on their own island with their own ideas of how things should be done. This does not affect Fedora alone. This affects how Arabic is translated across a variety of localized applications and libraries. This additionally creates a very serious problem for a large project, like Arabeyes. For example, in order to perform CVS sync's, the maintainer now has to manually see what module he still has control over and what modules he does not. In other words, a 5 minutes job will now take 50 minutes. The Loss of a Community ----------------------- This scheme completely obliterates the sense and spirit of a community. In the case of Arabic, this took very hard long years to build and foster. With such a scheme, this community no longer needs to exist and is simply put back to an individual doing a couple strings and going home forgetting about the work he/she has modified. The Loss of Credit ------------------ Arabeyes has taken great pains to ensuring that credit is given to each and every individual who has contributed in any way, shape or form. With the current scheme, this is no longer guaranteed. Conclusion ---------- Past experiences from projects such as KDE, GNOME, Mandrake, etc. should be a good reference point to anyone outlining a localization policy for a project of the size of Fedora. Fedora's point of view is, if a team maintainer is needed, we can do that, as long as no one objects. However, it is not clear as to what would be done if someone objects for no reason. I can simply sit there on the list and object to every maintainer who comes up, just in spite of the project. Would that be taken seriously? What if I have a personal agenda against an individual? Would that suffice? What if, what if? These questions do not have answers yet. It is our hope that this policy would be reviewed and discussed with the community of the many language teams and individual translators, before it is being made as policy. We also hope that this would result in a more reasonable policy that accounts to the fact that some languages already indeed have a large set of translators and contributors who are organized and structured. It is also our hope that other language teams of translators would join us in our plea to Fedora to re-consider this policy. References ---------- [1] https://listman.redhat.com/mailman/listinfo/fedora-trans-list/ [2] https://listman.redhat.com/archives/fedora-trans-list/2004-June/msg00046.ht… [3] http://www.arabeyes.org/ [4] http://wiki.arabeyes.org/QAC -- ------------------------------------------------------- | Mohammed Elzubeir | Visit us at: | | | http://www.arabeyes.org/ | | Arabeyes Project | Homepage: | | Unix the 'right' way | http://elzubeir.fakkir.net/ | ------------------------------------------------------- _______________________________________________ Doc mailing list Doc(a)arabeyes.org http://lists.arabeyes.org/mailman/listinfo/doc

1 0

Call to the RedHat CVS admins, Macedonian translation
by Томислав Марковски 25 Jun '04

25 Jun '04

Dear All, Our LUG has recently started translating the fedora packages to Macedonian. We're about to finish the translations, but cannot update the CVS as there are no previous mk.po files to update. Add/commit return "no permission errors". Please take the neccessary steps to help us synchronize the CVS with macedonian translation files. Thank you on behalf of our LUG. Kind Regards, Tomislav Markovski

2 2

Re: Annoucement: New translation status page is installed
by Youcef Rabah Rahal 25 Jun '04

25 Jun '04

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Bernd, Some commit errors: Testing ar.po... **** Access allowed: rahal is in ACL for rhn-applet. Testing ar.po... [specspo/dist/ar.po] is not assigned to you. **** Access allowed: rahal is in ACL for specspo/dist. cvs server: Pre-commit check failed cvs [server aborted]: correct above errors first! Even though I have this file assigned to me. Regards, - -- Youcef R. Rahal Arabeyes.org http://www.arabeyes.org/~rahal -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA21kmHDRR6Cd0eSYRAv8KAKDv4I/HztbA89j8PIPKCvI3GCDgNwCffGqo sskED+Jvb9a1If+khAJEnkc= =GHCs -----END PGP SIGNATURE-----

3 7

=== HELP! ===
by Andrei Nestor 25 Jun '04

25 Jun '04

Hello, There seem to be some problems with my cvs account. Although I am able to authenticate into the new system that's been set up, when I do so I get a message saying "Unknown translator: dannutz". I have previously deleted and then re-created my account, and I didn't receive the confirmation message which leads me to believe that my account might be in a strange inactive state. Can anyone help? Thanks, Andrei PS: the account name is "dannutz"

3 3

Recent discussions
by Sarah Wang 25 Jun '04

25 Jun '04

Hi all, I have to say that the past two or three days is the most exciting period of this mailing list since Fedora Translation Project started :) It's great to have so many people join the discussion and give their opinions from different perspectives. I'd like to explain a few things raised among the discussions. 1. About CVS access. Someone mentioned that it was too easy to get a CVS account. True. Currently anyone who has a valid email address can be granted CVS access to the commit locale of his/her choice. It was because in the early phase of the project we'd like to encourage people to participate and to start forming teams. There is no way to know or qualify people - on what basis should we give someone access to cvs while denying others? If the person is a GNOME or KDE coordinator then he/she should be the default coordinator for Fedora? There is no convincing formula. I believe by adopting an open policy then close the loopholes and fixing problems as they arise will maximise the community participation. (BTW, your cvs account has very limited rights, so don't even think of misuse it ;) ). It is easier to add features and put limitations on accounts than to remove features/restrictions. In the future process development, we may be able to have different level of cvs accounts. For example, a proofreader's account may have more rights than a new translator's account. 2. Coordinator's role I believe a coordinator's role is not *to control* how things should be but to stay *in control* of how things are. People participate one project naturally form groups. Some are small - relatively easy to coordinate and come to a resolution. Some groups are quite large with hundreds of members - it's quite a task to keep things organised and come to a consensus on discussions. For any languages that don't have a separate mailing list yet, I'd like to see the translators of the same language discover each other and form a group. If there are five or more people in the group, just elect your own coordinator and send me an email to request a separate mailing list. 3. Tools vs. Teamwork Tools will never eliminate the need of teamwork. The new status page is designed to ease the work involved in coordination. For smaller groups, it may be very effective to notify through mailing list about the work he/she is undertaking, but for groups with hundreds of members it's hard to track who is doing what through mailing list notification. It may seem cumbersome to have to go through take/release when you know you are the only translator out there :) but it may not be the case tomorrow, someone else may signed up to be a translator and want to help out. There are lots of things tools cannot replace teamwork, such as quality control, vocabulary consistency etc, but tools (or we hope to develop/modify tools) could help with those activities. The status page or any future enhancement is by no means a replacement for teamwork. 4. Red Hat people Fedora project is Red Hat sponsored open source project, naturally you will see plenty of people with "redhat.com" email address. That doesn't mean anything said by anyone(a)redhat.com is official. Like everyone here, he/she is also a participant/contributor. Fedora is a community project and anyone participate the project should respect the community, Red Hat people is no exception. Last but not the least, I know it's pretty hard to stay cool in a heated discussion but please keep in mind when you post to this mailing list that everyone is entitled to his/her opinion and we may have different approaches but we all have the same goal. All constructive suggestions, debates, and criticisms are welcome in this list. Sarah

2 1

Re: Re: Annoucement: New translation status page is installed
by hutuworm 22 Jun '04

22 Jun '04

Bernd Groh, It would be better if the system can release the module automatically after the taken module's translator check in the updated module. :D ======= 2004-06-22 17:38:32 Quote from your mail ======= >If you have only 2 translators, then it may not be a problem, it gets >more difficult with 10. And if you have 20+ translators to a language, >peer-to-peer communication has proven not to be ideal. In this way, >everyone is informed of who is doing what. You only have to [Take] a >module once, and then it belongs to you until the translation is >finished, or you [Release] it. We believed this mechanism to be >extremely helpful. > >Regards, >Bernd > >Sharuzzaman Ahmat Raslan schrieb: > >> Sulyok Peti wrote: >> >>> My opinion is that conflicts should be resolved according to the docs of >>> CVS. By using this take-over tech. teamwork has to be done outside CVS, >>> or by using another CVS repository. This might be painful for teams >>> working on the large PO files like dist and anaconda. >>> Regards, >>> Peti >> >> >> Agreed. Previously, I and another Malay translator working together >> with anaconda totally using CVS. No issue about take over. Both >> updates their own tree and resolve any conflict prior to committing >> new translation. It works well and we manage to complete it before FC2 >> release. >> >> I don't see the benefit of the take over mechanism here. Can anybody >> explain? >> >> Thanks. >> >> ----- >> Sharuzzaman Ahmat Raslan >> >> >> -- >> Fedora-trans-list mailing list >> Fedora-trans-list(a)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(a)redhat.com >http://www.redhat.com/mailman/listinfo/fedora-trans-list > ================================================== hutuworm

2 1

account update
by Andrei Nestor 22 Jun '04

22 Jun '04

Hi all, Does anyone know the proper procedure for updating the ssh key for the cvs account? Thanks, Andrei

3 8

Re: Re: Annoucement: New translation status page is installed
by hutuworm 22 Jun '04

22 Jun '04

Sharuzzaman Ahmat Raslan, Set a expire time first, for example 3 hours, if the translator can't check in the updated module in 3 hours, then the [Take] status will be released? ======= 2004-06-22 17:55:55 Quote from your mail ======= >Bernd Groh wrote: >> If you have only 2 translators, then it may not be a problem, it gets >> more difficult with 10. And if you have 20+ translators to a language, >> peer-to-peer communication has proven not to be ideal. In this way, >> everyone is informed of who is doing what. You only have to [Take] a >> module once, and then it belongs to you until the translation is >> finished, or you [Release] it. We believed this mechanism to be >> extremely helpful. >> >> Regards, >> Bernd > >Okay, but what if one of the translator [Take] the module, but left it >there untranslated? Can other [Release] the module or it just locked there? > >If it locked there, can other translator [Kill] the translator, and >[Rob] the module? > >----- >Sharuzzaman Ahmat Raslan > > >-- >Fedora-trans-list mailing list >Fedora-trans-list(a)redhat.com >http://www.redhat.com/mailman/listinfo/fedora-trans-list > >. ================================================== hutuworm

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

trans June 2004