Hello all,
The new translation status page has been installed: http://elvis.redhat.com/cgi-bin/i18n-status
You will notice that there is a new column called "Availability" for each package. It either says "Finished" (if the translation is 100%) or has a "Take" button (if the translation is not 100%). This feature is designed to minimise the commit conflicts and better coordinate the translation activity within the same language group. If you wish to finish the translation of a package, just click "Take" button, fill in your login and password. Then you will be able to finish and commit the translation to cvs. All cvs account holders should have received or soon to receive information about login name and password.
Please feel free to ask if you have any questions and encountered any problems.
Regards, Sarah
On Tuesday 22 June 2004 06:15, Sarah Wang wrote:
Hello all,
The new translation status page has been installed: http://elvis.redhat.com/cgi-bin/i18n-status
You will notice that there is a new column called "Availability" for each package. It either says "Finished" (if the translation is 100%) or has a "Take" button (if the translation is not 100%). This feature is designed to minimise the commit conflicts and better coordinate the translation activity within the same language group. If you wish to finish the translation of a package, just click "Take" button, fill in your login and password. Then you will be able to finish and commit the translation to cvs. All cvs account holders should have received or soon to receive information about login name and password.
Please feel free to ask if you have any questions and encountered any problems.
Regards, Sarah
I checked http://elvis.redhat.com/cgi-bin/i18n-status and saw that system-switch-mail is 100% untranslated, so I took it. After this I did cvs -z9 up translate ... cvs server: Updating translate/redhat-switchmail P translate/redhat-switchmail/ta.po cvs server: Updating translate/rhgb ... Which shows that the Bulgarian translation (bg.po) has not been updated at least two months. When I opend translate/redhat-switchmail/bg.po I saw it was fully translated by Boril Gourinov [ boril <at> bitex <dot> com ], and was last changed Mar 16. Where's the problem? Can someone unassign this? How often is i18n-status updated? (I refreshed the page many times)
On Tuesday 22 June 2004 09:37, Doncho N. Gunchev wrote:
On Tuesday 22 June 2004 06:15, Sarah Wang wrote:
Hello all,
The new translation status page has been installed: http://elvis.redhat.com/cgi-bin/i18n-status
...
I checked http://elvis.redhat.com/cgi-bin/i18n-status and saw thatsystem-switch-mail is 100% untranslated, so I took it...
... I released it, but I still wonder why it shows 0% when it is fully translated? When/how is it updated?
Try a fresh checkout, just in case.
Bernd
Doncho N. Gunchev schrieb:
On Tuesday 22 June 2004 09:37, Doncho N. Gunchev wrote:
On Tuesday 22 June 2004 06:15, Sarah Wang wrote:
Hello all,
The new translation status page has been installed: http://elvis.redhat.com/cgi-bin/i18n-status
...
I checked http://elvis.redhat.com/cgi-bin/i18n-status and saw that system-switch-mail is 100% untranslated, so I took it...
... I released it, but I still wonder why it shows 0% when it is fully translated? When/how is it updated?
2004-06-22, k keltezéssel 05:15-kor Sarah Wang ezt írta:
Hello all,
The new translation status page has been installed: http://elvis.redhat.com/cgi-bin/i18n-status
You will notice that there is a new column called "Availability" for each package. It either says "Finished" (if the translation is 100%) or has a "Take" button (if the translation is not 100%). This feature is designed to minimise the commit conflicts and better coordinate the translation activity within the same language group. If you wish to finish the translation of a package, just click "Take" button, fill in your login and password. Then you will be able to finish and commit the translation to cvs. All cvs account holders should have received or soon to receive information about login name and password.
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
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
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@redhat.com http://www.redhat.com/mailman/listinfo/fedora-trans-list
On Tue, Jun 22, 2004 at 07:38:32PM +1000, 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.
On the other hand it is just annoying if there is only one or two translators or if you want to commit a one-liner fix to a module "owned" by someone else.
Having the mechanism available is definitely useful but maybe it would be easier for everybody not to enforce it for CVS access. Mirek
Miloslav Trmac schrieb:
On Tue, Jun 22, 2004 at 07:38:32PM +1000, 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.
On the other hand it is just annoying if there is only one or two translators or if you want to commit a one-liner fix to a module "owned" by someone else.
For the case there's only one or two translators, we can potentially, if desired, exclude these languages from the process. For the case that you simply want to commit a one-liner to a module "owned" by someone else, I strongly disagree. Why? Because if someone is taking a module, that person is starting to translate it (or so it should be). If you fix a one-liner while another person is translating the file, you might just introduce a conflict.
Having the mechanism available is definitely useful but maybe it would be easier for everybody not to enforce it for CVS access. Mirek
The reason we introduced it, is because we had a lot of people asking for exactly such mechanism. But I'm happy to discuss the issue, and am not set either way. I simply felt it was the right thing to do. I could have been wrong.
Bernd
-- Fedora-trans-list mailing list Fedora-trans-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-trans-list
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
Sharuzzaman Ahmat Raslan schrieb:
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?
If a translator does that, *I* want to know it, and then I'll release it and send this translator a "friendly" reminder. To auto-release it after a certain time of inactivity is on the ToDo list, btw, and these incremental upgrades shouldn't take as long as putting the new version up in the first place! :)
Bernd
Sharuzzaman Ahmat Raslan
-- Fedora-trans-list mailing list Fedora-trans-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-trans-list
On Tue, 2004-06-22 at 11:38, 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,
I think we should have been consulted about this change before it was applied, no? Maybe you did and I missed it, sorry! After all, the translation project is a true community effort, and we might have something to say about what's best for us too...
everyone is informed of who is doing what. You only have to [Take] a
You can do that with too with translation teams.
module once, and then it belongs to you until the translation is
What if it never gets finished? Or never released, or someone else can translate it faster, or if it contains errors? Or if it does't use the same terminology/style as other translations?
finished, or you [Release] it. We believed this mechanism to be extremely helpful.
Maybe it is, but it causes some concern to me. When I joined the translation project for Fedora, I was told to get in contact with the people making the translation of the language I wanted to translate into. That way we would use de _same_ vocabulary, same terms, same style, etc... But with this new system, it will be possible to see more eclectic translations, and might not pass "quality" controls that some translator teams may have.
As for our team (10-15 persons), the procedure is basically to assign a module to someone in the team, let him/her translate it, and finally post the translation to our list so everybody can review it, making sure the right terminology is used, and that there are no spelling or grammar errors, etc, and finally we commit it. Even with all this, errors occur, but many are hunted prior to the commit. We solve problems by having a coordinator, and a page with who is translating what, and status, much like your status page, but ours is crappier :)
It is true that with the new system this can also be done, but it might not be enforced.
On the other hand it restricts the assignment of modules to people using CVS. Just as an example, in our team we have some very good translators that use Windows, and have no idea about CVS or SSH keys, but are very valuable to us.
IMHO, I think a better approach is that of the gnome translation project, having a coordinator for a language and making him/her commit the changes, but I believe Christian Rose has more to say if this is the case than I do.
And just out of curiosity, are new maintainers automatically subscribed to the translation list at fedora-trans-list@redhat.com?
My 2 cents...
Regards,
/Josep
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
Josep Puigdemont schrieb:
On Tue, 2004-06-22 at 11:38, 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,
I think we should have been consulted about this change before it was applied, no? Maybe you did and I missed it, sorry! After all, the translation project is a true community effort, and we might have something to say about what's best for us too...
I did this on request from a lot of people within the community, and I believed their reasoning to be very valid.
everyone is informed of who is doing what. You only have to [Take] a
You can do that with too with translation teams.
Of course you can, we simply agreed with a lot of the people from within the community, that it would be a very useful mechanism.
module once, and then it belongs to you until the translation is
What if it never gets finished? Or never released, or someone else can translate it faster, or if it contains errors? Or if it does't use the same terminology/style as other translations?
If it doesn't get finished in time, we'll release it. If somone else can translate it faster, so what? And I don't think all the other problems are to be associated with the new system, you have the same problems without it.
finished, or you [Release] it. We believed this mechanism to be extremely helpful.
Maybe it is, but it causes some concern to me. When I joined the translation project for Fedora, I was told to get in contact with the people making the translation of the language I wanted to translate into. That way we would use de _same_ vocabulary, same terms, same style, etc... But with this new system, it will be possible to see more eclectic translations, and might not pass "quality" controls that some translator teams may have.
Why? Why does the new system keep you from communicating with other translators in your language?
As for our team (10-15 persons), the procedure is basically to assign a module to someone in the team, let him/her translate it, and finally post the translation to our list so everybody can review it, making sure the right terminology is used, and that there are no spelling or grammar errors, etc, and finally we commit it. Even with all this, errors occur, but many are hunted prior to the commit. We solve problems by having a coordinator, and a page with who is translating what, and status, much like your status page, but ours is crappier :)
It is true that with the new system this can also be done, but it might not be enforced.
Who is actually commiting the files? Only the coordinator?
On the other hand it restricts the assignment of modules to people using CVS. Just as an example, in our team we have some very good translators that use Windows, and have no idea about CVS or SSH keys, but are very valuable to us.
Who is commiting their files?
IMHO, I think a better approach is that of the gnome translation project, having a coordinator for a language and making him/her commit the changes, but I believe Christian Rose has more to say if this is the case than I do.
The new system has the option of a maintainer. I can simply set the coordinator the maintainer of all modules of a certain language, and this maintainer then has full access to the cvs for that language. In how is that different to what gnome is doing? Nobody keeps only one person from commiting. We simply disallow two non-maintainers from commiting at the same time.
And just out of curiosity, are new maintainers automatically subscribed to the translation list at fedora-trans-list@redhat.com?
No.
Regards, Bernd
My 2 cents...
Regards,
/Josep
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@redhat.com http://www.redhat.com/mailman/listinfo/fedora-trans-list
Bernd Groh wrote:
I did this on request from a lot of people within the community, and I believed their reasoning to be very valid.
Just to add my opinion, this idea is useful. The pt_BR team was doing something similar using the mailing list and a website and a structure like this saves a lot of work...
What if it never gets finished? Or never released, or someone else can translate it faster, or if it contains errors? Or if it does't use the same terminology/style as other translations?
If it doesn't get finished in time, we'll release it. If somone else can translate it faster, so what? And I don't think all the other problems are to be associated with the new system, you have the same problems without it.
How will you define the automatic release interval (if you are going to implement this)? One possible problem I can imagine is that when the strings freeze date comes closer , a auto-release should happen faster than during the rest of the development. Maybe a 1 week release interval and a 2 day interval during development phase?
Why? Why does the new system keep you from communicating with other translators in your language?
It doesn't.. The only problem I saw is that the pages don't show any details on how to contact the other translators.. Maybe each page could have something like "To contact the X translation team , send a e-mail to fedora-trans-X at redhat dot com." . The only place that mentions the mailing lists is http://fedora.redhat.com/projects/translations/ , so a reminder would be useful...
As for our team (10-15 persons), the procedure is basically to assign a module to someone in the team, let him/her translate it, and finally post the translation to our list so everybody can review it, making sure the right terminology is used, and that there are no spelling or grammar errors, etc, and finally we commit it. Even with all this, errors occur, but many are hunted prior to the commit. We solve problems by having a coordinator, and a page with who is translating what, and status, much like your status page, but ours is crappier :)
It is true that with the new system this can also be done, but it might not be enforced.
Who is actually commiting the files? Only the coordinator?
Probably. Or any other person who has CVS access. This is probably like what we had on the pt_BR team. Just before the string freeze for FC2 , the creation of cvs accounts was suspended for a time... While a few of the translators (including me) were waiting for an account, one person from the team sent the .po files to the mailing list , we translated and sent it back to him so he could commit the changes.
And just out of curiosity, are new maintainers automatically subscribed to the translation list at fedora-trans-list@redhat.com?
No.
It would be interesting if the new mantainers got an e-mail reminding them of the mailing list... Maybe something like "All the changes to the translation system and discussion about translation bugs happen on fedora-trans-list at redhat dot com, so it's reccomended that you join this mailing list , along with the mailing list for your specific translation project , which is fedora-trans-X at redhat dot com" or something like that...
-- Pedro Macedo
Pedro Fernandes Macedo schrieb:
Bernd Groh wrote:
I did this on request from a lot of people within the community, and I believed their reasoning to be very valid.
Just to add my opinion, this idea is useful. The pt_BR team was doing something similar using the mailing list and a website and a structure like this saves a lot of work...
Thank you.
What if it never gets finished? Or never released, or someone else can translate it faster, or if it contains errors? Or if it does't use the same terminology/style as other translations?
If it doesn't get finished in time, we'll release it. If somone else can translate it faster, so what? And I don't think all the other problems are to be associated with the new system, you have the same problems without it.
How will you define the automatic release interval (if you are going to implement this)? One possible problem I can imagine is that when the strings freeze date comes closer , a auto-release should happen faster than during the rest of the development. Maybe a 1 week release interval and a 2 day interval during development phase?
That is a very good question and one of the reasons why I haven't implemented any such thing yet. If the majority of the community agrees that the system should be used, and not that cvs access should be unrestricted, then I believe we should discuss this issue on list.
Why? Why does the new system keep you from communicating with other translators in your language?
It doesn't.. The only problem I saw is that the pages don't show any details on how to contact the other translators.. Maybe each page could have something like "To contact the X translation team , send a e-mail to fedora-trans-X at redhat dot com." . The only place that mentions the mailing lists is http://fedora.redhat.com/projects/translations/ , so a reminder would be useful...
True. Not every language has a mailing list though, and to find the status pages, you have to go to http://fedora.redhat.com/projects/translations/ too. But I agree that a mailto: to the individual mailing lists (if exist) on the status page for this particular language would be helpful.
As for our team (10-15 persons), the procedure is basically to assign a module to someone in the team, let him/her translate it, and finally post the translation to our list so everybody can review it, making sure the right terminology is used, and that there are no spelling or grammar errors, etc, and finally we commit it. Even with all this, errors occur, but many are hunted prior to the commit. We solve problems by having a coordinator, and a page with who is translating what, and status, much like your status page, but ours is crappier :)
It is true that with the new system this can also be done, but it might not be enforced.
Who is actually commiting the files? Only the coordinator?
Probably. Or any other person who has CVS access. This is probably like what we had on the pt_BR team. Just before the string freeze for FC2 , the creation of cvs accounts was suspended for a time... While a few of the translators (including me) were waiting for an account, one person from the team sent the .po files to the mailing list , we translated and sent it back to him so he could commit the changes.
The person commiting should then take the module. But if it's a coordinator, and always the same, this person should be a maintainer even.
And just out of curiosity, are new maintainers automatically subscribed to the translation list at fedora-trans-list@redhat.com?
No.
It would be interesting if the new mantainers got an e-mail reminding them of the mailing list... Maybe something like "All the changes to the translation system and discussion about translation bugs happen on fedora-trans-list at redhat dot com, so it's reccomended that you join this mailing list , along with the mailing list for your specific translation project , which is fedora-trans-X at redhat dot com" or something like that...
Good point, I'd prefer an invite over an automatic subscription.
Bernd
-- Pedro Macedo
-- Fedora-trans-list mailing list Fedora-trans-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-trans-list
For the delay I'd like to see breaking working for any time duration but that it
a) warned you how long/short the time the previous owner had it b) emailed them or the i18n list with your reason if you did go ahead
social pressure should then do the rest 8)
Alan Cox schrieb:
For the delay I'd like to see breaking working for any time duration but that it
a) warned you how long/short the time the previous owner had it b) emailed them or the i18n list with your reason if you did go ahead
social pressure should then do the rest 8)
I do like this model, what does everyone else think of it?
Bernd
-- Fedora-trans-list mailing list Fedora-trans-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-trans-list
Pedro Fernandes Macedo wrote:
How will you define the automatic release interval (if you are going to implement this)? One possible problem I can imagine is that when the strings freeze date comes closer , a auto-release should happen faster than during the rest of the development. Maybe a 1 week release interval and a 2 day interval during development phase?
I would prefer 24 hours release on normal development phase and 1 hour on approaching (2 weeks before) deadline.
Currently, I'm doing Take, Commit, Release style, where I only take when I'm ready to commit, committing the changes, and then releasing it back after commit. By doing that, other translator will have the opportunity to translate, and it's not totally assigned to me only.
----- Sharuzzaman Ahmat Raslan
Sharuzzaman Ahmat Raslan schrieb:
Pedro Fernandes Macedo wrote:
How will you define the automatic release interval (if you are going to implement this)? One possible problem I can imagine is that when the strings freeze date comes closer , a auto-release should happen faster than during the rest of the development. Maybe a 1 week release interval and a 2 day interval during development phase?
I would prefer 24 hours release on normal development phase and 1 hour on approaching (2 weeks before) deadline.
I believe 24 hours on normal development is acceptable, since you should do a commit overnight, even if you haven't finished.
Currently, I'm doing Take, Commit, Release style, where I only take when I'm ready to commit, committing the changes, and then releasing it back after commit. By doing that, other translator will have the opportunity to translate, and it's not totally assigned to me only.
The use I intended was that first, you check the status pages for availability of a module. If it is available, and you intend to translate it, you take it. Then you do a cvs up, to make sure you're up to date. Then you work on it for as long as you wish, do a commit, and release it again if you don't intend to keep working on it for a while. If you change your mind and you don't intend to work on it anymore, release it straight away. If you only take it before you do a commit, you leave a lot of room for conflicts.
Bernd
Sharuzzaman Ahmat Raslan
-- Fedora-trans-list mailing list Fedora-trans-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-trans-list
On Wed, 2004-06-23 at 02:19, Bernd Groh wrote:
Josep Puigdemont schrieb:
On Tue, 2004-06-22 at 11:38, 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,
I think we should have been consulted about this change before it was applied, no? Maybe you did and I missed it, sorry! After all, the translation project is a true community effort, and we might have something to say about what's best for us too...
I did this on request from a lot of people within the community, and I believed their reasoning to be very valid.
I completely missed that, and wasn't aware of the fact that this was a community request, and being this the functionality the community wanted, it seems very logical that it was implemented.
Anyway, I still disagree in not having translation teams instead, and I would be a bad member of the community if I didn't at least mention it (even if it is only for myself who I'm speaking for).
I appreciate the advantages of this new method: * it's a community request * translation work accessible to everybody * avoids duplicated work * Anyone can see who's doing what in a very organized way * I think I miss a few more here...
It would also be interesting to see which points you (plural) think are not so good, or could be improved.
For me, the problem I see is that it doesn't encourage team work. In any translation project it is very important that all translators get in contact, that way we make sure we all use the same terminology, the same style, etc, and thus we guarantee a certain level of quality and consistency. Quality gets better with time.
In my particular case I can enjoy the experience of a group that has been working with the translation of open source software for more than 7 years. This work includes a great compendium of words and neologisms, a style guide, and a translation memory with more than 62,000 entries. Anyone with sufficient knowledge can do a translation, but although those 7 years of work are accessible to anyone, nobody forces a new translator to use them. On the other hand, if a new translator had to join a team, s/he would have to use the same style and terminology as the rest of the team, which I find _very_ important. For example, the word "File" can be translated into my language as "Fitxer" or "Arxiu". In order to keep consistency we had to decide which one to use and stay with it always, and _that's_ what a translation team can guarantee, and _that_ improves quality and consistency among translations. That's just one example, but there are many, specially those related to "new" terms like "buffer" or "cache", for which many people use the English term when there already is a translation.
What if it never gets finished? Or never released, or someone else can translate it faster, or if it contains errors? Or if it does't use the same terminology/style as other translations?
If it doesn't get finished in time, we'll release it. If somone else can translate it faster, so what? And I don't think all the other problems are to be associated with the new system, you have the same problems without it.
True, you're right, but, as explained above, the "other problems" are not present if translation teams are used.
I still think that it would be good to force translators to work and join translation teams.
[cut]
Why? Why does the new system keep you from communicating with other translators in your language?
It doesn't, but the fact that it doesn't, doesn't mean that it makes me communicate with other translators, which, for the reasons explained above, I believe should be enforced.
On the other hand it restricts the assignment of modules to people using CVS. Just as an example, in our team we have some very good translators that use Windows, and have no idea about CVS or SSH keys, but are very valuable to us.
Who is commiting their files?
I was, and I suppose you'll say that I can take the file for them and continue committing their files. True, it is just that I don't want to figure as a translator of something someone else is translating, I would feel like steeling their credit.
IMHO, I think a better approach is that of the gnome translation project, having a coordinator for a language and making him/her commit the changes, but I believe Christian Rose has more to say if this is the case than I do.
The new system has the option of a maintainer. I can simply set the coordinator the maintainer of all modules of a certain language, and this maintainer then has full access to the cvs for that language. In how is that different to what gnome is doing? Nobody keeps only one
That's what I could find: http://developer.gnome.org/projects/gtp/join.html
GNOME makes you be part of a team, you don't get CVS access unless someone vouches for you (iirc) or you have done previous work that proves you should have access (or deserve to).
person from commiting. We simply disallow two non-maintainers from commiting at the same time.
I believe it can be done with teams too.
That's just my opinion and I can be wrong too. So far no one has backed me up, and the community has already spoken, but I had to tell to have the satisfaction of having done [at least for once] my duty :)
Keep up the good work!
Best regards,
Josep
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thursday 24 June 2004 08:58, Josep Puigdemont wrote:
That's just my opinion and I can be wrong too. So far no one has backed me up, and the community has already spoken, but I had to tell to have the satisfaction of having done [at least for once] my duty :)
I think we are in the same boat ;)
You have backup from me.
Regards,
- -- Youcef R. Rahal Arabeyes.org http://www.arabeyes.org/~rahal
Josep Puigdemont schrieb:
On Wed, 2004-06-23 at 02:19, Bernd Groh wrote:
Josep Puigdemont schrieb:
On Tue, 2004-06-22 at 11:38, 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,
I think we should have been consulted about this change before it was applied, no? Maybe you did and I missed it, sorry! After all, the translation project is a true community effort, and we might have something to say about what's best for us too...
I did this on request from a lot of people within the community, and I believed their reasoning to be very valid.
I completely missed that, and wasn't aware of the fact that this was a community request, and being this the functionality the community wanted, it seems very logical that it was implemented.
Anyway, I still disagree in not having translation teams instead, and I would be a bad member of the community if I didn't at least mention it (even if it is only for myself who I'm speaking for).
Nobody keeps anyone from having translations teams, I think it is a good idea, but not one we'll be enforcing. This is something that has to evolve out of the community itself.
I appreciate the advantages of this new method:
- it's a community request
- translation work accessible to everybody
- avoids duplicated work
- Anyone can see who's doing what in a very organized way
- I think I miss a few more here...
It would also be interesting to see which points you (plural) think are not so good, or could be improved.
Agree. I'd be happy to receive any feedback, as long as it appears constructive, and I believe your comments are.
For me, the problem I see is that it doesn't encourage team work. In any translation project it is very important that all translators get in contact, that way we make sure we all use the same terminology, the same style, etc, and thus we guarantee a certain level of quality and consistency. Quality gets better with time.
I agree to some extent, in some cases, it is hard to manage though. Not talking about everyone agreeing on the same terminology. For some languages, that can indeed be extremely difficult, if it is possible at all.
In my particular case I can enjoy the experience of a group that has been working with the translation of open source software for more than 7 years. This work includes a great compendium of words and neologisms, a style guide, and a translation memory with more than 62,000 entries. Anyone with sufficient knowledge can do a translation, but although those 7 years of work are accessible to anyone, nobody forces a new translator to use them. On the other hand, if a new translator had to join a team, s/he would have to use the same style and terminology as the rest of the team, which I find _very_ important. For example, the word "File" can be translated into my language as "Fitxer" or "Arxiu". In order to keep consistency we had to decide which one to use and stay with it always, and _that's_ what a translation team can guarantee, and _that_ improves quality and consistency among translations. That's just one example, but there are many, specially those related to "new" terms like "buffer" or "cache", for which many people use the English term when there already is a translation.
Believe me, this point is very well taken, but at the same time, you can watch who is translating what, and if you recognize a new translator, invite her/him to your team. Why does it always have to be the new translator who gets in contact with the group? I personally believe in making it as easy for people to get started as possible. Wouldn't it be easier for the group to send an invite?
What if it never gets finished? Or never released, or someone else can translate it faster, or if it contains errors? Or if it does't use the same terminology/style as other translations?
If it doesn't get finished in time, we'll release it. If somone else can translate it faster, so what? And I don't think all the other problems are to be associated with the new system, you have the same problems without it.
True, you're right, but, as explained above, the "other problems" are not present if translation teams are used.
But these aren't associated with the new system, since it is even more restrictive than the previous one.
I still think that it would be good to force translators to work and join translation teams.
I believe it would be good to encourage them, I disagree with forcing them.
Why? Why does the new system keep you from communicating with other translators in your language?
It doesn't, but the fact that it doesn't, doesn't mean that it makes me communicate with other translators, which, for the reasons explained above, I believe should be enforced.
I don't think it should. I believe it makes it harder for new translators to get started. Nobody keeps you from encouraging new translators to join your team.
On the other hand it restricts the assignment of modules to people using CVS. Just as an example, in our team we have some very good translators that use Windows, and have no idea about CVS or SSH keys, but are very valuable to us.
Who is commiting their files?
I was, and I suppose you'll say that I can take the file for them and continue committing their files. True, it is just that I don't want to figure as a translator of something someone else is translating, I would feel like steeling their credit.
Why won't you be the maintainer then? ;) And being a current translator is not about credit, it's so that people know who is currently translating the file, or who intends a commit, so that other people know what to and what not to translate.
IMHO, I think a better approach is that of the gnome translation project, having a coordinator for a language and making him/her commit the changes, but I believe Christian Rose has more to say if this is the case than I do.
The new system has the option of a maintainer. I can simply set the coordinator the maintainer of all modules of a certain language, and this maintainer then has full access to the cvs for that language. In how is that different to what gnome is doing? Nobody keeps only one
That's what I could find: http://developer.gnome.org/projects/gtp/join.html
GNOME makes you be part of a team, you don't get CVS access unless someone vouches for you (iirc) or you have done previous work that proves you should have access (or deserve to).
Yes, that's why I never got any cvs access. The first maintainer I send an email to wasn't the maintainer anymore since ages, and the second one never replied. That's a really good system! I understand that maintainers of modules are busy with other things, this is voluntary after all, but that's exactly why I prefer a system in which you can just get started (ignoring the problems we had with account activation now and then :)), and if a maintainer has time, s/he can look at who was doing what and then either invite a person to become part of a group, or what ever s/he may chose. I prefer to assume that everyone deserves to participate, and then restrict or disable someones access if the opposite becomes apparent.
person from commiting. We simply disallow two non-maintainers from commiting at the same time.
I believe it can be done with teams too.
And I don't disagree.
That's just my opinion and I can be wrong too. So far no one has backed me up, and the community has already spoken, but I had to tell to have the satisfaction of having done [at least for once] my duty :)
And so you should! And I'm not doing anything else than stating my opinion either. :)
Best Regards, Bernd
Keep up the good work!
Best regards,
Josep
-- Fedora-trans-list mailing list Fedora-trans-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-trans-list
On Thu, Jun 24, 2004 at 07:28:57PM +1000, Bernd Groh wrote:
Josep Puigdemont schrieb:
That's what I could find: http://developer.gnome.org/projects/gtp/join.html
GNOME makes you be part of a team, you don't get CVS access unless someone vouches for you (iirc) or you have done previous work that proves you should have access (or deserve to).
Yes, that's why I never got any cvs access. The first maintainer I send an email to wasn't the maintainer anymore since ages, and the second one never replied. That's a really good system!
If you can't contact a GTP language maintainer, just mention it on gnome-i18n@gnome.org . The GTP coordinator then issues a "public call to respond" and the maintainer is replaced if he/she doesn't respond in 14 days. Mirek
On Thu, 2004-06-24 at 11:28, Bernd Groh wrote:
Josep Puigdemont schrieb:
Anyway, I still disagree in not having translation teams instead, and I would be a bad member of the community if I didn't at least mention it (even if it is only for myself who I'm speaking for).
Nobody keeps anyone from having translations teams, I think it is a good idea, but not one we'll be enforcing. This is something that has to evolve out of the community itself.
Just to summarize my position: As long as this system allows unconsistent translations, I'll think it is flawed, and thus I'll oppose to it (in a nice way). That I oppose to it doesn't mean I will not respect it.
And yes, I think the translation of Fedora has been flawed since day one, it's up to us to get it right. I was really surprised when I got the CVS account at Red Hat for translations, without questioning or hesitation from your side, I appreciate the trust, but it can also bring undesired lateral effects, fortunately I'm a nice guy :)
Finally, I believe that keeping the distribution consistent and coherent is more important than getting a new translator started.
Colophon: Who can tell if a translation is "right" or not? Or if it is "consistent" or not? that will be hard... maybe looking at "previous art", merit, or experience... Tough question, really, that's the weak part of my argument. Probably a team of translators for the same language would be able to decide what's "right", like in a democracy, as long as anyone can join a translation team, of course :)
On the other hand, if a new translator had to join a team, s/he would have to use the same style and terminology as the rest of the team, which I find _very_ important. For example, the word "File" can be translated into my language as "Fitxer" or "Arxiu". In order to keep consistency we had to decide which one to use and stay with it always, and _that's_ what a translation team can guarantee, and _that_ improves quality and consistency among translations. That's just one example, but there are many, specially those related to "new" terms like "buffer" or "cache", for which many people use the English term when there already is a translation.
Believe me, this point is very well taken, but at the same time, you can watch who is translating what, and if you recognize a new translator, invite her/him to your team. Why does it always have to be the new translator who gets in contact with the group? I personally believe in making it as easy for people to get started as possible. Wouldn't it be easier for the group to send an invite?
Right, if there's the case I (or someone else) will ask a new translator to join us, of course. It is just that s/he might not want to do it, or might not want to use the same terminology we've used for the rest of the translations... then what? One application says "Quit" the other says "Exit"... This is the only concern I have, and as a solution I only see enforcing (doh!) translation teams. But maybe that's not the goal of Fedora Translation Project (FTP?, ouch), maybe the goal is just to have the distro translated not consistent as well.
I still think that it would be good to force translators to work and join translation teams.
I believe it would be good to encourage them, I disagree with forcing them.
At least forcing the translator to commit himself to make a translation that will be consistent with the rest of the translations for a particular language. Just another example to illustrate what I mean: "log viewer" (the application) appears in three or four different files: menus, dist, anaconda and redhat-logviewer (iirc). All translations should use the same translation of "log viewer" or we'll confuse the user, but four different translators could use four different translations (yes it could be possible!).
I don't know if Red Hat has a policy on how the interface to the user should be, and in what way should it address the user, for instance if the policy (if any) encourage to ask the user: "Please, press the button", or to order: "Press the button", or at developer's will (which I think would be inconsistent)... Thinks like this make a difference. Our policy, to give yet another example, tells us to address the user as "you" [polite you] ("ni" in Swedish), and orders from the user to the computer are in imperative form. Now, being consistent with this is key. If there's an application that doesn't follow the same style (or policy) it will disturb the user, and will harm the distro (imo). I'm not saying that ours is the best policy, I'm saying that it has to be consistent, and I know you agree, but the new method doesn't guarantee that (or does it?).
Why won't you be the maintainer then? ;) And being a current translator
I'll apply for maintainer of ca (Catalan), if no one objects. The web page doesn't really tell what the role of a maintainer is, though, I think it should be stated somewhere. So I wait until I know what I'm messing with :) Policy on how to become maintainer and how to depose one should be stated too, probably.
is not about credit, it's so that people know who is currently translating the file, or who intends a commit, so that other people know what to and what not to translate.
I just took dist, and it looks kind of unfair to have my name as a Translator, as we're, so far, 4 people working [slowly] on that file, and I am probably the one that has contributed the less. But well, it's something we can live with, I suppose :)
Now, I know I seem to take this a bit religiously, and maybe I do, I just want you to see the light and become a convert, then I shall give you a place in the heaven of translationland :)
Best regards,
Josep
P.S.: I promised myself it would not be a long mail, but... here it is...
Josep,
Just to summarize my position: As long as this system allows unconsistent translations, I'll think it is flawed, and thus I'll oppose to it (in a nice way). That I oppose to it doesn't mean I will not respect it.
Point taken. But I believe every system allows inconsistent translations, as such, every system is flawed, no? ;) Of course, *iff* you have a really dedicated maintainer who QAs all translations before a commit and makes sure everything is consistent, this system actually works, I completely agree! :)
And yes, I think the translation of Fedora has been flawed since day one, it's up to us to get it right. I was really surprised when I got the CVS account at Red Hat for translations, without questioning or hesitation from your side, I appreciate the trust, but it can also bring undesired lateral effects, fortunately I'm a nice guy :)
Finally, I believe that keeping the distribution consistent and coherent is more important than getting a new translator started.
I'd even agree, to why I disagree with your position, I will come to in a minute.
Colophon: Who can tell if a translation is "right" or not? Or if it is "consistent" or not? that will be hard... maybe looking at "previous art", merit, or experience... Tough question, really, that's the weak part of my argument. Probably a team of translators for the same language would be able to decide what's "right", like in a democracy, as long as anyone can join a translation team, of course :)
Agree. :)
Believe me, this point is very well taken, but at the same time, you can watch who is translating what, and if you recognize a new translator, invite her/him to your team. Why does it always have to be the new translator who gets in contact with the group? I personally believe in making it as easy for people to get started as possible. Wouldn't it be easier for the group to send an invite?
Right, if there's the case I (or someone else) will ask a new translator to join us, of course. It is just that s/he might not want to do it, or might not want to use the same terminology we've used for the rest of the translations... then what?
Then what? Well, then we can talk to this person, and if s/he unwilling to use the "right" terminology, then we can think of disabling her/his account. Btw, I do translate 'Forward' with "Next" if 'Next' is meant, and not with "Forward", consistent or not! IMO, it's just plain wrong! ;) Just kidding. :)
One application says "Quit" the other says "Exit"... This is the only concern I have, and as a solution I only see enforcing (doh!) translation teams. But maybe that's not the goal of Fedora Translation Project (FTP?, ouch), maybe the goal is just to have the distro translated not consistent as well.
No, both is the goal. But, really, I much prefer to have one application say "Quit", and another one "Exit", than have either use the english term. Why should a user who always only uses program ("Quit") and never uses program ("Exit") care? And anyway, both are understandable, both are right in some respect and both have meaning to a user. And no, I am *not* arguing that I don't care whether translations are inconsistent or not, I do care a great deal, but I am arguing that I rather have an inconsistent, yet understandable, translation than none at all. *Iff* you have a dedicated maintainer who is willing to coordinate with such a great effort, and can manage that all translators agree on a certain (and not another) terminology, I completely agree with you, then even I believe it's a better way of doing things. But, I doubt it's the case for most of the languages. Some languages don't even have a translator yet, do we not give them access, because we don't speak xyz and nobody is there who could invite them? Some languages might have a lot of translators, but all of them are reluctant to really put that much effort in and be such a maintainer. I, personally, don't like the idea of having a system in place where it is required to have a great maintainer who does all these things, cos if a language doesn't have one, it may just die. No, really, I rather have people contribute unmaintained than not at all. And if there is such great maintainer, well, that is great, you have the option of being a maintainer, and if not for the entire language, for a module, or a group of modules. A maintainer has the additional right to release modules of translators, so they can excercise some level of control. And if somebody 'causes problems after that, well, then even I am happy to kick that person.
At least forcing the translator to commit himself to make a translation that will be consistent with the rest of the translations for a particular language.
I disagree. Asking her/him to do so, yes. And if s/he is unwilling to do so, and doesn't have a good reason of why, then we can indeed disable this persons access.
Just another example to illustrate what I mean: "log viewer" (the application) appears in three or four different files: menus, dist, anaconda and redhat-logviewer (iirc). All translations should use the same translation of "log viewer" or we'll confuse the user, but four different translators could use four different translations (yes it could be possible!).
Sure it could be possible, but if you don't have a maintainer who makes the effort to really check *all* of these cases, then there's no difference really, is there? And it could also be possible, that all translators translate it the same way, maybe by discussing it, without having to go through a maintainer. Yes, it could be possible!
I don't know if Red Hat has a policy on how the interface to the user should be, and in what way should it address the user, for instance if the policy (if any) encourage to ask the user: "Please, press the button", or to order: "Press the button", or at developer's will (which I think would be inconsistent)... Thinks like this make a difference. Our policy, to give yet another example, tells us to address the user as "you" [polite you] ("ni" in Swedish), and orders from the user to the computer are in imperative form. Now, being consistent with this is key. If there's an application that doesn't follow the same style (or policy) it will disturb the user, and will harm the distro (imo). I'm not saying that ours is the best policy, I'm saying that it has to be consistent, and I know you agree, but the new method doesn't guarantee that (or does it?).
As you've said yourself, you know I agree. :)
I'll apply for maintainer of ca (Catalan), if no one objects. The web page doesn't really tell what the role of a maintainer is, though, I think it should be stated somewhere. So I wait until I know what I'm messing with :) Policy on how to become maintainer and how to depose one should be stated too, probably.
Noted. A maintainer is, as opposed to the translator, a permanent (well, in theory) entity. The maintainer can commit at any time and release the assignment of a translator at any time, hence, keep someone from comitting. A maintainer is a person who is willing to take responsibility for the quality and consistency of a module, a group of modules or for an entire language. And while it is a good thing to have a maintainer, it is not a requirement. I know you think it should be, but that's exactly where we disagree. I believe a translation community can function well, even without having a designated maintainer, and that's what the system really is made for, to better manage the efforts of self-maintained translators.
I just took dist, and it looks kind of unfair to have my name as a Translator, as we're, so far, 4 people working [slowly] on that file, and I am probably the one that has contributed the less. But well, it's something we can live with, I suppose :)
As said, the Translator field is not about getting credit, it's about knowing whom to contact regarding translation issues of a certain module, or finding out that a module is available and one can take the module and translate or fix things herself/himself.
Now, I know I seem to take this a bit religiously, and maybe I do, I just want you to see the light and become a convert, then I shall give you a place in the heaven of translationland :)
That's ok, and if you show me the scriptures in which I shall find the law that for every language such great maintainer is instantly found and either always holds this position, or if required at any time, another such great maintainer as replacement is instantly found, then I will invite you to detail these scriptures for me. :)
Best Regards, Bernd
P.S.: I promised myself it would not be a long mail, but... here it is...
Isn't it always like that! ;)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
On Friday 25 June 2004 04:46, Bernd Groh wrote:
[...]
Then what? Well, then we can talk to this person, and if s/he unwilling to use the "right" terminology, then we can think of disabling her/his account. Btw, I do translate 'Forward' with "Next" if 'Next' is meant, and not with "Forward", consistent or not! IMO, it's just plain wrong! ;) Just kidding. :)
Not sure this is consistent with the rest. How do you define the 'right' terminology if there's no precise framework ? Why should someone be prevented from translation if his translations are correct yet using another terminology ?
[...]
Noted. A maintainer is, as opposed to the translator, a permanent (well, in theory) entity. The maintainer can commit at any time and release the assignment of a translator at any time, hence, keep someone from comitting. A maintainer is a person who is willing to take responsibility for the quality and consistency of a module, a group of modules or for an entire language. And while it is a good thing to have a maintainer, it is not a requirement. I know you think it should be, but that's exactly where we disagree. I believe a translation community can function well, even without having a designated maintainer, and that's what the system really is made for, to better manage the efforts of self-maintained translators.
Yes. A translation community can indeed function very well without having an established team and/or maintainer and this is proven everyday. However, when there are teams in place, they need to be considered.
A question: this new system has been installed after a request from the community, right ? How come many (if not all ?) people on this list are surprised ? ;) I don't remember a post on this list introducing the new system nor someone posting to request it ? Or are you referring to another 'community' ?
Some URLs would help. Sorry if I missed something.
Regards,
- -- Youcef R. Rahal Arabeyes.org http://www.arabeyes.org/~rahal
Youcef,
you're kidding, right?
Then what? Well, then we can talk to this person, and if s/he unwilling to use the "right" terminology, then we can think of disabling her/his account. Btw, I do translate 'Forward' with "Next" if 'Next' is meant, and not with "Forward", consistent or not! IMO, it's just plain wrong! ;) Just kidding. :)
Not sure this is consistent with the rest. How do you define the 'right' terminology if there's no precise framework ? Why should someone be prevented from translation if his translations are correct yet using another terminology ?
Wasn't your voice one of the loudest raising the issue of consistency? Since I believe that the comments made concerning consistency are very valid, I am suggesting solutions on how some of the problems can be handled with the given system. If you don't think someone should be prevented from doing translations that are correct, but inconsistent with everything else, what exactly were you on about previously?
Noted. A maintainer is, as opposed to the translator, a permanent (well, in theory) entity. The maintainer can commit at any time and release the assignment of a translator at any time, hence, keep someone from comitting. A maintainer is a person who is willing to take responsibility for the quality and consistency of a module, a group of modules or for an entire language. And while it is a good thing to have a maintainer, it is not a requirement. I know you think it should be, but that's exactly where we disagree. I believe a translation community can function well, even without having a designated maintainer, and that's what the system really is made for, to better manage the efforts of self-maintained translators.
Yes. A translation community can indeed function very well without having an established team and/or maintainer and this is proven everyday. However, when there are teams in place, they need to be considered.
Yes, and I believe they are. If a coordinator of an active community (as in the group of people having the common interest of wanting to translate Fedora into their language, including "newer" translators) who has the support of most of the members of that language group requests to be a maintainer, this request is not denied.
A question: this new system has been installed after a request from the community, right ? How come many (if not all ?) people on this list are surprised ? ;) I don't remember a post on this list introducing the new system nor someone posting to request it ? Or are you referring to another 'community' ?
Some URLs would help. Sorry if I missed something.
Please, don't you think you're going a little off track here? Is that your idea of constructive criticism, or are you simply on some kind of mission now? Why do you ask me? Why don't you ask the people suggesting to lock files to disallow two translators from comitting at the same time, since that's the main thing that's new. And I still believe their reasoning to be very valid.
Regards, Bernd
Regards,
Youcef R. Rahal Arabeyes.org http://www.arabeyes.org/~rahal -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFA2+S0HDRR6Cd0eSYRAvo8AJ9ji4qtL2OgbPRs6+hgRR8+nMLBAwCfW8Um oS8OP3jCdfz61Eiz+4xafTg= =aFu4 -----END PGP SIGNATURE-----
-- Fedora-trans-list mailing list Fedora-trans-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-trans-list
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Friday 25 June 2004 12:05, Bernd Groh wrote:
Youcef,
you're kidding, right?
Dear Bernd,
A statement like the previous one does conflict with the idea I have of a constructive and professional discussion.
Not sure this is consistent with the rest. How do you define the 'right' terminology if there's no precise framework ? Why should someone be prevented from translation if his translations are correct yet using another terminology ?
Wasn't your voice one of the loudest raising the issue of consistency? Since I believe that the comments made concerning consistency are very valid, I am suggesting solutions on how some of the problems can be handled with the given system. If you don't think someone should be prevented from doing translations that are correct, but inconsistent with everything else, what exactly were you on about previously?
I am still defending consistency and team work. I simply say that refusing access to someone who is doing _correct_ translations but with a different terminology than a group who is working on the same language, is not coherent with _your_ previous statements and the new system. And hence the inconsistence in the system itself.
Yes. A translation community can indeed function very well without having an established team and/or maintainer and this is proven everyday. However, when there are teams in place, they need to be considered.
Yes, and I believe they are. If a coordinator of an active community (as in the group of people having the common interest of wanting to translate Fedora into their language, including "newer" translators) who has the support of most of the members of that language group requests to be a maintainer, this request is not denied.
What if the members of that language are simply not subscribed to this list ? ;) I sent an email to i18n@redhat.com 2 days ago and didn't get any answer about my application to be a maintainer.
A question: this new system has been installed after a request from the community, right ? How come many (if not all ?) people on this list are surprised ? ;) I don't remember a post on this list introducing the new system nor someone posting to request it ? Or are you referring to another 'community' ?
Some URLs would help. Sorry if I missed something.
Please, don't you think you're going a little off track here? Is that your idea of constructive criticism, or are you simply on some kind of mission now? Why do you ask me? Why don't you ask the people suggesting to lock files to disallow two translators from comitting at the same time, since that's the main thing that's new. And I still believe their reasoning to be very valid.
Not off track, sorry. This is a _natural_ question. You stated previously that the new system was suggested by the community ? Nobody seemed to question that though many of the posts (if not all) I read note that their authors are rather suprised by the new system.
Again, as this new system simply conflicts with what was already in place, with what other projects do, and with what we (as translators) have been familiar with (until two days ago), I'm simply asking, when, by who, and where this request was made ? What community are you referring to ? As far as I know, people interested by Fedora translation (the community) are subscribed to this list, yet I never read any reference about this subject. Should we be subscribed to some other list ?
It shouldn't take long to answer these questions. A URL should not be hard to paste. If you want me to accept something, please explain it to me first... I'm not asking more than how things really happened. If I missed something than please remind me by pointing me to the right place.
PS: You can add that to _constructive critisism_ of communication among the Fedora community. If you call for critics, but you can't accept them, then, well...
Best regards,
- -- Youcef R. Rahal Arabeyes.org http://www.arabeyes.org/~rahal
Dear Youcef,
Youcef Rabah Rahal schrieb:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Friday 25 June 2004 12:05, Bernd Groh wrote:
Youcef,
you're kidding, right?
Dear Bernd,
A statement like the previous one does conflict with the idea I have of a constructive and professional discussion.
Not sure this is consistent with the rest. How do you define the 'right' terminology if there's no precise framework ? Why should someone be prevented from translation if his translations are correct yet using another terminology ?
Wasn't your voice one of the loudest raising the issue of consistency? Since I believe that the comments made concerning consistency are very valid, I am suggesting solutions on how some of the problems can be handled with the given system. If you don't think someone should be prevented from doing translations that are correct, but inconsistent with everything else, what exactly were you on about previously?
I am still defending consistency and team work. I simply say that refusing access to someone who is doing _correct_ translations but with a different terminology than a group who is working on the same language, is not coherent with _your_ previous statements and the new system. And hence the inconsistence in the system itself.
And you're telling me you're not kidding? I am in favour of consistency and teamwork, I simply favour inconsistent translations over none. I do not refuse someone who is doing _correct_ translations with a different terminology access, neither I ever will be. But if I'd see that maintainers put in a lot of effort to keep translations consistent, and one member would, even after having been reminded, not be willing to adapt to a commonly agreed on terminology, I'd fulfill the maintainers request on suspending, and if required disabling someones access. This is me taking the comments made about consistency issues seriously, nothing more. And while I do not see where I am incoherent, even if I would become incoherent, because I listen to what the community is saying, frankly speaking, I wouldn't even care (on a side note, you're not the sole speaker of the community).
Yes. A translation community can indeed function very well without having an established team and/or maintainer and this is proven everyday. However, when there are teams in place, they need to be considered.
Yes, and I believe they are. If a coordinator of an active community (as in the group of people having the common interest of wanting to translate Fedora into their language, including "newer" translators) who has the support of most of the members of that language group requests to be a maintainer, this request is not denied.
What if the members of that language are simply not subscribed to this list ? ;) I sent an email to i18n@redhat.com 2 days ago and didn't get any answer about my application to be a maintainer.
Well, maybe the people making these decisions haven't decided yet? Btw, I have received more emails from arabic speaking members not supporting you being the maintainer of all modules than I have received emails in support of you. I invite these people to send you an email directly, or state their opinion on list, but even if they chose not to do so, their opinion is heard.
A question: this new system has been installed after a request from the community, right ? How come many (if not all ?) people on this list are surprised ? ;) I don't remember a post on this list introducing the new system nor someone posting to request it ? Or are you referring to another 'community' ?
Some URLs would help. Sorry if I missed something.
Please, don't you think you're going a little off track here? Is that your idea of constructive criticism, or are you simply on some kind of mission now? Why do you ask me? Why don't you ask the people suggesting to lock files to disallow two translators from comitting at the same time, since that's the main thing that's new. And I still believe their reasoning to be very valid.
Not off track, sorry. This is a _natural_ question. You stated previously that the new system was suggested by the community ? Nobody seemed to question that though many of the posts (if not all) I read note that their authors are rather suprised by the new system.
Yes, it surprised me too. But maybe the ones preferring the new system simply didn't have any reason to speak. People tend to voice their opinions more if things aren't the way they want them to be, I am exactly the same.
Again, as this new system simply conflicts with what was already in place, with what other projects do
Why is that again?
, and with what we (as translators) have been familiar with (until two days ago), I'm simply asking, when, by who, and where this request was made ? What community are you referring to ? As far as I know, people interested by Fedora translation (the community) are subscribed to this list, yet I never read any reference about this subject. Should we be subscribed to some other list ?
Well, we have individual language lists too, all of which are part of Fedora. As far as I remember came most requests out of the french and brazilian-portuguese communities, is that right? Anyone?
And really, most emails of critique weren't really criticizing the new system, the new system merely made people aware again that everyone can commit. But that's not really a fault of the new system, or is it now?
It shouldn't take long to answer these questions. A URL should not be hard to paste. If you want me to accept something, please explain it to me first... I'm not asking more than how things really happened. If I missed something than please remind me by pointing me to the right place.
Ok, can somebody please do that? Please? :)
PS: You can add that to _constructive critisism_ of communication among the Fedora community. If you call for critics, but you can't accept them, then, well...
Why, oh why, is your "criticism" the only one I can't accept? In response to other emails, I even said, and I quote: "I simply felt it was the right thing to do. I could have been wrong.".
Regards, Bernd
Best regards,
Youcef R. Rahal Arabeyes.org http://www.arabeyes.org/~rahal -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFA3AHsHDRR6Cd0eSYRAuMoAJ9wwK/CxQfK8dOfm084qS+cxzKLCwCggj9i iJV9iABVHr/St/xS40WNJvk= =/A5A -----END PGP SIGNATURE-----
-- Fedora-trans-list mailing list Fedora-trans-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-trans-list
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Friday 25 June 2004 14:10, Bernd Groh wrote:
I am still defending consistency and team work. I simply say that refusing access to someone who is doing _correct_ translations but with a different terminology than a group who is working on the same language, is not coherent with _your_ previous statements and the new system. And hence the inconsistence in the system itself.
And you're telling me you're not kidding?
Again, no. And again, let's avoid that.
I am in favour of consistency and teamwork, I simply favour inconsistent translations over none. I do not refuse someone who is doing _correct_ translations with a different terminology access, neither I ever will be. But if I'd see that maintainers put in a lot of effort to keep translations consistent, and one member would, even after having been reminded, not be willing to adapt to a commonly agreed on terminology, I'd fulfill the maintainers request on suspending, and if required disabling someones access. This is me taking the comments made about consistency issues seriously, nothing more. And while I do not see where I am incoherent,
The incoherence is in the fact of saying that everyone is free to translate without joining in the teams in place, yet his account may be suspended if he doesnt' abide by the team's rules... Why do the team's views prevail on the individual's ones ? How do you decide which one is better ? So, finally, new comers will be obliged to join the teams, no ?
Again, this is no sarcasm, no irony. These are objective questions, that need clear and non-ambiguous answers if we have to avoid issues in the future.
even if I would become incoherent, because I listen to what the community is saying, frankly speaking, I wouldn't even care (on a side note, you're not the sole speaker of the community).
I'm not the sole speaker, I never stated the contrary. I'm simply stating concerns that many others (on this very list !) have expressed. I don't want to speak on their behalf though.
Well, maybe the people making these decisions haven't decided yet?
I thought you were in charge of such decisions. Who is then ?
Btw, I have received more emails from arabic speaking members not supporting you being the maintainer of all modules than I have received emails in support of you. I invite these people to send you an email directly, or state their opinion on list, but even if they chose not to do so, their opinion is heard.
Bernd, are you really trying to drag me into a if-you're-running-out-of-arguments-then-try-to-discredit-your-interlocutor type of debate ?
Speaking about your other emails, you keep reading 'kidding' when there's none. You keep reading sarcasm when I'm serious. You said I was on a 'mission'. What mission ??!! I'm only concerned about the work of the team I've been coordinating, and any new work that may be done in the future in the current framework, if we are to continue. So please, let's avoid these easy-to-decalare, hard-to-justify statements.
I think I asked some clear questions, which you keep avoiding to answer. Rather than that, you're going off-track. So, even though your emails say the contrary, I certainly hope that's not your intention.
Please, no need to answer me on the above paragraph, let's discuss and focus on the the real issues.
Not off track, sorry. This is a _natural_ question. You stated previously that the new system was suggested by the community ? Nobody seemed to question that though many of the posts (if not all) I read note that their authors are rather suprised by the new system.
Yes, it surprised me too. But maybe the ones preferring the new system simply didn't have any reason to speak. People tend to voice their opinions more if things aren't the way they want them to be, I am exactly the same.
Then, I'll be glad to hear positive opinions.
Again, as this new system simply conflicts with what was already in place, with what other projects do
Why is that again?
That's the central point !
, and with what we (as translators) have been familiar with (until two days ago), I'm simply asking, when, by who, and where this request was made ? What community are you referring to ? As far as I know, people interested by Fedora translation (the community) are subscribed to this list, yet I never read any reference about this subject. Should we be subscribed to some other list ?
Well, we have individual language lists too, all of which are part of Fedora. As far as I remember came most requests out of the french and brazilian-portuguese communities, is that right? Anyone?
And really, most emails of critique weren't really criticizing the new system, the new system merely made people aware again that everyone can commit. But that's not really a fault of the new system, or is it now?
The way you explained it, it's the fault of the new system.
It shouldn't take long to answer these questions. A URL should not be hard to paste. If you want me to accept something, please explain it to me first... I'm not asking more than how things really happened. If I missed something than please remind me by pointing me to the right place.
Ok, can somebody please do that? Please? :)
That's what dragging us off-track the most. If you clearly answer it (it would take you a second), it will close the debate. In another post, Josep said that this system is fine _assuming_ it was suggested by the community. I'm asking to see that suggestion.
For now, I'll I'm reading is people (not all of course) reluctant to adopt it.
PS: You can add that to _constructive critisism_ of communication among the Fedora community. If you call for critics, but you can't accept them, then, well...
Why, oh why, is your "criticism" the only one I can't accept?
I can't answer this question, can I ? And your statement is rather unjustified...
In response to other emails, I even said, and I quote: "I simply felt it was the right thing to do. I could have been wrong.".
Regards,
- -- Youcef R. Rahal Arabeyes.org http://www.arabeyes.org/~rahal
I updated my CVS tree, and realized that the anaconda po file was 100% translated, but the status page stated that it got 16 fuzzy and 13 untranslated.
Expecting that my tree is messed up like last time, I rename my tree and tried to checkout fresh.
This is Cervisia error message:
-------------------------- cd /cvs/redhat/ && cvs -f -d :ext:arclynx@elvis.redhat.com:/usr/local/CVS checkout -P translate
elvis.redhat.com: Connection timed out
cvs [checkout aborted]: end of file from server (consult above messages if any)
[Exited with status 1] --------------------------
Is it really connection timeout or the CVSROOT has changed?
Thank you.
Sarah Wang wrote:
Hello all,
The new translation status page has been installed: http://elvis.redhat.com/cgi-bin/i18n-status
You will notice that there is a new column called "Availability" for each package. It either says "Finished" (if the translation is 100%) or has a "Take" button (if the translation is not 100%). This feature is designed to minimise the commit conflicts and better coordinate the translation activity within the same language group. If you wish to finish the translation of a package, just click "Take" button, fill in your login and password. Then you will be able to finish and commit the translation to cvs. All cvs account holders should have received or soon to receive information about login name and password.
Please feel free to ask if you have any questions and encountered any problems.
Regards, Sarah
-- Fedora-trans-list mailing list Fedora-trans-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-trans-list
Hello.
Please ignore my previous email. My CVS tree really messed up, and Cervisia look like don't want to checkout the module properly.
I checkout the module using command line, then asking Cervisia to check for update. Weird things do happen sometimes :)
Sharuzzaman Ahmat Raslan wrote:
I updated my CVS tree, and realized that the anaconda po file was 100% translated, but the status page stated that it got 16 fuzzy and 13 untranslated.
Expecting that my tree is messed up like last time, I rename my tree and tried to checkout fresh.
This is Cervisia error message:
cd /cvs/redhat/ && cvs -f -d :ext:arclynx@elvis.redhat.com:/usr/local/CVS checkout -P translate
elvis.redhat.com: Connection timed out
cvs [checkout aborted]: end of file from server (consult above messages if any)
[Exited with status 1]
Is it really connection timeout or the CVSROOT has changed?
Thank you.
----- Sharuzzaman Ahmat Raslan
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tuesday 22 June 2004 05:15, Sarah Wang wrote:
[...]
Please feel free to ask if you have any questions and encountered any problems.
Hi,
On the status page for each translated PO file, there's a field 'Translator' which is not clear. I understand that 'Last translator' is grabbed from the PO file (and I checked that the names there are OK regarding Arabic translation).
However, for dist.po I'm not sure how the fields are filled. I simply don't know the person whose name is put under 'Translator' nor that he ever participated in translation ? :-) Since he has a redhat email, i suppose this is some quality control ??!
http://elvis.redhat.com/cgi-bin/i18n-status?page=module&locale=ar&mo...
Please note that this is only for incomplete files. Finished files have the field 'Translator' empty.
Regards,
- -- Youcef R. Rahal Arabeyes.org http://www.arabeyes.org/~rahal
The translator is the person that is currently translating the file, it will be set to a translator. iff somebody [Take]s the module, otherwise it's blank.
Regards, Bernd
Youcef Rabah Rahal schrieb:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tuesday 22 June 2004 05:15, Sarah Wang wrote:
[...]
Please feel free to ask if you have any questions and encountered any problems.
Hi,
On the status page for each translated PO file, there's a field 'Translator' which is not clear. I understand that 'Last translator' is grabbed from the PO file (and I checked that the names there are OK regarding Arabic translation).
However, for dist.po I'm not sure how the fields are filled. I simply don't know the person whose name is put under 'Translator' nor that he ever participated in translation ? :-) Since he has a redhat email, i suppose this is some quality control ??!
http://elvis.redhat.com/cgi-bin/i18n-status?page=module&locale=ar&mo...
Please note that this is only for incomplete files. Finished files have the field 'Translator' empty.
Regards,
Youcef R. Rahal Arabeyes.org http://www.arabeyes.org/~rahal -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFA1+1kHDRR6Cd0eSYRAsOGAKDppea84ttqPYktqQ8ucpiIEKMqfwCdHRdk A59LaC9clFllCmHxMUOACZs= =v5Io -----END PGP SIGNATURE-----
-- Fedora-trans-list mailing list Fedora-trans-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-trans-list
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tuesday 22 June 2004 11:31, Bernd Groh wrote:
The translator is the person that is currently translating the file, it will be set to a translator. iff somebody [Take]s the module, otherwise it's blank.
If so, then it's obviously an error. Can somebody please fix that ??
Regards,
- -- Youcef R. Rahal Arabeyes.org http://www.arabeyes.org/~rahal
It's not an error, it's intentional. The translator field states who is currently translating the module. If the module isn't currently assigned to anyone, then, of course, the translator field is blank. Or did you refer to something else?
Regards, Bernd
Youcef Rabah Rahal schrieb:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tuesday 22 June 2004 11:31, Bernd Groh wrote:
The translator is the person that is currently translating the file, it will be set to a translator. iff somebody [Take]s the module, otherwise it's blank.
If so, then it's obviously an error. Can somebody please fix that ??
Regards,
Youcef R. Rahal Arabeyes.org http://www.arabeyes.org/~rahal -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFA1//9HDRR6Cd0eSYRAiRQAJ9SXv8kd2AojJuVp7XynIOGq5HARgCgkXoy XQk8nlll8tH22MGZWVycjUQ= =YPw5 -----END PGP SIGNATURE-----
-- Fedora-trans-list mailing list Fedora-trans-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-trans-list
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
On Wednesday 23 June 2004 01:43, Bernd Groh wrote:
It's not an error, it's intentional. The translator field states who is currently translating the module. If the module isn't currently assigned to anyone, then, of course, the translator field is blank. Or did you refer to something else?
What surprises me the most is that the person has a Redhat email address :-)
We (Arabeyes) started Arabic translation from scratch a few months ago, I am the coordinator of the translation team and been sync'ing our CVS with Fedora one all this time, and I can guarantee you (publicly :-) that this person has never participated in translation nor is doing any translation currently. A simple grep in the PO headers will confirm.
So again, to me this is an error that needs a fix :-)
Regards,
- -- Youcef R. Rahal Arabeyes.org http://www.arabeyes.org/~rahal
Youcef Rabah Rahal schrieb:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
On Wednesday 23 June 2004 01:43, Bernd Groh wrote:
It's not an error, it's intentional. The translator field states who is currently translating the module. If the module isn't currently assigned to anyone, then, of course, the translator field is blank. Or did you refer to something else?
What surprises me the most is that the person has a Redhat email address :-)
We (Arabeyes) started Arabic translation from scratch a few months ago, I am the coordinator of the translation team and been sync'ing our CVS with Fedora one all this time, and I can guarantee you (publicly :-) that this person has never participated in translation nor is doing any translation currently. A simple grep in the PO headers will confirm.
So again, to me this is an error that needs a fix :-)
Why don't you email Sherif and ask to release the module, as you don't know him? That's not a call I could make.
Regards, Bernd
Regards,
Youcef R. Rahal Arabeyes.org http://www.arabeyes.org/~rahal -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFA2TjMHDRR6Cd0eSYRAv4xAJ4pxw16EZMWETTerVwML+GQLr867ACg9KDt XXkkNWTPQF7MMA2CFePx8sQ= =QF3H -----END PGP SIGNATURE-----
-- Fedora-trans-list mailing list Fedora-trans-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-trans-list
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wednesday 23 June 2004 23:29, Bernd Groh wrote:
Why don't you email Sherif and ask to release the module, as you don't know him?
Indeed, I don't know him.
That's not a call I could make.
Sorry, but I don't understand. We are doing all the the translation work (check the recent commits), a new system is installed, a name appear from nowhere and we are supposed to fix the 'bugs' ? :-)
Is that reasonable ?
I guess the worst thing a volunteer can experience is seeing someone else being credited for his own work.
Regards,
- -- Youcef R. Rahal Arabeyes.org http://www.arabeyes.org/~rahal
Youcef Rabah Rahal schrieb:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wednesday 23 June 2004 23:29, Bernd Groh wrote:
Why don't you email Sherif and ask to release the module, as you don't know him?
Indeed, I don't know him.
And that should be reason for me to disable this persons access? Because you don't know him?
That's not a call I could make.
Sorry, but I don't understand. We are doing all the the translation work (check the recent commits), a new system is installed, a name appear from nowhere and we are supposed to fix the 'bugs' ? :-)
So far, you've only told me you don't know him, you haven't told me that this person is producing bugs you need to fix, and how should I know if you don't tell me? Is that the case? Is that person actually messing up translations and producing 'bugs'? If so, let me know, and I'll have a word with him, and if required disable his access. But I'm not going to do that just because you don't know him.
Is that reasonable ?
IMO, yes.
I guess the worst thing a volunteer can experience is seeing someone else being credited for his own work.
If you are the coordinator, and hold the majority of commits, then you do have the option of becoming a maintainer. If you chose to do so, you are in a position to release the module from the current translator and make it available again. If you want to put yourself into that position, that is fine with me, but *I* am not going to disallow somebody to participate, because somebody else doesn't know him (or her for that matter). Question remains, do you know for a fact that this person is producing 'bugs'?
Best Regards, Bernd
Regards,
Youcef R. Rahal Arabeyes.org http://www.arabeyes.org/~rahal -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFA2gg6HDRR6Cd0eSYRApieAJ4zvFkQZ4k9mSjjI9clLS2xfxTPBACeN7UT XHzqkjdWhas0QeEUN1XpOso= =9G2p -----END PGP SIGNATURE-----
-- Fedora-trans-list mailing list Fedora-trans-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-trans-list
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thursday 24 June 2004 01:45, Bernd Groh wrote:
And that should be reason for me to disable this persons access? Because you don't know him?
What's the point of having a coordinator if he/she has no control over the team ? :) Anyone can come, take over a module and commit. We are already translating many projects: KDE, GNOME, Debian, Mandrake... and we need to keep consistency and do quality control (please visit arabeyes.org for more info). So yes, knowing who is translating what is absolutely needed.
So far, you've only told me you don't know him, you haven't told me that this person is producing bugs you need to fix, and how should I know if you don't tell me? Is that the case? Is that person actually messing up translations and producing 'bugs'? If so, let me know, and I'll have a word with him, and if required disable his access. But I'm not going to do that just because you don't know him.
Sorry, seems like there's a misunderstand here. I didn't say the person is producting bugs, I called 'bug' the fact that I clicked on dist.po and found his name there, without knowing how it arrived there :-) What I said is that he never paticipated nor he is paticipating so why his name should be there ? (please take a look at the PO headers).
If I understand well, i won't be able to commit as long as he is the 'Translator', right ? I'll probably have to commit by the end of this week, as I usually do (sync'ing repositories). So I won't be able to do so then ?
If you are the coordinator, and hold the majority of commits, then you do have the option of becoming a maintainer. If you chose to do so, you are in a position to release the module from the current translator and make it available again. If you want to put yourself into that position, that is fine with me, but *I* am not going to disallow somebody to participate, because somebody else doesn't know him (or her for that matter). Question remains, do you know for a fact that this person is producing 'bugs'?
Yep, I am the coordinator. And I did not do the majority of commits but _all_ of them (there was 7 strings translated when we started, proably some tests). I sent a request to become the maintainer. I hope I'll have an answer soon :-) If that resolves the problem then OK. What about the 'human factor' though ? I mean, everyone (or the majority) on this list know that I'm the coordinator of the Arabic translation. Even if I don't post often on the list, I send updates from time to time (when we started translation, when we did a good deal of work, when we asked for inclusion in FC2...). Everything is in the mailing list archives, in the PO headers, in the CVS logs...
For me, that human factor should facilitate resolving such issues, rather than dealing with an automatic interface. If someone is publicly known to be the coordinator, so why should he/she go through all this process ?
Can anyone please confirm ? :-) Sarah ?
Kind regards,
- -- Youcef R. Rahal Arabeyes.org http://www.arabeyes.org/~rahal
Hi Youcef,
I can indeed confirm that you have been involved in the Arabic translation thing, but what you are missing here is that the Fedora translation project has no coordinator, no maintainer. Ok? You can't just jump up and say "I am the coordinator." If someone's making troubles for you as a contributor, then Red Hat people would love to help you resolve the problem, but before that, you are simply not different from any other possible contributor which may show up at any time. So please understand, unlike many other project, this one's not about human factor, credits, blah blah. PO headers are not about that either, because they just document the *last* translator. It's not about credit. You did all the translation, thank you; you're welcome. That's all.
behdad (who has not done any translation on Fedora [yet])
On Wed, 23 Jun 2004, Youcef Rabah Rahal wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thursday 24 June 2004 01:45, Bernd Groh wrote:
And that should be reason for me to disable this persons access? Because you don't know him?
What's the point of having a coordinator if he/she has no control over the team ? :) Anyone can come, take over a module and commit. We are already translating many projects: KDE, GNOME, Debian, Mandrake... and we need to keep consistency and do quality control (please visit arabeyes.org for more info). So yes, knowing who is translating what is absolutely needed.
So far, you've only told me you don't know him, you haven't told me that this person is producing bugs you need to fix, and how should I know if you don't tell me? Is that the case? Is that person actually messing up translations and producing 'bugs'? If so, let me know, and I'll have a word with him, and if required disable his access. But I'm not going to do that just because you don't know him.
Sorry, seems like there's a misunderstand here. I didn't say the person is producting bugs, I called 'bug' the fact that I clicked on dist.po and found his name there, without knowing how it arrived there :-) What I said is that he never paticipated nor he is paticipating so why his name should be there ? (please take a look at the PO headers).
If I understand well, i won't be able to commit as long as he is the 'Translator', right ? I'll probably have to commit by the end of this week, as I usually do (sync'ing repositories). So I won't be able to do so then ?
If you are the coordinator, and hold the majority of commits, then you do have the option of becoming a maintainer. If you chose to do so, you are in a position to release the module from the current translator and make it available again. If you want to put yourself into that position, that is fine with me, but *I* am not going to disallow somebody to participate, because somebody else doesn't know him (or her for that matter). Question remains, do you know for a fact that this person is producing 'bugs'?
Yep, I am the coordinator. And I did not do the majority of commits but _all_ of them (there was 7 strings translated when we started, proably some tests). I sent a request to become the maintainer. I hope I'll have an answer soon :-) If that resolves the problem then OK. What about the 'human factor' though ? I mean, everyone (or the majority) on this list know that I'm the coordinator of the Arabic translation. Even if I don't post often on the list, I send updates from time to time (when we started translation, when we did a good deal of work, when we asked for inclusion in FC2...). Everything is in the mailing list archives, in the PO headers, in the CVS logs...
For me, that human factor should facilitate resolving such issues, rather than dealing with an automatic interface. If someone is publicly known to be the coordinator, so why should he/she go through all this process ?
Can anyone please confirm ? :-) Sarah ?
Kind regards,
Youcef R. Rahal Arabeyes.org http://www.arabeyes.org/~rahal -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFA2ib4HDRR6Cd0eSYRAiWhAJ9403BhqJ17qB89iuJ4b2jHO9bXDACgpqDE BQFdkpMMQ75OfRueau8dHMU= =nElG -----END PGP SIGNATURE-----
-- Fedora-trans-list mailing list Fedora-trans-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-trans-list
--behdad behdad.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thursday 24 June 2004 05:26, Behdad Esfahbod wrote:
Hi Youcef,
I can indeed confirm that you have been involved in the Arabic translation thing,
Ah, finally, someone ;) The thing is that we are *still* involved in it ;) Last sunday (or Saturday) I did some commits.
Thank you for confirming :-)
but what you are missing here is that the Fedora translation project has no coordinator, no maintainer. Ok? You can't just jump up and say "I am the coordinator."
Actually it has, and you can apply to it via the web interface...
If someone's making troubles for you as a contributor, then Red Hat people would love to help you resolve the problem, but before that, you are simply not different from any other possible contributor which may show up at any time.
Not sure. You mean there's no difference between someone who jumps in and put his name there because a new system has just been installed and the field was blank and between a team who did 90% of the translation in the last weeks and which is *still* translating ? ;)
So please understand, unlike many other project, this one's not about human factor, credits, blah blah. PO headers are not about that either, because they just document the *last* translator.
No, the PO headers list *all* the translators, not only the last one. So everyone get their credits.
About the 'human factor': when a new system is installed, it should consider what was already in place in terms of who was doing what. If someone comes by chance and fills a blank field because the system is very recent (and the community is not even aware of such a change yet), then the responsible should say, 'OK sorry, but there's already a team translating, why not contact them first ?'.
It's not about credit. You did all the translation, thank you; you're welcome. That's all.
I'm not asking more than that. But if you do all of the translation and someone says thank you to someone else than you, then there's a problem ;)
behdad (who has not done any translation on Fedora [yet])
:-)
Regards,
- -- Youcef R. Rahal Arabeyes.org http://www.arabeyes.org/~rahal
Youcef,
I can indeed confirm that you have been involved in the Arabic translation thing,
Ah, finally, someone ;) The thing is that we are *still* involved in it ;) Last sunday (or Saturday) I did some commits.
Thank you for confirming :-)
Why the sarcasm, nobody ever said you weren't involved, not even I. I simply said, and I believe so did Behdad, that it doesn't give you the right to decide who is allowed to translate into Arabic and who isn't. And that you've done *all* (somebody please back that up) the commits, doesn't change that.
but what you are missing here is that the Fedora translation project has no coordinator, no maintainer. Ok? You can't just jump up and say "I am the coordinator."
Actually it has, and you can apply to it via the web interface...
No, it hasn't. At least not in the way you were proclaiming and Behdad was referring to. The new system has the option of assigning a maintainer to a certain module, not to an entire language. To assign a maintainer to all modules of a language will only be done if somebody is willing to be the maintainer of an entire language, and nobody of that language objects to it.
If someone's making troubles for you as a contributor, then Red Hat people would love to help you resolve the problem, but before that, you are simply not different from any other possible contributor which may show up at any time.
Not sure. You mean there's no difference between someone who jumps in and put his name there because a new system has just been installed and the field was blank and between a team who did 90% of the translation in the last weeks and which is *still* translating ? ;)
Do you misunderstand Behdad on purpose now? Please, Youcef, please tell me, how do you know that Sherif simply put in his name, because a new system has just been installed and the field was blank? I'd think he took the module, because he is translating it. Did that ever occur to you? Or do you believe that because you did the majority of translations, that you, and not he, should have the right to translate the module?
So please understand, unlike many other project, this one's not about human factor, credits, blah blah. PO headers are not about that either, because they just document the *last* translator.
No, the PO headers list *all* the translators, not only the last one. So everyone get their credits.
What exactly is more important to you, that the translations get done, or that you get some credit? And no, the po header does only list the last translator. Some programs keep previous translators in comments, others do not.
About the 'human factor': when a new system is installed, it should consider what was already in place in terms of who was doing what. If someone comes by chance and fills a blank field because the system is very recent (and the community is not even aware of such a change yet), then the responsible should say, 'OK sorry, but there's already a team translating, why not contact them first ?'.
You seem to talk about someone, as opposed to the community? Does that mean you do not consider this someone part of the community? What for you is the community?
It's not about credit. You did all the translation, thank you; you're welcome. That's all.
I'm not asking more than that. But if you do all of the translation and someone says thank you to someone else than you, then there's a problem ;)
Then there shouldn't be a problem, right? Again, thank you. :)
Regards, Bernd
behdad (who has not done any translation on Fedora [yet])
:-)
Regards,
Youcef R. Rahal Arabeyes.org http://www.arabeyes.org/~rahal -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFA2pmFHDRR6Cd0eSYRAiGXAKDQu6nbGj36nyPHgzuT1UPoGbhgpACePltI FNlhteL+sQji1qp/Zdjeg8Q= =9L+H -----END PGP SIGNATURE-----
-- Fedora-trans-list mailing list Fedora-trans-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-trans-list
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thursday 24 June 2004 12:09, Bernd Groh wrote:
Why the sarcasm, nobody ever said you weren't involved, not even I. I simply said, and I believe so did Behdad, that it doesn't give you the right to decide who is allowed to translate into Arabic and who isn't. And that you've done *all* (somebody please back that up) the commits, doesn't change that.
I'm concerned about consistency, task-sharing, avoiding conflicts and QA.
No, it hasn't. At least not in the way you were proclaiming and Behdad was referring to. The new system has the option of assigning a maintainer to a certain module, not to an entire language. To assign a maintainer to all modules of a language will only be done if somebody is willing to be the maintainer of an entire language, and nobody of that language objects to it.
OK. I apply to be the maintainer of the entire language. How will you know that no one objects to it if they don't susbcribe to the lists ? (seriously, no irony).
Do you misunderstand Behdad on purpose now? Please, Youcef, please tell me, how do you know that Sherif simply put in his name, because a new system has just been installed and the field was blank? I'd think he took the module, because he is translating it. Did that ever occur to you? Or do you believe that because you did the majority of translations, that you, and not he, should have the right to translate the module?
Again, I have NOTHING against him in particular. As stated above, I'm concerned bu consisteny, QA... Like I said in another email, I'll contact him, no problem. It's just that I wasn't expecting such traffic from a 'simple' request :)
What exactly is more important to you, that the translations get done, or that you get some credit?
QA, consistency, no conflicts...
And no, the po header does only list the last translator. Some programs keep previous translators in comments, others do not.
In our team we are keen to keep all the names there (check the translated POs). And I _personally_ check that constantly. There are even the names of people who translated the 7 strings before we started working on it. So everyone is there.
About the 'human factor': when a new system is installed, it should consider what was already in place in terms of who was doing what. If someone comes by chance and fills a blank field because the system is very recent (and the community is not even aware of such a change yet), then the responsible should say, 'OK sorry, but there's already a team translating, why not contact them first ?'.
You seem to talk about someone, as opposed to the community? Does that mean you do not consider this someone part of the community? What for you is the community?
Community: people who are already working on something. Someone: a new comer (which will be integrated to the community).
Then there shouldn't be a problem, right? Again, thank you. :)
:)
Regards,
- -- Youcef R. Rahal Arabeyes.org http://www.arabeyes.org/~rahal
Youcef Rabah Rahal schrieb:
[snip] Again, I have NOTHING against him in particular. As stated above, I'm concerned bu consisteny, QA... Like I said in another email, I'll contact him, no problem. It's just that I wasn't expecting such traffic from a 'simple' request :)
I simply wanted to make sure you understood why I am not going to fullfill this request, and it is important to me that you do understand. :)
Best Regards, Bernd
What exactly is more important to you, that the translations get done, or that you get some credit?
QA, consistency, no conflicts...
And no, the po header does only list the last translator. Some programs keep previous translators in comments, others do not.
In our team we are keen to keep all the names there (check the translated POs). And I _personally_ check that constantly. There are even the names of people who translated the 7 strings before we started working on it. So everyone is there.
About the 'human factor': when a new system is installed, it should consider what was already in place in terms of who was doing what. If someone comes by chance and fills a blank field because the system is very recent (and the community is not even aware of such a change yet), then the responsible should say, 'OK sorry, but there's already a team translating, why not contact them first ?'.
You seem to talk about someone, as opposed to the community? Does that mean you do not consider this someone part of the community? What for you is the community?
Community: people who are already working on something. Someone: a new comer (which will be integrated to the community).
Then there shouldn't be a problem, right? Again, thank you. :)
:)
Regards,
Youcef R. Rahal Arabeyes.org http://www.arabeyes.org/~rahal -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFA2q1sHDRR6Cd0eSYRAoHJAJ0XsBE03UCT7SChHBE/rofL5C8M6ACgyfMg UjR2XBcBsw4rkRoX+ys65K4= =dufD -----END PGP SIGNATURE-----
-- Fedora-trans-list mailing list Fedora-trans-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-trans-list
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thursday 24 June 2004 12:40, Bernd Groh wrote:
Youcef Rabah Rahal schrieb:
Again, I have NOTHING against him in particular. As stated above, I'm concerned bu consisteny, QA... Like I said in another email, I'll contact him, no problem. It's just that I wasn't expecting such traffic from a 'simple' request :)
I simply wanted to make sure you understood why I am not going to fullfill this request, and it is important to me that you do understand. :)
Fair enough. Though I don't fully agree with you, I understand your position :-)
Kind regards,
- -- Youcef R. Rahal Arabeyes.org http://www.arabeyes.org/~rahal
Youcef Rabah Rahal schrieb:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thursday 24 June 2004 01:45, Bernd Groh wrote:
And that should be reason for me to disable this persons access? Because you don't know him?
What's the point of having a coordinator if he/she has no control over the team ? :)
Being a coordinator isn't about having control, or is it now? ;)
Anyone can come, take over a module and commit. We are already translating many projects: KDE, GNOME, Debian, Mandrake... and we need to keep consistency and do quality control (please visit arabeyes.org for more info). So yes, knowing who is translating what is absolutely needed.
Completely agree.
So far, you've only told me you don't know him, you haven't told me that this person is producing bugs you need to fix, and how should I know if you don't tell me? Is that the case? Is that person actually messing up translations and producing 'bugs'? If so, let me know, and I'll have a word with him, and if required disable his access. But I'm not going to do that just because you don't know him.
Sorry, seems like there's a misunderstand here. I didn't say the person is producting bugs, I called 'bug' the fact that I clicked on dist.po and found his name there, without knowing how it arrived there :-)
Well, it arrived there, because this person clicked on [Take], and no, it is not a bug. :)
What I said is that he never paticipated nor he is paticipating so why his name should be there ? (please take a look at the PO headers).
Given that he has taken a module, I'd say he *is* participating. And as Behdad said, PO-Headers aren't all conclusive, but even if that person had never done any translations before, why say he can't? What is wrong with somebody wanting to participate?
If I understand well, i won't be able to commit as long as he is the 'Translator', right ? I'll probably have to commit by the end of this week, as I usually do (sync'ing repositories). So I won't be able to do so then ?
You won't be able to commit dist (or specspo), but you can commit everything else. Have you already translated dist? If so, let Sherif know, and ask him to release the module, I'm sure he'd be helpful. If you chose not to do so, I am not going to help you. I am not going to kick him off, just because you don't know him, as I've stated previously.
If you are the coordinator, and hold the majority of commits, then you do have the option of becoming a maintainer. If you chose to do so, you are in a position to release the module from the current translator and make it available again. If you want to put yourself into that position, that is fine with me, but *I* am not going to disallow somebody to participate, because somebody else doesn't know him (or her for that matter). Question remains, do you know for a fact that this person is producing 'bugs'?
Yep, I am the coordinator. And I did not do the majority of commits but _all_ of them (there was 7 strings translated when we started, proably some tests).
You did all of the commits, but I assume not all of the translations, or? So why do you believe you have the right to say that Sherif cannot do any Arabic translations? Why don't you, even after I told you you should, send him an email, but instead tell me that him translating the module is a 'bug' and I should fix it? It is not a bug, he's an Arabic translator, just like you. He might not have known there is a very active Arabic group, he might not even be subscribed to this mailing list, so, why not email him and ask him to participate in your group? IMO, that's what a coordinator should do. On a side note, do you believe the other arabic translators get enough credit?
I sent a request to become the maintainer. I hope I'll have an answer soon :-) If that resolves the problem then OK. What about the 'human factor' though ? I mean, everyone (or the majority) on this list know that I'm the coordinator of the Arabic translation. Even if I don't post often on the list, I send updates from time to time (when we started translation, when we did a good deal of work, when we asked for inclusion in FC2...). Everything is in the mailing list archives, in the PO headers, in the CVS logs...
So? Does that mean you decide on who is allowed to contribute to the Arabic translations and who isn't?
For me, that human factor should facilitate resolving such issues, rather than dealing with an automatic interface. If someone is publicly known to be the coordinator, so why should he/she go through all this process ?
I didn't know you were the Arabic coordinator, neither it seems like Sherif or Behdad knew, who happen to speak Arabic. And if Behdad would chose to take a module and participate, I believe that he should be able to. Or would you disagree?
Can anyone please confirm ? :-) Sarah ?
We can confirm that you have been very involved in the project, and we may chose to make you the maintainer for Arabic. But if we'd to hear that you won't let other Arabic translators participate, because you don't know them, we may chose other people as maintainers. Coordination is not about excercising control of who is doing what and how, it is about coordinating the efforts of everyone who is willing to participate. If you're not even willing to send Sherif an email, but ask me to 'remove' him, really, I don't know whether that's what is meant by being a coordinator.
On a last note, if you'd want to argue that I excercise some level of control, it's true, and I use it to make sure as best as I can that everyone who wants to participate can.
Best Regards, Bernd
Kind regards,
Youcef R. Rahal Arabeyes.org http://www.arabeyes.org/~rahal -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFA2ib4HDRR6Cd0eSYRAiWhAJ9403BhqJ17qB89iuJ4b2jHO9bXDACgpqDE BQFdkpMMQ75OfRueau8dHMU= =nElG -----END PGP SIGNATURE-----
-- Fedora-trans-list mailing list Fedora-trans-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-trans-list
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thursday 24 June 2004 06:21, Bernd Groh wrote:
Being a coordinator isn't about having control, or is it now? ;)
It depends how you define 'control' :-). I define it as keeping consistency, avoiding conflicts, sharing the tasks.
Well, it arrived there, because this person clicked on [Take], and no, it is not a bug. :)
Yeah, I suppose so. In the very short (?) moment between the system was installed and the email was sent to the list. If you consider the human factor though, it seems like it's a bug. In other words, a team is already translating the same file -> conflict/bug.
Given that he has taken a module, I'd say he *is* participating. And as Behdad said, PO-Headers aren't all conclusive, but even if that person had never done any translations before, why say he can't? What is wrong with somebody wanting to participate?
Nothing wrong about that at all. If there are many 'inorganized' (not meant to be pejorative :-) people working on a language then it's OK. However, if there's a team already in place (with mailing lists, with CVS, etc on their own) , new comers should join it, for the reasons I said above: consistency, task-sharing...).
Actually, many (if not all) projects consider this 'human factor' :-) The ones we're contributing to at least. So Fedora now is becoming an exception to the rule, but I have yet to understand the reasons ;)
You won't be able to commit dist (or specspo), but you can commit everything else. Have you already translated dist? If so, let Sherif know, and ask him to release the module, I'm sure he'd be helpful. If you chose not to do so, I am not going to help you. I am not going to kick him off, just because you don't know him, as I've stated previously.
I'm not interested in committing other files, since.... we *finished* them. The only file which has untranslated/fuzzy strings is now dist.po and I'm not able to update it :-)
I'll contact him, no problem. But not considering the 'human factor' sounds to me dangerous as it will tend to alienate constant contributors simply because someone came and filled a blank field.
Again, I don't know Sherif, he's probably a very nice and dedicated person (well, in short, I don't know him ;). My issue is not with him personally. Again, it's about considering the 'human factor' (sorry, I don't know how many times I said this word in this email ;)
You did all of the commits, but I assume not all of the translations, or?
Never said the contrary. I did the commits on behalf of a team, and their names are in the headers. I did only a small percentage :-)
When I say 'I', you can substitute it by 'we' or 'the team'...
So why do you believe you have the right to say that Sherif cannot do any Arabic translations?
Never said that. I'm saying that newcomers should be directed to a team in case there's one already in place. Very different. Why ? For the reasons I stated above.
Why don't you, even after I told you you should, send him an email, but instead tell me that him translating the module is a 'bug' and I should fix it?
As I said above, I'll do.
It is not a bug, he's an Arabic translator, just like you. He might not have known there is a very active Arabic group, he might not even be subscribed to this mailing list, so, why not email him and ask him to participate in your group?
Noted.
IMO, that's what a coordinator should do.
On a side note, responsibles of the Fedora l10n/i18n should also be aware of the teams involved in translation IMHO.
On a side note, do you believe the other arabic translators get enough credit?
Yes. At least, their names are in the PO headers, and as far as I can tell no one asked more than that. Again, when you read 'I' please understand 'the team' :-) Sorry if I gave the impression that I was trying to credit myself individually. I'm the coordinator of the translation and I'm concerned by the fact that every contributor gets credited for their hard work.
So? Does that mean you decide on who is allowed to contribute to the Arabic translations and who isn't?
I don't remember a single time when we said to someone don't translate. On the contrary, we're in dire need for translators ;) And the Fedora page on Arabeyes states it clearly in bold characters:
http://www.arabeyes.org/project.php?proj=Fedora
What I think though, is that if there's a team in place, there's a need to place new comers in harmony among the team, for the reasons stated above.
I didn't know you were the Arabic coordinator, neither it seems like Sherif or Behdad knew, who happen to speak Arabic. And if Behdad would chose to take a module and participate, I believe that he should be able to. Or would you disagree?
Well now you know ;) As for Sherif, how could he know if he came on the status page by accident when you had just implemented the new system ? Of course he couldn't know. But now we're back to the human factor. ie, *you* know that I'm the coordinator. As for Behdad, I guess he's more interested by Persian ;) Of course, he is more then welcome if he wants to participate in the Arabic translation :))
We can confirm that you have been very involved in the project, and we may chose to make you the maintainer for Arabic.
Thank you.
But if we'd to hear that you won't let other Arabic translators participate, because you don't know them, we may chose other people as maintainers.
Did I ever said that ? :-) Again, We're in need of translators. Yet we have to respect consistency. It's about the framework, not about the persons.
Coordination is not about excercising control of who is doing what and how, it is about coordinating the efforts of everyone who is willing to participate.
Agreed (yet the coordinator is also responsible for QA and such).
If you're not even willing to send Sherif an email, but ask me to 'remove' him, really, I don't know whether that's what is meant by being a coordinator.
Again, will do. But considering the 'human factor', when I sent my first email to this list concerning this topic, I was far from thinking that it would generate all this traffic. I thought it was a 1-sec fix. Obviously, I was wrong.
On a last note, if you'd want to argue that I excercise some level of control, it's true, and I use it to make sure as best as I can that everyone who wants to participate can.
Agreed. I just would like to stress one last time on the ... 'human factor', 'human factor', 'human factor', 'human factor', ;-)) You have to exercice some control. Right. But you have to be aware of the translation teams in place too.
Regards,
- -- Youcef R. Rahal Arabeyes.org http://www.arabeyes.org/~rahal
Youcef,
I'll make this one short.
So why do you believe you have the right to say that Sherif cannot do any Arabic translations?
Never said that. I'm saying that newcomers should be directed to a team in case there's one already in place. Very different. Why ? For the reasons I stated above.
Well, why then did you ask me to fix the bug of Sherif being there? You've basically asked me to remove him and put you instead. I'd say that it pretty much says that you believe you've got more right to translate the module than him, and he shouldn't really translate it without your permission. Or where did I misunderstand you here?
Why don't you, even after I told you you should, send him an email, but instead tell me that him translating the module is a 'bug' and I should fix it?
As I said above, I'll do.
Thank you, I'm sure all will be resolved now. :)
Again, will do. But considering the 'human factor', when I sent my first email to this list concerning this topic, I was far from thinking that it would generate all this traffic. I thought it was a 1-sec fix. Obviously, I was wrong.
You see, again, a 1-sec fix? And then you say you've never said he can't translate it. He does, and he has the right to commit. Maybe you should have emailed him straight away, rather than ask on list to remove him? I'd never, since it is not my place to decide on who of a certain language has what right. I'm happy to give someone certain additional rights under certain conditions, but I'm not going to take away anyone rights without a good reason, such as that a person is producing bad translations.
On a last note, if you'd want to argue that I excercise some level of control, it's true, and I use it to make sure as best as I can that everyone who wants to participate can.
Agreed. I just would like to stress one last time on the ... 'human factor', 'human factor', 'human factor', 'human factor', ;-)) You have to exercice some control. Right. But you have to be aware of the translation teams in place too.
I'd encourage everyone to join a translation team, but you have to understand that just because someone doesn't belong to a certain group, I am not going to revoke his rights to translate a module.
Best Regards, Bernd
Regards,
Youcef R. Rahal Arabeyes.org http://www.arabeyes.org/~rahal -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFA2qc7HDRR6Cd0eSYRAkhiAJ4n1nLiTxnBsADhC15Nalxbb9OphwCfSvYb FapZu7Ts37F/V9vQDr81XmA= =k42a -----END PGP SIGNATURE-----
-- Fedora-trans-list mailing list Fedora-trans-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-trans-list
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thursday 24 June 2004 12:32, Bernd Groh wrote:
Well, why then did you ask me to fix the bug of Sherif being there? You've basically asked me to remove him and put you instead. I'd say that it pretty much says that you believe you've got more right to translate the module than him, and he shouldn't really translate it without your permission. Or where did I misunderstand you here?
No, not about the rights, but about the framework.
As I said above, I'll do.
Thank you, I'm sure all will be resolved now. :)
I hope so :-)
You see, again, a 1-sec fix? And then you say you've never said he can't translate it. He does, and he has the right to commit. Maybe you should have emailed him straight away, rather than ask on list to remove him?
Yes, it was a mistake.
I'd never, since it is not my place to decide on who of a certain language has what right. I'm happy to give someone certain additional rights under certain conditions, but I'm not going to take away anyone rights without a good reason, such as that a person is producing bad translations.
Noted.
I'd encourage everyone to join a translation team, but you have to understand that just because someone doesn't belong to a certain group, I am not going to revoke his rights to translate a module.
Not revoke their rights, but before giving them rights, direct them first to the language team if any. If there's a problem, like the team not wanting to integrate the person for no valid reason, then you should give them access. I think you really should consider this. It does not seem to be specific to Arabic and other people have expressed concerns about this system too.
Regards,
- -- Youcef R. Rahal Arabeyes.org http://www.arabeyes.org/~rahal
Wow .. where did I miss all of that ! Where all that came from? I did not know that there was someone active is translating that module into arabic. Simply I wanted to contribute. I just wanted to get it done.
Youcef, you could have simply sent me email and I would released that for you. I am not sure that what you are doing here is right. Claiming control and asking for kicking anyone else out isn't acceptable.
Regardless of the my concerns on the translation already made, I want to make this clear as Bernd cleared it. No one has the right for more traslantion than others or demand to have the trasnaltion done his way. I do have concerns about the current translation, but I always belived something is better than nothing. My attempt to help as I am arabic speaking person is my right.
With all my respect to you, I am surprised to the approach. Simple email reaquesting relase would have done it.
I am not sure what QA and keeping things organized on any other site? I thought the system already in place is the one the community should share and use to reach what they want. So I am sorry your claims I can not understand. So you have no problem for me to translate but I have to join you guys @ arabeyes otherwise I should keep my hands off because it is yours? I just can not understand it.
I will release this module and you are more than welcome to finish it.
As for your request to maintain all the arabic translation, and as rules stated by Bernd, I myself object for someone to control all the translation.
Thanks
Sherif
Youcef,
I have just released the module for you. Enjoy translation.
Thanks
Sherif
On Thu, 24 Jun 2004, Sherif Abdelgawad wrote:
Wow .. where did I miss all of that ! Where all that came from? I did not know that there was someone active is translating that module into arabic. Simply I wanted to contribute. I just wanted to get it done.
Youcef, you could have simply sent me email and I would released that for you. I am not sure that what you are doing here is right. Claiming control and asking for kicking anyone else out isn't acceptable.
Regardless of the my concerns on the translation already made, I want to make this clear as Bernd cleared it. No one has the right for more traslantion than others or demand to have the trasnaltion done his way. I do have concerns about the current translation, but I always belived something is better than nothing. My attempt to help as I am arabic speaking person is my right.
With all my respect to you, I am surprised to the approach. Simple email reaquesting relase would have done it.
I am not sure what QA and keeping things organized on any other site? I thought the system already in place is the one the community should share and use to reach what they want. So I am sorry your claims I can not understand. So you have no problem for me to translate but I have to join you guys @ arabeyes otherwise I should keep my hands off because it is yours? I just can not understand it.
I will release this module and you are more than welcome to finish it.
As for your request to maintain all the arabic translation, and as rules stated by Bernd, I myself object for someone to control all the translation.
Thanks
Sherif
-- Fedora-trans-list mailing list Fedora-trans-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-trans-list
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thursday 24 June 2004 15:39, Sherif Abdelgawad wrote:
Youcef,
I have just released the module for you. Enjoy translation.
Thanks
Sherif
Thank you.
My invitation is still valid to join us (and of course you can also start translating 'alone' if you'd like)
Regards,
- -- Youcef R. Rahal Arabeyes.org http://www.arabeyes.org/~rahal
Στις 24/Ιούν/2004, ημέρα Πέμπτη και ώρα 16:26, ο/η Sherif Abdelgawad έγραψε:
Regardless of the my concerns on the translation already made, I want to make this clear as Bernd cleared it. No one has the right for more traslantion than others or demand to have the trasnaltion done his way.
Correct me if i am wrong: ok its the same thing for kernel developement for example, everyone has the right to code but i think that he can't take control via web buttons or commit code unless this code is reviewed by someone responsible for that.
Start translating is an easy thing and anyone can do it but as you get deeper in this process you realize that many issues arrive. The random guy can do damage and put some extra work to those people that initialy spent their time and continue to care for quality translations.
So i believe that the random guy have to prove he is qualified to do the job. The gnome model is certainly better for me.
Nikos Charonitakis
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Correct me if i am wrong: ok its the same thing for kernel developement for example, everyone has the right to code but i think that he can't take control via web buttons or commit code unless this code is reviewed by someone responsible for that.
I did not say that we should not let someone to finish/maintain work. I agree with you that someone should maintain things.
I think, that the current system is OK and I belive the translation team are doing their best to get everything done right. As for the case I was commenting on, I was just making it clear that the page was not saying there is a maintainer who maintain this module, so I wanted to contribute and help.
I am not sure about the other languages, but for Arabic which what I was commenting on, there is quite delicats. Which I think if only one person is doing the translation, it would look odd to others. Unless a full team of ppl agree and accept one standard, that where my concerns are coming from.
I assume that anyone can object, discuss or ask the maintainer to change something which will happen my time.
Thanks
Sherif
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thursday 24 June 2004 16:45, Sherif Abdelgawad wrote:
I did not say that we should not let someone to finish/maintain work. I agree with you that someone should maintain things.
I think, that the current system is OK and I belive the translation team are doing their best to get everything done right. As for the case I was commenting on, I was just making it clear that the page was not saying there is a maintainer who maintain this module, so I wanted to contribute and help.
You couldn't know. Now, that you know, you can either contribute by joining the team or not joining it.
I am not sure about the other languages, but for Arabic which what I was commenting on, there is quite delicats. Which I think if only one person is doing the translation, it would look odd to others. Unless a full team of ppl agree and accept one standard, that where my concerns are coming from.
Hmm. Not sure I understand ? I'm not translating alone. I'm just the coordinator. About the standard, it is being discussed in deep at Arabeyes, and involving all the Arabic translators working on GNOME, KDE, Mandrake, Debian...
I assume that anyone can object, discuss or ask the maintainer to change something which will happen my time.
Yup. Did anyone say the contrary ? ;-) You can see the records of long discussions on quality of translation on the archives of doc @ arabeyes dot org: vocabulary, grammar, sources, etc etc (and to which you can subscribe and post).
Regards,
- -- Youcef R. Rahal Arabeyes.org http://www.arabeyes.org/~rahal
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Youcef, Glade that you know that there was no intention or other reasons than just helping from my side.
Good luck in translation .. will sure contribute when need, it is almost done the arabic translation :-)
I will use this mailing list to discuss or comment on any arabic translation. It is good at least to have base we can move forward from.
Take care , and thanks.
Sherif
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thursday 24 June 2004 18:03, Sherif Abdelgawad wrote:
Youcef,
Glade that you know that there was no intentionor other reasons than just helping from my side.
I was simply surprised. I'm sorry if my posts let you think that I thought something else.
Good luck in translation .. will sure contribute when need, it is almost done the arabic translation :-)
I will use this mailing list to discuss or comment on any arabic translation. It is good at least to have base we can move forward from.
I'm looking forward to read your comments/critics/bug_reports and/or see you contributing ;)
Take care , and thanks.
Sherif
Regards,
- -- Youcef R. Rahal Arabeyes.org http://www.arabeyes.org/~rahal
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thursday 24 June 2004 15:26, Sherif Abdelgawad wrote:
Wow .. where did I miss all of that ! Where all that came from? I did not know that there was someone active is translating that module into arabic. Simply I wanted to contribute. I just wanted to get it done.
You're right. Since there no mean on the status page to know there's a team working on the module, you couldn't know.
Youcef, you could have simply sent me email and I would released that for you. I am not sure that what you are doing here is right. Claiming control and asking for kicking anyone else out isn't acceptable.
I'll refer to my previous posts on the subject (about control etc).
Regardless of the my concerns on the translation already made, I want to make this clear as Bernd cleared it. No one has the right for more traslantion than others or demand to have the trasnaltion done his way. I do have concerns about the current translation, but I always belived something is better than nothing. My attempt to help as I am arabic speaking person is my right.
Of course it's you right. However, since there's already a team in place (OK, that you weren't aware of), joining it, contributing and sharing your concerns is the best way to do IMHO. Please, if you have concerns about the current translation, we'll be more than happy to hear them.
With all my respect to you, I am surprised to the approach. Simple email reaquesting relase would have done it.
That started by an answer to the annoucement, and generated a traffic I wasn't expecting. So, yes, it was a mistake from my side. However, you should not take that personally. I would have reacted the same if it was another name.
I am not sure what QA and keeping things organized on any other site? I thought the system already in place is the one the community should share and use to reach what they want. So I am sorry your claims I can not understand. So you have no problem for me to translate but I have to join you guys @ arabeyes otherwise I should keep my hands off because it is yours? I just can not understand it.
You are free to translate without joining us (see Bernd's emails on the subject). However, we'll be more than glad to have you in the team and hear your thoughts and concerns.
I will release this module and you are more than welcome to finish it.
Thanks.
As for your request to maintain all the arabic translation, and as rules stated by Bernd, I myself object for someone to control all the translation.
Well, I have been implied in translation for some time now, and I coordinate Fedora and Mandrake translations, and experience shows that working in organized teams is the best way to do it, and that's how other projects organize their translations. In Fedora though, per the new system, you're 'free' to translate alone ;)
Again sorry if you've been offended, nothing personal. I would have reacted the same in case there's was another name in the 'Translator' field, even if retrospectively it sounds like it was a mistake.
Regards,
- -- Youcef R. Rahal Arabeyes.org http://www.arabeyes.org/~rahal
On Tue, Jun 22, 2004 at 07:31:01PM +1000, Bernd Groh wrote:
The translator is the person that is currently translating the file, it will be set to a translator. iff somebody [Take]s the module, otherwise it's blank.
Just noticed another problem. If your translation is 100% finished but wrong there is no way to take it and fix it as it just shows "Finished"
Alan Cox schrieb:
On Tue, Jun 22, 2004 at 07:31:01PM +1000, Bernd Groh wrote:
The translator is the person that is currently translating the file, it will be set to a translator. iff somebody [Take]s the module, otherwise it's blank.
Just noticed another problem. If your translation is 100% finished but wrong there is no way to take it and fix it as it just shows "Finished"
If it's finished, everyone of that language group can commit to it. 99% of all conflicts we get with files that aren't finished, so we thought that to be reasonable.
Bernd
-- Fedora-trans-list mailing list Fedora-trans-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-trans-list
tis 2004-06-22 klockan 10.27 skrev Youcef Rabah Rahal:
Please feel free to ask if you have any questions and encountered any problems.
On the status page for each translated PO file, there's a field 'Translator' which is not clear. I understand that 'Last translator' is grabbed from the PO file (and I checked that the names there are OK regarding Arabic translation).
However, for dist.po I'm not sure how the fields are filled. I simply don't know the person whose name is put under 'Translator' nor that he ever participated in translation ? :-) Since he has a redhat email, i suppose this is some quality control ??!
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...
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.
Christian
Christian Rose schrieb:
tis 2004-06-22 klockan 10.27 skrev Youcef Rabah Rahal:
Please feel free to ask if you have any questions and encountered any problems.
On the status page for each translated PO file, there's a field 'Translator' which is not clear. I understand that 'Last translator' is grabbed from the PO file (and I checked that the names there are OK regarding Arabic translation).
However, for dist.po I'm not sure how the fields are filled. I simply don't know the person whose name is put under 'Translator' nor that he ever participated in translation ? :-) Since he has a redhat email, i suppose this is some quality control ??!
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.
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.
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.
Best Regards, Bernd
Christian
-- Fedora-trans-list mailing list Fedora-trans-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-trans-list
ke, 2004-06-23 kello 03:55, Bernd Groh kirjoitti:
Christian Rose schrieb:
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?
Making a good translation is not as easy as many people would think. The translator needs to have very good skills both in English, AND his/her own language. It is not enough, if you know English pretty well and know how to use an editor. Also, being very eager to participate does not mean that one has the capability for it. The majority of people probably could not make a good translation if they tried.
Therefore, it is safe to assume that a newcomer translator who pops out of nowhere is not capable of translating well enough. I am not saying this is always the case. Of course there can be newcomers who are good right from the beginning.
The newcomer does have the right to participate. However, if such a person enters a project, and starts committing bad translations (ie. inconsistent, grammatically bad, etc), it can lead to some consequences.
Assuming there have been an active team/person doing the translation, they may become annoyed seeing some group of untalented newcomers messing with their translations. Being annoyed, they may dump the whole project and let the newcomers continue. Which could lead to general deterioration of the translation. This, in turn, could lead to end users choosing another language, as they cannot stand the translation.
The scenario which I described above is a rather pessimistic one, yes. In general, new translators are welcome to participate. Still, in my opinion, they should at least be asked to write to the mailinglist of their language before they start, or to contact the previous translator of the file.
Lauri Nurmi wrote:
Making a good translation is not as easy as many people would think. The translator needs to have very good skills both in English, AND his/her own language. It is not enough, if you know English pretty well and know how to use an editor. Also, being very eager to participate does not mean that one has the capability for it. The majority of people probably could not make a good translation if they tried.
Therefore, it is safe to assume that a newcomer translator who pops out of nowhere is not capable of translating well enough. I am not saying this is always the case. Of course there can be newcomers who are good right from the beginning.
The newcomer does have the right to participate. However, if such a person enters a project, and starts committing bad translations (ie. inconsistent, grammatically bad, etc), it can lead to some consequences.
Assuming there have been an active team/person doing the translation, they may become annoyed seeing some group of untalented newcomers messing with their translations. Being annoyed, they may dump the whole project and let the newcomers continue. Which could lead to general deterioration of the translation. This, in turn, could lead to end users choosing another language, as they cannot stand the translation.
The scenario which I described above is a rather pessimistic one, yes. In general, new translators are welcome to participate. Still, in my opinion, they should at least be asked to write to the mailinglist of their language before they start, or to contact the previous translator of the file.
Good point here. I would like to suggest another enhancement to the system.
List out the name and email of people who are currently actively translating for a particular language. Example for Malay language, its me and Hasbullah Pit. It will help newcomer to seek guidance and information regarding the translation process and quality control.
A simple team page (like the one in KDE) would be better.
----- Sharuzzaman Ahmat Raslan
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Friday 25 June 2004 09:04, Lauri Nurmi wrote:
Making a good translation is not as easy as many people would think. The translator needs to have very good skills both in English, AND his/her own language. It is not enough, if you know English pretty well and know how to use an editor. Also, being very eager to participate does not mean that one has the capability for it. The majority of people probably could not make a good translation if they tried.
Therefore, it is safe to assume that a newcomer translator who pops out of nowhere is not capable of translating well enough. I am not saying this is always the case. Of course there can be newcomers who are good right from the beginning.
The newcomer does have the right to participate. However, if such a person enters a project, and starts committing bad translations (ie. inconsistent, grammatically bad, etc), it can lead to some consequences.
Assuming there have been an active team/person doing the translation, they may become annoyed seeing some group of untalented newcomers messing with their translations. Being annoyed, they may dump the whole project and let the newcomers continue. Which could lead to general deterioration of the translation. This, in turn, could lead to end users choosing another language, as they cannot stand the translation.
The scenario which I described above is a rather pessimistic one, yes. In general, new translators are welcome to participate. Still, in my opinion, they should at least be asked to write to the mailinglist of their language before they start, or to contact the previous translator of the file.
Absolutely. Agreed 100% ;-)
Regards,
- -- Youcef R. Rahal Arabeyes.org http://www.arabeyes.org/~rahal
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
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.
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@redhat.com http://www.redhat.com/mailman/listinfo/fedora-trans-list
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
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@redhat.com http://www.redhat.com/mailman/listinfo/fedora-trans-list
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,
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".
[ra@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@proxy anaconda]$
(thats the anaconda module)
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
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@redhat.com http://www.redhat.com/mailman/listinfo/fedora-trans-list
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
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.
- 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.
- 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.
- 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.
- 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.
- 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?
- 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@redhat.com http://www.redhat.com/mailman/listinfo/fedora-trans-list
On Thu, 2004-07-08 at 11:27, Bernd Groh wrote:
- 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
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
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@redhat.com http://www.redhat.com/mailman/listinfo/fedora-trans-list
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
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@redhat.com http://www.redhat.com/mailman/listinfo/fedora-trans-list
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
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
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
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
See revision 1.67 of anaconda/zh_CN.po
[sarahs@sarah anaconda]$ cvs up -r1.67 zh_CN.po Enter passphrase for key '/home/sarahs/.ssh/id_dsa': P zh_CN.po [sarahs@sarah anaconda]$ msgfmt -v -o /dev/null zh_CN.po 1499 translated messages.
? Sarah
On Fri, 2004-07-09 at 09:12 +1000, Sarah Wang wrote:
See revision 1.67 of anaconda/zh_CN.po
[sarahs@sarah anaconda]$ cvs up -r1.67 zh_CN.po Enter passphrase for key '/home/sarahs/.ssh/id_dsa': P zh_CN.po [sarahs@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
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@sarah anaconda]$ cvs up -r1.67 zh_CN.po Enter passphrase for key '/home/sarahs/.ssh/id_dsa': P zh_CN.po [sarahs@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
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
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@redhat.com http://www.redhat.com/mailman/listinfo/fedora-trans-list
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
--- Alan Cox alan@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
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@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-trans-list
____________________________________________________________ Do You Yahoo!? Αποκτήστε τη δωρεάν @yahoo.gr διεύθυνση σας στο http://www.otenet.gr
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
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
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@redhat.com http://www.redhat.com/mailman/listinfo/fedora-trans-list
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
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@redhat.com http://www.redhat.com/mailman/listinfo/fedora-trans-list
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
On Tue, Jun 22, 2004 at 01:15:01PM +1000, Sarah Wang wrote:
each package. It either says "Finished" (if the translation is 100%) or has a "Take" button (if the translation is not 100%). This feature is designed to minimise the commit conflicts and better coordinate the translation activity within the same language group. If you wish to
Only two.
1. What if someone needs to take an entry back (eg if someone goes on holiday and forgets)
2. It would be nice if people could grab the current .po file without having to "take" it - you need the other po files in order to make a translation consistent, and in the Welsh case for example it would help the Debian .cy people to see the translations used in Fedora
Alan
Alan Cox schrieb:
On Tue, Jun 22, 2004 at 01:15:01PM +1000, Sarah Wang wrote:
each package. It either says "Finished" (if the translation is 100%) or has a "Take" button (if the translation is not 100%). This feature is designed to minimise the commit conflicts and better coordinate the translation activity within the same language group. If you wish to
Only two.
- What if someone needs to take an entry back (eg if someone goes on
holiday and forgets)
Do you mean if somebody takes a module and forgets about it? The designated maintainer of a module, Sarah, and myself can release a module. Since we haven't assigned any maintainers yet, it's just us two. The next upgrade will release them automatically after a certain period of non-commit. For now, emailing this list and telling us will have to do.
- It would be nice if people could grab the current .po file without
having to "take" it - you need the other po files in order to make a translation consistent, and in the Welsh case for example it would help the Debian .cy people to see the translations used in Fedora
What do you mean with grab? For the purpose of modification? What if you do that while somebody else is in the process of translating the module? Everyone can just grab the module anytime, they just can't commit unconditional.
Bernd
Alan
-- Fedora-trans-list mailing list Fedora-trans-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-trans-list
On Wed, Jun 23, 2004 at 10:28:33AM +1000, Bernd Groh wrote:
What do you mean with grab? For the purpose of modification? What if you
To view.
do that while somebody else is in the process of translating the module? Everyone can just grab the module anytime, they just can't commit
I couldn't find any way to download them without a CVS account - as you can for example with the Gnome ones. A button to do that would be great because the .cy translation project isn't just a Fedora project
Alan
Alan Cox schrieb:
On Wed, Jun 23, 2004 at 10:28:33AM +1000, Bernd Groh wrote:
What do you mean with grab? For the purpose of modification? What if you
To view.
do that while somebody else is in the process of translating the module? Everyone can just grab the module anytime, they just can't commit
I couldn't find any way to download them without a CVS account - as you can for example with the Gnome ones. A button to do that would be great because the .cy translation project isn't just a Fedora project
I see. Noted for the next upgrade.
Bernd
Alan
-- Fedora-trans-list mailing list Fedora-trans-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-trans-list
2004-06-22, k keltezéssel 05:15-kor Sarah Wang ezt írta:
The new translation status page has been installed: http://elvis.redhat.com/cgi-bin/i18n-status
You will notice that there is a new column called "Availability" for each package. It either says "Finished" (if the translation is 100%) or has a "Take" button (if the translation is not 100%). This feature is designed to minimise the commit conflicts and better coordinate the translation activity within the same language group. If you wish to finish the translation of a package, just click "Take" button, fill in your login and password. Then you will be able to finish and commit the translation to cvs. All cvs account holders should have received or soon
Does this take-over mechanism work on finished files? E.g. when somebody wants to correct some recently found typos in a "Finished" translation, is take-over needed and possible?
Regards, Peti
Sulyok Peti schrieb:
2004-06-22, k keltezéssel 05:15-kor Sarah Wang ezt írta:
The new translation status page has been installed: http://elvis.redhat.com/cgi-bin/i18n-status
You will notice that there is a new column called "Availability" for each package. It either says "Finished" (if the translation is 100%) or has a "Take" button (if the translation is not 100%). This feature is designed to minimise the commit conflicts and better coordinate the translation activity within the same language group. If you wish to finish the translation of a package, just click "Take" button, fill in your login and password. Then you will be able to finish and commit the translation to cvs. All cvs account holders should have received or soon
Does this take-over mechanism work on finished files? E.g. when somebody wants to correct some recently found typos in a "Finished" translation, is take-over needed and possible?
As just mentioned in reply to Alan, there is no restriction on finished files, everyone of that language group can still commit to it.
Regards, Peti
-- Fedora-trans-list mailing list Fedora-trans-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-trans-list
On Wed, Jun 23, 2004 at 10:33:38AM +1000, Bernd Groh wrote:
E.g. when somebody wants to correct some recently found typos in a "Finished" translation, is take-over needed and possible?
As just mentioned in reply to Alan, there is no restriction on finished files, everyone of that language group can still commit to it.
I see the logic - although the lack of the take button makes it a bit confusing. I'd prefer to have it in that case too - I can think of examples where you do want to take a 100% translated file (for example normalising terminology). Minor issue anyway
Alan Cox schrieb:
On Wed, Jun 23, 2004 at 10:33:38AM +1000, Bernd Groh wrote:
E.g. when somebody wants to correct some recently found typos in a "Finished" translation, is take-over needed and possible?
As just mentioned in reply to Alan, there is no restriction on finished files, everyone of that language group can still commit to it.
I see the logic - although the lack of the take button makes it a bit confusing. I'd prefer to have it in that case too - I can think of examples where you do want to take a 100% translated file (for example normalising terminology). Minor issue anyway
True. Maybe we should discuss this on list (everyone that is)? Being a minor issue or not.
Bernd
-- Fedora-trans-list mailing list Fedora-trans-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-trans-list
-
Alan Cox -
Behdad Esfahbod -
Bernd Groh -
Christian Rose -
Doncho N. Gunchev -
Jeremy Katz -
Josep Puigdemont -
Keld Jørn Simonsen -
Lauri Nurmi -
Miloslav Trmač -
Nikos Charonitakis -
Pedro Fernandes Macedo -
Pedro Morais -
Richard Allen -
Sarah Wang -
Sharuzzaman Ahmat Raslan -
Sherif Abdelgawad -
Sulyok Peti -
Tino Meinen -
Youcef Rabah Rahal