Language names in translation status pages
Hi Carlos, can you please add the following language names to the translation status pages: dv Divehi gn Guarani zh_HK Chinese (Hong Kong) Thanks, Christian -- Forwarded message -- From: Raphael Higino [EMAIL PROTECTED] Date: May 12, 2006 3:23 AM Subject: Guarani language in status pages To: GNOME-i18n gnome-i18n@gnome.org Cc: Matheus [EMAIL PROTECTED] Hey, Carlos. Would you please include de name of Guarani team in the status pages http://l10n-status.gnome.org/gnome-2.14/top.html? The code is gn. Thanks. -- Raphael Higino ___ 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: Language names in translation status pages
El dom, 14-05-2006 a las 13:00 +0200, Christian Rose escribió: Hi Carlos, Hi can you please add the following language names to the translation status pages: dv Divehi gn Guarani zh_HK Chinese (Hong Kong) Done, later today should be applied. Cheers. Thanks, Christian -- Forwarded message -- From: Raphael Higino [EMAIL PROTECTED] Date: May 12, 2006 3:23 AM Subject: Guarani language in status pages To: GNOME-i18n gnome-i18n@gnome.org Cc: Matheus [EMAIL PROTECTED] Hey, Carlos. Would you please include de name of Guarani team in the status pages http://l10n-status.gnome.org/gnome-2.14/top.html? The code is gn. Thanks. -- Raphael Higino ___ 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: Translation status pages
Hi Ross, Today at 9:58, Ross Golder wrote: So, in the meantime, would it be possible for you to post the scripts you use for the translation status pages somewhere, and perhaps write up some brief notes/HOWTO (e.g. a l.g.o. wiki page) to help anyone (i.e. me) get things set up on a given box. In the meantime, I'll get the script(s) checked into a CVS module somewhere, start some sysadmin-oriented maintenance notes on the wiki and install and test it all on the Intel server as soon as it hits the rack, and we can take it from there (e.g. DNS updates etc). The code is what Carlos wrote, but I also have access to it, and I maintain the installation of i18n-status.gnome.org (back-up for l10n-status). The basic steps are: - get latest GNU gettext and intltool on the system (on i18n-status I have GNU gettext 0.14.5 and intltool-0.34.2 in my $HOME, since I am not admin and we need to update them when we get new releases) - get and install Carlos' scripts (they are in C) — if Carlos doesn't want to publish them, we can send them to you personally, putting it in $HOME/src - on i18n this is the script I call from crontab: #!/bin/sh unset LC_ALL unset LANG unset LANGUAGE export LC_ALL=C # I've compiled and installed gettext and intltool with --prefix=$HOME/intltool export PATH=$HOME/intltool/bin:$PATH export LD_LIBRARY_PATH=$HOME/intltool/lib CVSDIR=/home/ftp/cvs cd $HOME cvs -d:pserver:[EMAIL PROTECTED]:/cvs/gnome co -d gnome-i18n gnome-i18n/status/data/ignored-lang-list cvs -d:pserver:[EMAIL PROTECTED]:/cvs/gnome co -d gnome-i18n gnome-i18n/status/data/translation-status.xml src/estado --install-dir=$HOME/public_html --cvs-dir=$CVSDIR --modules-file=$HOME/gnome-i18n/translation-status.xml I've documented it on http://live.gnome.org/TranslationProject/SettingUpStatusPages as well, but there is still no source code which makes the gist of it :) I'll later document what we need for documentation status pages as shown on http://kvota.net/doc-l10n/ (latest xml2po, meaning Python+libxml2 as well), but the code for that is in Gnome CVS: http://cvs.gnome.org/viewcvs/gnome-i18n/status/doc-l10n-status/ I also want to unify both of these! Cheers, Danilo ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Translation status pages
El vie, 07-10-2005 a las 20:12 +0200, Danilo Šegan escribió: Today at 5:20, Owen Taylor wrote: [...] It does do significant disk work: it basically checks out entire gnome cvs, runs intltool-update -p and then msgmerge on every single PO file in Gnome CVS repository (sometimes for multiple branches) and creates hundreds of static .html files containing statistics. Creation of hundreds of static .html files seems like a prehistoric thing to do. Would it be too complicated to create a few xml files with the statistics data (or maybe insert it in a database) and then generate the html dinamically (to avoid too much intensive db access, these could be cached upon generation to avoid duplication). The flow would be like this: -process generates data (xml or sql) -user accesses a page first time (eg. /gnome-2.12/es/desktop/) -php generates the page from data and stores it in a temp dir -other user visits the same page -it gets shown from the temp dir (no duplicate generation, no db overhead) -temp dir gets erased every time the process runs Questions: -Pages that are never visited never get generated, is this a pro or a con? -Is this really less cpu intensive? I don't know if the sum of cpu time for all the pages that are visited (for the first time) is less than what we have now. Anyway, it's just an idea, I would volunteer to help with this if possible. Cheers, Lucas [...] -- Lucas Vieites Fariña [EMAIL PROTECTED] Web: http://www.asixinformatica.com/users/lucas/ Blog: http://www.asixinformatica.com/blog/ ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Translation status pages
On Thu, 2005-10-06 at 19:57 +0200, Christian Rose wrote: ons 2005-10-05 klockan 10:44 +0200 skrev Carlos Perelló Marín: If you'd prefer not to host it on your own server, and if there is willing to maintain it, I expect some space could possibly be arranged on one of the real gnome.org servers. It's just easier for the GNOME sysadmins to set up a DNS entry than it is to set up new user accounts and a secure/capable hosting area etc. It would probably get rolling quicker if hosted externally, at least to begin with ;) I agree with Ross; an external solution is probably the best in the short run, but in the long run, GNOME translation status pages and the translation status page scripts make sense to have hosted on the gnome.org servers. That will make sure that: * There are always several people distributed around the world who can access the machine and fix it if needed (gnome.org sysadmins) * The pipe is already a *very* Fat (tm) one * The status pages will not be inaccessible again when some single individual moves/goes on vacation/loses his job/gets hit by a bus and is unable to maintain them * The translation status pages will have access to the repository which sits right next to it at the very same location The only thing needed for the translation status pages to be hosted at the real, live gnome.org servers is for someone to figure out what kind of CPU/memory/disk resources it needs, and is prepared to help set it up, or at least give sufficient instructions for having it set up. So what's the required configuration? [EMAIL PROTECTED]:/srv/l10n # du -hs . 6.9G. and the process takes near 4 hours with an AMD Sempron(tm) 2800+ and 768MB of RAM With more RAM and faster CPU the process should be also faster. The main problem here is the hard disk I/O that's why we had to move it outside widget the first time, the server load was really high. widget has since then been replaced by window. window.gnome.org is a dual Xeon 2.8 GHz server with 2 GB memory and RAID1 SCSI disks. This should be doable, right? Sure, the server works, the problem are the other process on that machine not the generation of the status pages... I'm not able to tell you if that machine will work or not, sorry. As I said in other email, I don't mind to give shell access to you (Christian), danilo or any GNOME admin to have a backup Still, I think the Translation Status pages are too important to be hosted off-site. The work of the GTP effectively stops completely when the status pages are not working. Just to make it crystal clear, I don't have anything against that, I'm the maintainer, not the owner. If you are on vacation and the current server hosting the pages goes down, we aren't helped much by shell accounts. Sure, we can probably call someone, but whom? And how fast can it be fixed? My current hosting allows to control it over the web and reboot a recovery Linux system just in case is there any problem with the server so if finally we don't move it outside my server and offline problems became a problem (the stability of the server changed a lot since 6 months ago...) I could share that web access too with any GNOME sysadmin (it's better if I know him) With the gnome.org servers, emergency plans for all of that are already in place, and have been proven to be working. But having the translation status pages hosted somewhere completely else where I and others don't have any information of that sort doesn't make me sleep well at night. If the migration to GNOME server is doable, perfect, if it's not, I don't mind to get a plan in place so you can sleep well... Cheers. Christian -- Carlos Perelló Marín Ubuntu Hoary (PowerPC) = http://www.ubuntulinux.org Linux Registered User #121232 mailto:[EMAIL PROTECTED] || mailto:[EMAIL PROTECTED] http://carlos.pemas.net Valencia - Spain signature.asc Description: This is a digitally signed message part ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Translation status pages
On ศ., 2005-10-07 at 20:42 -0400, Owen Taylor wrote: On Fri, 2005-10-07 at 20:12 +0200, Danilo Šegan wrote: - If it really is that intensive, it's not optimizable, we need it on a gnome.org server, than container is probably the most appropriate home: window: 2 gig ram, 72gig (raid 1) disk, load avg ~1 container: 6 gig ram, 500gig (raid 5) disk, load avg ~0.2 Any machine with sufficient CPU power and low load will do. But, some amount of disk-bound work is still necessary, because we are anyway talking about working with/parsing full CVS code to find extractable strings, and then working on each PO file in turn. Basically, GNOME doesn't have a spare machine - all 4 of ours servers perform important roles in public services. A dedicated i18n machine wouldn't be such a bad request, seeing as the translation pages service seems to be held in a very high regard amongst the GTP team. I vaguely recall some big company asking us what server hardware we needed for GNOME project use (on the sysadmin list I think). I don't recall seeing a response or followup. Does else anyone remember? Does anyone know the outcome? -- Ross ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Translation status pages
Today at 5:20, Owen Taylor wrote: Something that takes 4 hours of CPU time on window (a day?) probably isn't a huge deal ... window isn't terribly CPU-bound currently... and the process could be niced down. Stats are usually done multiple times a day. I am not quite sure of the current schedule, but I think Carlos is doing them at least 3 times a day (7am, 3pm, 11pm). If you ask translators, they'd prefer to have them updated as often as possible. Though, with current code, that's not realistic. Carlos new stuff should provide that with much lower CPU usuage, by watching CVS directly. Now, if only someone found time to finish the code if Carlos doesn't make it (it's available in his svn repo somewhere on carlos.pemas.net, I think :). But if it's doing significant disk work - so ejecting stuff out of cache, then it's going to impact all bugzilla users, all anoncvs users, all people accessing www.gnome.org etc. window isn't really a good place to run intensive jobs, because so much is going on there. It does do significant disk work: it basically checks out entire gnome cvs, runs intltool-update -p and then msgmerge on every single PO file in Gnome CVS repository (sometimes for multiple branches) and creates hundreds of static .html files containing statistics. Things to do: - Try running it on window, see if it really takes 4 hours, or 2 hours. (30-45 minutes might be an OK time for an intensive task to churn.) - Get someone to look at optimizing it. You can do an incredible amount of work in 4 hours these days ... if this task is taking 4 hours, it's being done inefficiently. (Not volunteering) It is somewhat inefficient, and Carlos acknowledges it, since he has new status pages in the works which would provide more features and should be better suited for running on window. :) The big CPU-bound task is running msgmerge with fuzzy matching (it uses a slow string distance algorithm to find most similar strings in translations, and to reuse translations; now, imagine it working 50 times for a set of 5000 strings [eg. Evolution with 50 translations]). It's my estimate that most of the time is spent in it. I just ran a test drive without fuzzy matching, just as a check for my assumption, and the runtime dropped from 4.5 hours to 1.8 hours on i18n-status.gnome.org (it's another machine, hosted by Keld). Note that fuzzy matching is very important for translators, so basically, most of the process is CPU bound (some part of those 1.8 hours is also CPU bound, and the 60% time difference is definitely CPU- and memory-related). I have some ideas for optimising msgmerge step that will do a significantly better job (i.e. I'd first concatenate all the PO files to get a list of *all* English strings, and run msgmerge-style step once for such list and a POT file, creating a table of similarity matches: the problem with this is that it will require bit more memory, but it should speed up the process O(n) times, where n is the number of PO files/languages, provided we don't run into excessive memory page faults and swapping :). As for disk optimisations, storing statistics in the database is probably way better (and that's what Carlos' new code does) than generating hundreds of .html files. Another disk optimisation is handling of cvs checkouts. For different reasons, all cvs checkouts are usually done in full, i.e. checkout is first removed, and only then is it cvs coed again. If there was no hand tuning of cvs repositories in Gnome, maybe cvs up -Pd would be sufficient? I don't know enough details of CVS hacking to answer this, but the basic thing is that we need to insure pristine CVS tree before running intltool-update -p and msgmerge. - If it really is that intensive, it's not optimizable, we need it on a gnome.org server, than container is probably the most appropriate home: window: 2 gig ram, 72gig (raid 1) disk, load avg ~1 container: 6 gig ram, 500gig (raid 5) disk, load avg ~0.2 Any machine with sufficient CPU power and low load will do. But, some amount of disk-bound work is still necessary, because we are anyway talking about working with/parsing full CVS code to find extractable strings, and then working on each PO file in turn. Cheers, Danilo ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Translation status pages
Le vendredi 07 octobre 2005 à 20:12 +0200, Danilo Šegan a écrit : Another disk optimisation is handling of cvs checkouts. For different reasons, all cvs checkouts are usually done in full, i.e. checkout is first removed, and only then is it cvs coed again. If there was no hand tuning of cvs repositories in Gnome, maybe cvs up -Pd would be sufficient? I don't know enough details of CVS hacking to answer this, but the basic thing is that we need to insure pristine CVS tree before running intltool-update -p and msgmerge. Also, is it really useful to checkout the whole modules? Wouldn't checking out only the po/ directories help? Vincent -- Les gens heureux ne sont pas pressés. ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Translation status pages
Vincent Untz wrote: Le vendredi 07 octobre 2005 à 20:12 +0200, Danilo Šegan a écrit : Another disk optimisation is handling of cvs checkouts. For different reasons, all cvs checkouts are usually done in full, i.e. checkout is first removed, and only then is it cvs coed again. If there was no hand tuning of cvs repositories in Gnome, maybe cvs up -Pd would be sufficient? I don't know enough details of CVS hacking to answer this, but the basic thing is that we need to insure pristine CVS tree before running intltool-update -p and msgmerge. Also, is it really useful to checkout the whole modules? Wouldn't checking out only the po/ directories help? Vincent You can't extract strings from source files if you don't check out the source files themselves... # Adam -- Adam Weinberger [EMAIL PROTECTED] || [EMAIL PROTECTED] [EMAIL PROTECTED]|| [EMAIL PROTECTED] http://www.vectors.cx ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Translation status pages
ons 2005-10-05 klockan 10:44 +0200 skrev Carlos Perelló Marín: If you'd prefer not to host it on your own server, and if there is willing to maintain it, I expect some space could possibly be arranged on one of the real gnome.org servers. It's just easier for the GNOME sysadmins to set up a DNS entry than it is to set up new user accounts and a secure/capable hosting area etc. It would probably get rolling quicker if hosted externally, at least to begin with ;) I agree with Ross; an external solution is probably the best in the short run, but in the long run, GNOME translation status pages and the translation status page scripts make sense to have hosted on the gnome.org servers. That will make sure that: * There are always several people distributed around the world who can access the machine and fix it if needed (gnome.org sysadmins) * The pipe is already a *very* Fat (tm) one * The status pages will not be inaccessible again when some single individual moves/goes on vacation/loses his job/gets hit by a bus and is unable to maintain them * The translation status pages will have access to the repository which sits right next to it at the very same location The only thing needed for the translation status pages to be hosted at the real, live gnome.org servers is for someone to figure out what kind of CPU/memory/disk resources it needs, and is prepared to help set it up, or at least give sufficient instructions for having it set up. So what's the required configuration? [EMAIL PROTECTED]:/srv/l10n # du -hs . 6.9G. and the process takes near 4 hours with an AMD Sempron(tm) 2800+ and 768MB of RAM With more RAM and faster CPU the process should be also faster. The main problem here is the hard disk I/O that's why we had to move it outside widget the first time, the server load was really high. widget has since then been replaced by window. window.gnome.org is a dual Xeon 2.8 GHz server with 2 GB memory and RAID1 SCSI disks. This should be doable, right? As I said in other email, I don't mind to give shell access to you (Christian), danilo or any GNOME admin to have a backup Still, I think the Translation Status pages are too important to be hosted off-site. The work of the GTP effectively stops completely when the status pages are not working. If you are on vacation and the current server hosting the pages goes down, we aren't helped much by shell accounts. Sure, we can probably call someone, but whom? And how fast can it be fixed? With the gnome.org servers, emergency plans for all of that are already in place, and have been proven to be working. But having the translation status pages hosted somewhere completely else where I and others don't have any information of that sort doesn't make me sleep well at night. Christian ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Translation status pages
On Thu, 2005-10-06 at 19:57 +0200, Christian Rose wrote: The only thing needed for the translation status pages to be hosted at the real, live gnome.org servers is for someone to figure out what kind of CPU/memory/disk resources it needs, and is prepared to help set it up, or at least give sufficient instructions for having it set up. So what's the required configuration? [EMAIL PROTECTED]:/srv/l10n # du -hs . 6.9G. and the process takes near 4 hours with an AMD Sempron(tm) 2800+ and 768MB of RAM With more RAM and faster CPU the process should be also faster. The main problem here is the hard disk I/O that's why we had to move it outside widget the first time, the server load was really high. widget has since then been replaced by window. window.gnome.org is a dual Xeon 2.8 GHz server with 2 GB memory and RAID1 SCSI disks. This should be doable, right? Something that takes 4 hours of CPU time on window (a day?) probably isn't a huge deal ... window isn't terribly CPU-bound currently... and the process could be niced down. But if it's doing significant disk work - so ejecting stuff out of cache, then it's going to impact all bugzilla users, all anoncvs users, all people accessing www.gnome.org etc. window isn't really a good place to run intensive jobs, because so much is going on there. In any case, I wouldn't expect things to run faster on window than on Carlos's machine ... window is a bigger/faster machine, but it's no monster, and it's a heavily loaded bigger/faster machine. Disk space is rather tight on window too, though 7 gigs (added to /etc/rsyncd/backup.exclude appropriately) shouldn't be a big problem if we keep track. Things to do: - Try running it on window, see if it really takes 4 hours, or 2 hours. (30-45 minutes might be an OK time for an intensive task to churn.) - Get someone to look at optimizing it. You can do an incredible amount of work in 4 hours these days ... if this task is taking 4 hours, it's being done inefficiently. (Not volunteering) - If it really is that intensive, it's not optimizable, we need it on a gnome.org server, than container is probably the most appropriate home: window: 2 gig ram, 72gig (raid 1) disk, load avg ~1 container: 6 gig ram, 500gig (raid 5) disk, load avg ~0.2 Regards, Owen signature.asc Description: This is a digitally signed message part ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Translation status pages
On Sun, 2005-10-02 at 23:04 +0200, Christian Rose wrote: tis 2005-09-20 klockan 13:24 +0700 skrev Ross Golder: On จ., 2005-09-19 at 23:07 +0200, Keld Jørn Simonsen wrote: On Tue, Sep 20, 2005 at 02:11:32AM +0700, Ross Golder wrote: On ???., 2005-09-16 at 18:03 +0200, Keld Jørn Simonsen wrote: On Wed, Sep 14, 2005 at 03:37:51PM +0200, Danilo Šegan wrote: Hi everyone, Maybe we should look into providing alternative status pages until Carlos responds. Anyone with a strong machine with a lot of unused CPU cycles on a fat-pipe willing to donate a couple of hours of runtime a day for our l10n-status pages? We could do that, at klid.dk. We did provide some alternate status for gnome-i18n some years ago, so we have some idea of what is involved. We have a 100 Mbit connection and quite some spare CPU cycles. Anyway we would like to have it running in the night and niced. Please mail me with info on how to proceed. Sounds good. Perhaps we should arrange for 'status.gnome.org' to point to the machine that hosts these pages. Hmm, I thought you had another offer. Anyway, I am still willing to help. If you'd prefer not to host it on your own server, and if there is willing to maintain it, I expect some space could possibly be arranged on one of the real gnome.org servers. It's just easier for the GNOME sysadmins to set up a DNS entry than it is to set up new user accounts and a secure/capable hosting area etc. It would probably get rolling quicker if hosted externally, at least to begin with ;) I agree with Ross; an external solution is probably the best in the short run, but in the long run, GNOME translation status pages and the translation status page scripts make sense to have hosted on the gnome.org servers. That will make sure that: * There are always several people distributed around the world who can access the machine and fix it if needed (gnome.org sysadmins) * The pipe is already a *very* Fat (tm) one * The status pages will not be inaccessible again when some single individual moves/goes on vacation/loses his job/gets hit by a bus and is unable to maintain them * The translation status pages will have access to the repository which sits right next to it at the very same location The only thing needed for the translation status pages to be hosted at the real, live gnome.org servers is for someone to figure out what kind of CPU/memory/disk resources it needs, and is prepared to help set it up, or at least give sufficient instructions for having it set up. So what's the required configuration? [EMAIL PROTECTED]:/srv/l10n # du -hs . 6.9G. and the process takes near 4 hours with an AMD Sempron(tm) 2800+ and 768MB of RAM With more RAM and faster CPU the process should be also faster. The main problem here is the hard disk I/O that's why we had to move it outside widget the first time, the server load was really high. As I said in other email, I don't mind to give shell access to you (Christian), danilo or any GNOME admin to have a backup Cheers. Christian -- Carlos Perelló Marín Ubuntu Hoary (PowerPC) = http://www.ubuntulinux.org Linux Registered User #121232 mailto:[EMAIL PROTECTED] || mailto:[EMAIL PROTECTED] http://carlos.pemas.net Valencia - Spain signature.asc Description: This is a digitally signed message part ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Translation status pages
On จ., 2005-09-19 at 23:07 +0200, Keld Jørn Simonsen wrote: On Tue, Sep 20, 2005 at 02:11:32AM +0700, Ross Golder wrote: On ???., 2005-09-16 at 18:03 +0200, Keld Jørn Simonsen wrote: On Wed, Sep 14, 2005 at 03:37:51PM +0200, Danilo Šegan wrote: Hi everyone, Maybe we should look into providing alternative status pages until Carlos responds. Anyone with a strong machine with a lot of unused CPU cycles on a fat-pipe willing to donate a couple of hours of runtime a day for our l10n-status pages? We could do that, at klid.dk. We did provide some alternate status for gnome-i18n some years ago, so we have some idea of what is involved. We have a 100 Mbit connection and quite some spare CPU cycles. Anyway we would like to have it running in the night and niced. Please mail me with info on how to proceed. Sounds good. Perhaps we should arrange for 'status.gnome.org' to point to the machine that hosts these pages. Hmm, I thought you had another offer. Anyway, I am still willing to help. If you'd prefer not to host it on your own server, and if there is willing to maintain it, I expect some space could possibly be arranged on one of the real gnome.org servers. It's just easier for the GNOME sysadmins to set up a DNS entry than it is to set up new user accounts and a secure/capable hosting area etc. It would probably get rolling quicker if hosted externally, at least to begin with ;) -- Ross -- Ross ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Translation status pages
Hi Keld, Yesterday at 23:07, Keld Jørn Simonsen wrote: On Tue, Sep 20, 2005 at 02:11:32AM +0700, Ross Golder wrote: On ???., 2005-09-16 at 18:03 +0200, Keld Jørn Simonsen wrote: On Wed, Sep 14, 2005 at 03:37:51PM +0200, Danilo Šegan wrote: Hi everyone, Maybe we should look into providing alternative status pages until Carlos responds. Anyone with a strong machine with a lot of unused CPU cycles on a fat-pipe willing to donate a couple of hours of runtime a day for our l10n-status pages? We could do that, at klid.dk. We did provide some alternate status for gnome-i18n some years ago, so we have some idea of what is involved. We have a 100 Mbit connection and quite some spare CPU cycles. Anyway we would like to have it running in the night and niced. Please mail me with info on how to proceed. Sounds good. Perhaps we should arrange for 'status.gnome.org' to point to the machine that hosts these pages. Hmm, I thought you had another offer. Anyway, I am still willing to help. I had one from Francisco Javier F. Serrador. In the meantime, Carlos also got back from vacation, so I punted handling all this for after my exams. Francisco has since told me that the machine he was planning to use is not available anymore, so I guess we should go with your offer. Since I am still having a couple of exams, I'd rather not devote too much time to setting up stats generation. I can forward the mail (with code) which I wrote to Francisco to you personally, if you are ready to look into it yourself (eg. experiment a bit, read some code to see how it needs to be set up, etc. :). Of course, I am sure Ross (and the SysAdmin team) will be fast with subdomain DNS set-up once the machine is ready. Cheers, Danilo ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Translation status pages
On Tue, Sep 20, 2005 at 03:28:48PM +0200, Danilo Šegan wrote: Hi Keld, Yesterday at 23:07, Keld Jørn Simonsen wrote: On Tue, Sep 20, 2005 at 02:11:32AM +0700, Ross Golder wrote: On ???., 2005-09-16 at 18:03 +0200, Keld Jørn Simonsen wrote: On Wed, Sep 14, 2005 at 03:37:51PM +0200, Danilo Šegan wrote: Hi everyone, Maybe we should look into providing alternative status pages until Carlos responds. Anyone with a strong machine with a lot of unused CPU cycles on a fat-pipe willing to donate a couple of hours of runtime a day for our l10n-status pages? We could do that, at klid.dk. We did provide some alternate status for gnome-i18n some years ago, so we have some idea of what is involved. We have a 100 Mbit connection and quite some spare CPU cycles. Anyway we would like to have it running in the night and niced. Please mail me with info on how to proceed. Sounds good. Perhaps we should arrange for 'status.gnome.org' to point to the machine that hosts these pages. Hmm, I thought you had another offer. Anyway, I am still willing to help. I had one from Francisco Javier F. Serrador. In the meantime, Carlos also got back from vacation, so I punted handling all this for after my exams. Francisco has since told me that the machine he was planning to use is not available anymore, so I guess we should go with your offer. Since I am still having a couple of exams, I'd rather not devote too much time to setting up stats generation. I can forward the mail (with code) which I wrote to Francisco to you personally, if you are ready to look into it yourself (eg. experiment a bit, read some code to see how it needs to be set up, etc. :). OK, why not send me the code, and tell me how you think it should be handled. Of course, I am sure Ross (and the SysAdmin team) will be fast with subdomain DNS set-up once the machine is ready. Why not do the setup now, in that way the DNS will updated when things are ready here. I think the RR for status.gnome.org should just be a pointer to www.klid.dk Best regards Keld ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Translation status pages
On ศ., 2005-09-16 at 18:03 +0200, Keld Jørn Simonsen wrote: On Wed, Sep 14, 2005 at 03:37:51PM +0200, Danilo Šegan wrote: Hi everyone, Maybe we should look into providing alternative status pages until Carlos responds. Anyone with a strong machine with a lot of unused CPU cycles on a fat-pipe willing to donate a couple of hours of runtime a day for our l10n-status pages? We could do that, at klid.dk. We did provide some alternate status for gnome-i18n some years ago, so we have some idea of what is involved. We have a 100 Mbit connection and quite some spare CPU cycles. Anyway we would like to have it running in the night and niced. Please mail me with info on how to proceed. Sounds good. Perhaps we should arrange for 'status.gnome.org' to point to the machine that hosts these pages. -- Ross ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Translation status pages
On Tue, Sep 20, 2005 at 02:11:32AM +0700, Ross Golder wrote: On ???., 2005-09-16 at 18:03 +0200, Keld Jørn Simonsen wrote: On Wed, Sep 14, 2005 at 03:37:51PM +0200, Danilo Šegan wrote: Hi everyone, Maybe we should look into providing alternative status pages until Carlos responds. Anyone with a strong machine with a lot of unused CPU cycles on a fat-pipe willing to donate a couple of hours of runtime a day for our l10n-status pages? We could do that, at klid.dk. We did provide some alternate status for gnome-i18n some years ago, so we have some idea of what is involved. We have a 100 Mbit connection and quite some spare CPU cycles. Anyway we would like to have it running in the night and niced. Please mail me with info on how to proceed. Sounds good. Perhaps we should arrange for 'status.gnome.org' to point to the machine that hosts these pages. Hmm, I thought you had another offer. Anyway, I am still willing to help. Best regards keld ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Translation status pages
On Wed, Sep 14, 2005 at 03:37:51PM +0200, Danilo Šegan wrote: Hi everyone, Maybe we should look into providing alternative status pages until Carlos responds. Anyone with a strong machine with a lot of unused CPU cycles on a fat-pipe willing to donate a couple of hours of runtime a day for our l10n-status pages? We could do that, at klid.dk. We did provide some alternate status for gnome-i18n some years ago, so we have some idea of what is involved. We have a 100 Mbit connection and quite some spare CPU cycles. Anyway we would like to have it running in the night and niced. Please mail me with info on how to proceed. Best regards keld ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Translation status pages
On Wed, September 14, 2005 15:37, Danilo Å egan wrote: Hi everyone, Maybe we should look into providing alternative status pages until Carlos responds. Anyone with a strong machine with a lot of unused CPU cycles on a fat-pipe willing to donate a couple of hours of runtime a day for our l10n-status pages? Just wondering... Why isn't this done on a gnome.org server? Does it use too much CPU? Maybe it'd be possible to only update the data when a po file gets committed? Vincent -- Les gens heureux ne sont pas pressés. ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Translation status pages
Kt, 2005 09 15 12:46 +0200, Vincent Untz rašė: Just wondering... Why isn't this done on a gnome.org server? Does it use too much CPU? Maybe it'd be possible to only update the data when a po file gets committed? It will be useless then, it has to be updated when string changes happen in the code, as well. Žygis ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Translation status pages
On Thu, September 15, 2005 12:57, ®ygimantas Beruèka wrote: Kt, 2005 09 15 12:46 +0200, Vincent Untz raÅ¡Ä: Just wondering... Why isn't this done on a gnome.org server? Does it use too much CPU? Maybe it'd be possible to only update the data when a po file gets committed? It will be useless then, it has to be updated when string changes happen in the code, as well. Right. I should not answer mails when I'm hungry :-) Vincent -- Les gens heureux ne sont pas pressés. ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Translation status pages
Hi Vincent, Today at 12:46, Vincent Untz wrote: On Wed, September 14, 2005 15:37, Danilo Å egan wrote: Hi everyone, Maybe we should look into providing alternative status pages until Carlos responds. Anyone with a strong machine with a lot of unused CPU cycles on a fat-pipe willing to donate a couple of hours of runtime a day for our l10n-status pages? Just wondering... Why isn't this done on a gnome.org server? Does it use too much CPU? Maybe it'd be possible to only update the data when a po file gets committed? Well, we are definitelly going to request another machine from Gnome for all the status stuff: we currently have separate stuff for translation status (Carlos), doc status (Shaun) and doc translation status (myself). We have already discussed joining all our status stuff together (so we eg. do one CVS checkout, instead of three :), but we have not yet gotten around to implementing it. Since we also keep up with branches, this should turn out to be useful for jhbuild as well. Cheers, Danilo ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
