Re: requesting string and feature freeze break for hamster-applet
2010-11-06 10:28 keltezéssel, Toms Baugis írta: was hoping to squeeze it in for 2.32.1 (tarballs due nov 15) as i don't see when 2.32.2 is scheduled if at all. apologies for late notice - life got into the way of my hacking activities Seems that it affects quite a few of your users, so i18n approval 1/2. Regards Gabor Kelemen On Sat, Nov 6, 2010 at 8:20 AM, Johannes Schmidj...@jsschmid.de wrote: Hi! In 2.32 project hamster lost the grand totals for the reports. Bit of regression and seems to be used by quite a few, so i'd like to reapply the patch that i just committed to git master[1]. It breaks 5 strings or so. Apologies for the size of the patch. What's the timeline for releasing this? I think something like 2 weeks is the minimum to allow translators to fix that. Regards, Johannes ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: GCompris needs a translation update
El dv 05 de 11 de 2010 a les 13:34 +0200, en/na Khaled Hosny va escriure: On Fri, Nov 05, 2010 at 01:29:15PM +0200, Simos Xenitellis wrote: On Fri, Nov 5, 2010 at 9:51 AM, Matej Urban matej.ur...@gmail.com wrote: Well, we don't care much, the master branch is unmaintained and hopefully nobody uses it. I understand this developers perspecitve. But I read your statement as: Well, we don't care much *about the quality of the translations*, the master branch is unmaintained and *if somebody uses it, , why do we bother translating anyway?*. I also read: If translators want some order in the project, they should get one of those boring paper-sorting jobs. I also hear: Anyway, be glad that we let you use it. Is really so hard to rename master to old_master and then rename gcomvcyvycprxsyvcyvcydsfdaso to master? I would say the concern is something like this, http://stackoverflow.com/questions/1526794/git-rename-remote-branch Bruno mentioned that he does not oppose to the switch (I am rephrasing). Therefore, assuming that indeed people would need to clone again the gcompris repository (who can verify this? Matej, Александър?), there should be an announcement for those with gcompris clones to clone again after a specific cutoff date. I discussed this a while ago with Bruno, and IIRC the only practical solution requires admin intervention because some git operations are restricted on g.g.o. Regards, Khaled Hi, Maybe there's an even easier solution if you (gcompris devs I mean) reply 'no' to the following question: Does any commit on master branch really matters[1]? If the answer is no then you can just clone gcompris and checkout master branch, then in a separate folder clone again compris and checkout to gcomprixogoo. With those two folders (one containing master and the other gcomprixogoo) just do a plain replace of all files changed and added from gcomprixogoo to master and remove all files not in gcomprixogoo which are on master and make a huge commit with it (or partial commits if you prefer). With this you will simulate a git merge but effectively you are making master as gcomprixogoo. With this approach no sysadmins' help is needed and you will be 100% sure that the resulting master branch will be exactly the gcomprixogoo branch. A first step to do this would be to plain copy/replace/remove all images and binary files, just doing a git diff --stat master..gcomprixogoo gives that +5k files are changed but lots of them are images which is trivial to move (you know the good ones are on gcomprixogoo) and it will allow git merge tool to be less stressed when doing the merge. After either approach is taken just create a new branch based on master if you still plan to work on different branches for stable/dev work. Hope this approach can help. Cheers, [1] Sure translations, but those can be easily migrated -- 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 planet: http://planet.guifi.net ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: GCompris needs a translation update
Hi! With this you will simulate a git merge but effectively you are making master as gcomprixogoo. With this approach no sysadmins' help is needed and you will be 100% sure that the resulting master branch will be exactly the gcomprixogoo branch. This would kill the complete history of the gcomprixgoo branch which I wouldn't do as a maintainer. What's the problem in mergin gcromprixgoo in the first place. If the two branches really diverged you could still just revert all commits on master that are in the way master doesn't really matter and do a merge. Maybe there is also some git flag to use the branch version in case of a conflict. I would just ask some git gurus on #gnome-hackers for help - I am pretty sure there is some way. Regards, Johannes ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: requesting string and feature freeze break for hamster-applet
Hi! On Sun, 2010-11-07 at 11:12 +0100, Gabor Kelemen wrote: 2010-11-06 10:28 keltezéssel, Toms Baugis írta: was hoping to squeeze it in for 2.32.1 (tarballs due nov 15) as i don't see when 2.32.2 is scheduled if at all. apologies for late notice - life got into the way of my hacking activities There is no 2.32.2 schedules but you can do one if you like to for your module. Seems that it affects quite a few of your users, so i18n approval 1/2. 2/2 from i18n. Johannes ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
String additions to 'hamster-applet.gnome-2-32'
This is an automatic notification from status generation scripts on: http://l10n.gnome.org. There have been following string additions to module 'hamster-applet.gnome-2-32': + Total Note that this doesn't directly indicate a string freeze break, but it might be worth investigating. ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: gedit taglist plugin moved to gedit-plugins
2010-11-06 22:13 keltezéssel, Paolo Borelli írta: Hi, I just moved in git the taglist plugin from the gedit module to the gedit-plugins module. The taglist plugin comes with quite a bit of translatable strings, so this is an heads-up so that translators know they just need to move the translations instead of redoing them. If someone knows a way to do this automatically, he is more than welcome to do such a change. Done: http://l10n.gnome.org/module/gedit-plugins/ I hope I didn't messed up anything, but translators please check the files - at least, Hungarian looked alright :) For the curious, this is what happened: for i in `ls -1 ../../gedit/po/ | cut -d . -f1`; do echo $i; if [ -f $i.po ] ; then msgmerge -o $i.po ../../gedit/po/$i.po $i.po; else cp ../../gedit/po/$i.po $i.po; fi; intltool-update $i; msgattrib --no-obsolete $i.po -o $i.po; done Also, I changed the extras set to track the master branch instead of gnome-2-32. Regards Gabor Kelemen ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: gedit taglist plugin moved to gedit-plugins
On Sun, Nov 07, 2010 at 02:14:32PM +0100, Gabor Kelemen wrote: 2010-11-06 22:13 keltezéssel, Paolo Borelli írta: Hi, I just moved in git the taglist plugin from the gedit module to the gedit-plugins module. The taglist plugin comes with quite a bit of translatable strings, so this is an heads-up so that translators know they just need to move the translations instead of redoing them. If someone knows a way to do this automatically, he is more than welcome to do such a change. Done: http://l10n.gnome.org/module/gedit-plugins/ I hope I didn't messed up anything, but translators please check the files - at least, Hungarian looked alright :) For the curious, this is what happened: for i in `ls -1 ../../gedit/po/ | cut -d . -f1`; do echo $i; if [ -f $i.po ] ; then msgmerge -o $i.po ../../gedit/po/$i.po $i.po; else cp ../../gedit/po/$i.po $i.po; fi; intltool-update $i; msgattrib --no-obsolete $i.po -o $i.po; done When I used `msgmerge` it fuzzied many of the legitimate translations in the original gedit-plugins file (essentially all fuzzies that I got should have not been touched), it also added a huge log of unused strings (~# lines) at the end of the file (I think that is the rest of strings in the gedit file), for this reason I'd preferred if each language coordinator would do it on his own. I think `pogrep` could have been used to extract 'taglist' specific strings from gedit and that would be then merged wit gedit-plugins, but I've no experience with it myself. Regards, Khaled -- Khaled Hosny Arabic localiser and member of Arabeyes.org team Free font developer ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
GCompris 9.4 BETA2 / Break of string freeze
Hi all, I uploaded a new release 9.4BETA2 for Windows to let you test the lastest changes: http://gcompris.net/incoming/gcompris-9.4BETA2.exe The only difference is the missing letter editor that I completly reviewed to support UTF-8. Also now I display error messages to help the user understand what must be done. By the way, it breaks the string freeze (sorry to translators). Bruno. ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: genius
I will soon be making a new release of genius, just a heads up in case anybody is translating. I'm shooting for release on Thursday (but I might get sidetracked and release later). There are very few changed strings. Jiri -- Jiri (George) Lebl, http://www.math.ucsd.edu/~jlebl/ or http://www.jirka.org/ ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
