Re: Translation Team for Latin (la, lat)
Ysgrifennodd Petr Kovar: In the past, I was provided with some Recent Latin resource consisting of examples of computer terminology, I'm also aware of Roman Curia (or should I say Curia romana) publishing a lexicon for modern terms from time to time, but personally I somehow doubt that it'd enough for localization of something as extensive and as technical as GNOME. I've created a Wiki page: http://live.gnome.org/Latin Feel free to change it around; this is only my idea of what it should say. I've started going through Metacity's .pot and identifying terms we need (but only just started). Thomas -- Thomas Thurman, tthurman at gnome, http://blogs.gnome.org/tthurman You'd probably be better off using your bare hands than that thing! ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
i18n page in gnome.org
Hi! Found http://www.gnome.org/i18n/ (it's linked from open-tran.eu) This page is actually maintained? Should it be redirected to http://l10n.gnome.org/teams/ ? Regards, -- gil forcada [ca] guifi.net - una xarxa lliure que no para de créixer [en] guifi.net - a non-stopping free network bloc: http://gil.badall.net ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
GNOME 2.24: Worst release cycle I have been a part of [l10n/i18n]
Hello my fellow GNOME enthusiasts Ok so knowing that there is a tendency towards Too Long Didn't Read, if you think this looks to long, just skip to A set of interesting stats. Now that the GNOME 2.24 release is well delivered, I though it was time for a little evaluation. I am a translator, and as such I often get exposed to the problems that are included, in trying to get a bunch of hired people and volunteers working well together on a single project. Some of these problem arise from communication problems between the different groups and their lack of knowledge about how the other group works, and they sometimes end up giving one or the other group extra work. All of this is not uncommon, but this release left an impression on me as being one of the worst ones I have had the pleasure of working on. Lets recap! gdm: I know that this particular problem has much more far reaching implications than just translation, but let me emphasize how it looked from the point of translators. Remembering last releases trouble with gdm i decided to go proactive and on August 4 (right after module and feature freeze, and release minus 1month20days) i wrote an email asking which version we would be shipping. There is a total string difference of 665 strings in between say version gnome-2-20 and trunk, so it does have some effect on out workload. I was told that it was pending a release team decision and that we would be informed within two weeks. The next I heard of it was a mail on Sep. 22 (release minus 2days !) telling us that gdm trunk would be used. Thanks a lot. libgweather: On August 4 (release minus 1month20 days)we were informed of a major update in libgweather-locations. This update was so large that it decreased all teams translation stats by about 5-6%. Obviously the change had required a lot a work, and so could have been partially committed earlier to give us some more time. But what is significantly worse is, that in the following discussion on the gnome-i18n list several incorrections in the string selection rule was identified which can only lead me to the conclusion that the state of completion this work is in, does not at all warrant the effort we were asked to put in it. So thanks to libgweather-locations we, the Danish translation team, were on Sep 25 able to proudly present[1] that fact that we had gotten gnome 2.24 translated up to a whooping 96%, no no not 100% as in the last two releases but 96%, nice! I am by way the still working on it, where on occasion my left pinky cramps up from all the f C-j y tab sequences in emacs. evolution: Ok so this is not a problem that is limited to evolution, it is just that much more visible here because it is such a big module. In evolution this time there was an update of 368 strings, the problem is that while going through it, I realized that a very large part of these strings I had to update, was due to a change from ' or quot; to (I know there were at least 35 of the latter kind, the first one is a little harder to grep for). This means, that if the relevant devs had a some point taken ~15 minutes to discuss string conventions, this update could have been avoided all together, nice!!. What makes it all a little more funny is that I still saw some ' and quot;s left which means, that I can only assume that I will be at it again next time. IF this is a general tendency, that means that 10% of the strings we have to update (that's about 4-600 strings) only needs update because someone didn't bother making a convention, and therefore essentially pi all over our efforts. A set of interesting stats. === This is a list of modules, which the GNOME status page has told us on the gnome-i18n list, that there has been made changes to AFTER string freeze on Sep. 1 and until release. (I already sorted the ones out we were told were false alarms). eog 21. sep. gtk+ 19. sep. hamster-applet 17. sep. cheese 15. sep. tomboy 15. sep. glib 15. sep. hamster-applet 15. sep. anjuta 15. sep. hamster-applet 15. sep. gnome-utils 8. sep. mousetweaks 6. sep. anjuta 4. sep. gnome-session 4. sep. deskbar-applet 3. sep. Now I count 14 changes in there and _11_ individual modules. Surely there is some amount of false alarms, and some legitimate freeze breaks (i.e. the ones that are due to bugs that have been reported very late in the release schedule). But there is also a fair amount of Ohh are we in string freeze Don't worry, these strings will not be seen by anyone ;) Calm down, this is not _technically_ a string freeze break, because we just forgot to mark them for translation/add the file in potfiles.in and Ehh, I have had this patch laying around for a couple of months now, which fixes this really ugly thing, I really like to have it in and I just forgot to commit it, would that be OK? 's in there. Ok let my say this once so clearly that even a 10 year old should be able to under stand it. IT DOES NOT MATTER FOR TRANSLATORS whether it is
Re: GNOME 2.24: Worst release cycle I have been a part of [l10n/i18n]
El dom, 12-10-2008 a las 14:08 +0200, Kenneth Nielsen escribió: Hello my fellow GNOME enthusiasts [...] A set of interesting stats. === This is a list of modules, which the GNOME status page has told us on the gnome-i18n list, that there has been made changes to AFTER string freeze on Sep. 1 and until release. (I already sorted the ones out we were told were false alarms). eog 21. sep. gtk+ 19. sep. hamster-applet 17. sep. cheese 15. sep. tomboy 15. sep. glib 15. sep. hamster-applet 15. sep. anjuta 15. sep. hamster-applet 15. sep. gnome-utils 8. sep. mousetweaks 6. sep. anjuta 4. sep. gnome-session 4. sep. deskbar-applet 3. sep. Now I count 14 changes in there and _11_ individual modules. I would like to point out that probably all of those changes were approved by the i18n team, as requested by our procedures. If you consider some of those breaks to be unjustified, then you could have expressed your opinion during the freeze break requests evaluation. As a translator, I am sure your opinion would be well considered before the approvals were given. 's in there. Ok let my say this once so clearly that even a 10 year old should be able to under stand it. IT DOES NOT MATTER FOR TRANSLATORS whether it is technically a string freeze or not, new strings means that we will have to update the module once more, and really there are better things to spend our time on. Not knowing about the freezes and old patches! Come on, you are asked to stay of of the strings for 20 freaking days each release, how difficult can that be! How difficult can it be? Well, far from ideal, for sure. Translators work is hard, I know that, and I respect it enourmosly. Seriously. But let's not trivialize the fact that it's also hard for us to handle issues smoothly during the development cycles. Just as volunteer translators, volunteer developers also have a life and sometimes you can't get your hands on the issues in the most appropriate moment. Life sucks, but believe me that we all make our best effort to make it suck as less as possible. Claudio -- Claudio Saavedra [EMAIL PROTECTED] ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: i18n page in gnome.org
On 10/12/08, Gil Forcada [EMAIL PROTECTED] wrote: Found http://www.gnome.org/i18n/ (it's linked from open-tran.eu) This page is actually maintained? Should it be redirected to http://l10n.gnome.org/teams/ ? That page contains end user information on supported languages. I don't think entirely replacing it with http://l10n.gnome.org/teams/ is appropriate, as those pages are mostly aimed at localization contributors, but anyway, the current list of supported languages at that page is probably outdated. That part could probably just be replaced with a link to the i18n section of the latest stable release notes, http://library.gnome.org/misc/release-notes/2.24/#rni18 currently. But then someone needs to remember to update that link for each new release. :-) The http://www.gnome.org/i18n/ page is kept in SVN, by the way; see http://svn.gnome.org/viewvc/gnomeweb-wml/trunk/www.gnome.org/i18n/index.wml. Patches and suggestions welcome... Christian ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: GNOME 2.24: Worst release cycle I have been a part of [l10n/i18n]
2008/10/12 Claudio Saavedra [EMAIL PROTECTED]: El dom, 12-10-2008 a las 14:08 +0200, Kenneth Nielsen escribió: Hello my fellow GNOME enthusiasts [...] A set of interesting stats. === This is a list of modules, which the GNOME status page has told us on the gnome-i18n list, that there has been made changes to AFTER string freeze on Sep. 1 and until release. (I already sorted the ones out we were told were false alarms). eog 21. sep. gtk+ 19. sep. hamster-applet 17. sep. cheese 15. sep. tomboy 15. sep. glib 15. sep. hamster-applet 15. sep. anjuta 15. sep. hamster-applet 15. sep. gnome-utils 8. sep. mousetweaks 6. sep. anjuta 4. sep. gnome-session 4. sep. deskbar-applet 3. sep. Now I count 14 changes in there and _11_ individual modules. I would like to point out that probably all of those changes were approved by the i18n team, as requested by our procedures. If you consider some of those breaks to be unjustified, then you could have expressed your opinion during the freeze break requests evaluation. As a translator, I am sure your opinion would be well considered before the approvals were given. Yes, either they were approved or they are in the category of technically not a string freeze break which does not require approval. Another thing is that, for the changes that does require approval (like the patch for an old or new bug being submitted), yes, I could have objected. However if it is a patch for a new major bug, then it should be approved without a hickup no matter if it introduces new strings or not. , most of the time, I do not feel knowledgeable enough the matter to make the objection, et the very least not without having to research the matter in which case it causes extra work no matter what. A separate matter is: Why do we always have to be the ones that say no? With any luck I might be a parent one day, so I really don't want to have to get into that habit to early. I suppose one of the thing I asking for, is a little more project (project as in module not GNOME as a whole) leader responsibility as well, since probably some of these thing should have been rejected already at that level, before even reaching us. If you want an example of this, you can read the thread from the gnome-i18n list from Sep 16 about a string addition to glade3. I'm not sure whether it really ended up actually adding strings, but it was clear enough that not many thoughts had been given to the rest of the group from them. 's in there. Ok let my say this once so clearly that even a 10 year old should be able to under stand it. IT DOES NOT MATTER FOR TRANSLATORS whether it is technically a string freeze or not, new strings means that we will have to update the module once more, and really there are better things to spend our time on. Not knowing about the freezes and old patches! Come on, you are asked to stay of of the strings for 20 freaking days each release, how difficult can that be! How difficult can it be? Well, far from ideal, for sure. Translators work is hard, I know that, and I respect it enourmosly. Seriously. But let's not trivialize the fact that it's also hard for us to handle issues smoothly during the development cycles. Just as volunteer translators, volunteer developers also have a life and sometimes you can't get your hands on the issues in the most appropriate moment. Life sucks, but believe me that we all make our best effort to make it suck as less as possible. Claudio I understand the predicament of the volunteer, especially when it comes to time. But being a volunteer does not mean that you can ignore your responsibilities once you are commited. Being a volunteer means that you decide whether you perform the task or not, not that you can decide to perform it any way or style you want to. By the way I understand that a lot of developers, volunteers as paid, are working as hard as they can to keep it all running as smooth as possible, the only thing I'm saying is that this release felt worse than usual, to a degree where it really stopped being funny to contribute. That is a dangerous situation because that is where you start to loose contributers. Not me off course, this is not that kind of mail of all, besides I'm also in it for the ideology more than just for the fun. But new contributers don't have to be exposed to that much before they call quits and find something else, now being asked to translated some thousands names of weather stations, a list that they (if they follow the gnome-i18n list) might expect are far from done being changed, might just be one of those things that could scare them of. Regards Kenneth Nielsen ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: GNOME 2.24: Worst release cycle I have been a part of [l10n/i18n]
Hi! A set of interesting stats. === This is a list of modules, which the GNOME status page has told us on the gnome-i18n list, that there has been made changes to AFTER string freeze on Sep. 1 and until release. (I already sorted the ones out we were told were false alarms). eog 21. sep. gtk+ 19. sep. hamster-applet 17. sep. cheese 15. sep. tomboy 15. sep. glib 15. sep. hamster-applet 15. sep. anjuta 15. sep. hamster-applet 15. sep. gnome-utils 8. sep. mousetweaks 6. sep. anjuta 4. sep. gnome-session 4. sep. deskbar-applet 3. sep. I have no stats about that but I feel that there were quite a few changes due to the fact that translators filed bugs against strings/untranslatable strings. I could argue now that they should have done is earlier - but of course they don't do that before string freeze usually so these things simply come up late in the cycle. What was really bad in this cycle IMHO was, that lot's of developers did NOT ask for string freeze breaks but just committed. That really shouldn't happen in the future as anybody can read in the MaintainersCorner how to handle these freezes. Same is for sending announcements when not technical string freeze breaks happen. It makes the work of the i18n team much easier when we know why damned-lies tells us there have been changes if we get such announcements. In addition what happened to gdm and glade3 (gnome-2-22 was used there) should really not happen again. The release team has to make such decisions early and maintainers have to announce when they will not release from trunk for a new branch. This really sucked this cycle I think the release-team failed here. Regards, Johannes signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: String additions to 'epiphany.gnome-2-24'
On 10/12/08, Leonardo F. Fontenelle [EMAIL PROTECTED] wrote: Em Seg, 2008-10-13 às 00:57 +, GNOME Status Pages escreveu: This is an automatic notification from status generation scripts on: http://l10n.gnome.org/. There have been following string additions to module 'epiphany.gnome-2-24': + Cannot Load Document While Working Offline + Cannot load document while working offline. Note that this doesn't directly indicate a string freeze break, but it might be worth investigating. Diego, your commit broke a string freeze: http://svn.gnome.org/viewvc/epiphany?view=revisionrevision=8580 It is evident from the URL that you were carreful enough to fix message catalogs as well, so that virtually no translation team will get hurt. But it's still an unapproved string freeze break... We (translators) were just discussing communication issues between develpers and translators in this release cycle. Oh sorry about that, since it was almost a typo fix I didn't notify you. I mean, since the meaning has not changed, I assumed noone would mind. I tested with the Spanish translation and the replace in the .po files worked as expected. I'm aware of string freeze policy and while this is technically a new string, in practice it's just a word replaced, that plus the .po files being patched too made me consider it as a safe change. If I understand correctly, no translation was broken right? That was my rationale, I also see your point. I will consider it as a string freeze break next time. Thanks for the clarification Diego ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Semi vacations
During the days October 21 to December 1st I'll be partially unavailable to GNOME translation, because of some graduate dissertation deadlines [1]. During this period, I'll stop reading mailing lists but will continue to read private mail. Anyone is more than welcome to email me as usual, no need to think twice. I don't think it will be necessary to indicate a substitute, because the Brazilian Portuguese GNOME translation team (which I coordinate) has other committers and enough skilled translators. I'll be around until the release of GNOME 2.24.1, so you'll have to bare me a little more ;) 1. If you are from Latin America or the Iberic Peninsule, read: http://www.gnome.org/~csaavedra/news-2007-10.html#D06 -- Leonardo Fontenelle http://leonardof.org ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
