Thread: Need idea for a web framework for NLS site
I'm looking for suggestions for a new/better web framework to run the NLS web site <http://pgtranslation.projects.postgresql.org/>. It's currently using "DocBook website", which is crufty and has all kinds of weird XML dependencies. I have tried to rewrite it using Ikiwiki, but that also has some very particular weirdnesses that annoyed me very much. I don't necessarily want to change the layout or contents of the web site at all, but I would like to have a toolkit that has less overhead. Requirements are roughly: * Perfect and flawless table support is essential. The page <http://pgtranslation.projects.postgresql.org/status.html> is pretty much the core of the service, so it must work well. I currently create HTML tables using a script and include them, but pretty much every toolkit has problems in this area. I am not attached to the HTML markup, however. * Low-tech, standard tools available through FreeBSD ports collection, or whatever the sysadmins want to deal with. * PostgreSQL-themable. * Preferrably understandable and maintainable by more than one person. Recommendations would be greatly appreciated.
Peter Eisentraut wrote: > I'm looking for suggestions for a new/better web framework to run the > NLS web site <http://pgtranslation.projects.postgresql.org/>. It's > currently using "DocBook website", which is crufty and has all kinds of > weird XML dependencies. I have tried to rewrite it using Ikiwiki, but > that also has some very particular weirdnesses that annoyed me very much. > > I don't necessarily want to change the layout or contents of the web > site at all, but I would like to have a toolkit that has less overhead. > > Requirements are roughly: > > * Perfect and flawless table support is essential. The page > <http://pgtranslation.projects.postgresql.org/status.html> is pretty > much the core of the service, so it must work well. I currently create > HTML tables using a script and include them, but pretty much every > toolkit has problems in this area. I am not attached to the HTML > markup, however. > > * Low-tech, standard tools available through FreeBSD ports collection, > or whatever the sysadmins want to deal with. > > * PostgreSQL-themable. > > * Preferrably understandable and maintainable by more than one person. > > Recommendations would be greatly appreciated. Can you explain a little more what the idea is? Is it just generating this one HTML page, or is there some more logic behind it? Does it make actual modifications somewhere? What's the source data? A pgfoundry CVS repository? Anything else? On the surface it *seems* like it should be simple :) Seems like it should be easy enough to extend your script with one of the templating engines we're already working with for other websites. //Magnus
On Tue, 2008-12-30 at 15:50 +0200, Peter Eisentraut wrote: > * Low-tech, standard tools available through FreeBSD ports collection, > or whatever the sysadmins want to deal with. > > * PostgreSQL-themable. > > * Preferrably understandable and maintainable by more than one person. > > Recommendations would be greatly appreciated. Drupal. Sincerely, Joshua D. Drake -- PostgreSQL Consulting, Development, Support, Training 503-667-4564 - http://www.commandprompt.com/ The PostgreSQL Company,serving since 1997
Joshua D. Drake wrote: > On Tue, 2008-12-30 at 15:50 +0200, Peter Eisentraut wrote: > >> * Low-tech, standard tools available through FreeBSD ports collection, >> or whatever the sysadmins want to deal with. >> >> * PostgreSQL-themable. >> >> * Preferrably understandable and maintainable by more than one person. >> >> Recommendations would be greatly appreciated. > > Drupal. I think that mail fail point nr 1 above :-P //Magnus
On Tue, 2008-12-30 at 18:20 +0100, Magnus Hagander wrote: > Joshua D. Drake wrote: > > On Tue, 2008-12-30 at 15:50 +0200, Peter Eisentraut wrote: > > > >> * Low-tech, standard tools available through FreeBSD ports collection, > >> or whatever the sysadmins want to deal with. > >> > >> * PostgreSQL-themable. > >> > >> * Preferrably understandable and maintainable by more than one person. > >> > >> Recommendations would be greatly appreciated. > > > > Drupal. > > I think that mail fail point nr 1 above :-P Drupal is in ports. It is already used within the standard network (pugs), is themeable, and for what Peter wants is a frankly perfect choice. And if nothing else, there is *nothing* else that I can think of that meats the low tech standard and can be managed by more than one person. Sincerely, Joshua D. Drake > > //Magnus > -- PostgreSQL Consulting, Development, Support, Training 503-667-4564 - http://www.commandprompt.com/ The PostgreSQL Company,serving since 1997
Joshua D. Drake wrote: > On Tue, 2008-12-30 at 18:20 +0100, Magnus Hagander wrote: >> Joshua D. Drake wrote: >>> On Tue, 2008-12-30 at 15:50 +0200, Peter Eisentraut wrote: >>> >>>> * Low-tech, standard tools available through FreeBSD ports collection, >>>> or whatever the sysadmins want to deal with. >>>> >>>> * PostgreSQL-themable. >>>> >>>> * Preferrably understandable and maintainable by more than one person. >>>> >>>> Recommendations would be greatly appreciated. >>> Drupal. >> I think that mail fail point nr 1 above :-P > > Drupal is in ports. It is already used within the standard network > (pugs), is themeable, and for what Peter wants is a frankly perfect > choice. I will reserve judgement until Peter actually comes back and answers my questions I had earlier. But my initial impression is that Drupal would be both a *huge* overkill (AFAICS we are talking a grand total of two pages right now?) and a very limiting factor in how things are done. But it could be that I've not understood the requirements. > And if nothing else, there is *nothing* else that I can think of that > meats the low tech standard and can be managed by more than one person. You have got to be kidding me :-) I think we are seeing this at completely differnet levels. Let's wait for Peter to straighten out the requirements. //Magnus
Tino Wildenhain wrote: > Joshua D. Drake wrote: >> On Tue, 2008-12-30 at 18:20 +0100, Magnus Hagander wrote: >>> Joshua D. Drake wrote: >>>> On Tue, 2008-12-30 at 15:50 +0200, Peter Eisentraut wrote: >>>> >>>>> * Low-tech, standard tools available through FreeBSD ports >>>>> collection, or whatever the sysadmins want to deal with. >>>>> >>>>> * PostgreSQL-themable. >>>>> >>>>> * Preferrably understandable and maintainable by more than one person. >>>>> >>>>> Recommendations would be greatly appreciated. >>>> Drupal. >>> I think that mail fail point nr 1 above :-P >> >> Drupal is in ports. It is already used within the standard network >> (pugs), is themeable, and for what Peter wants is a frankly perfect >> choice. >> > I still wonder why the web stuff for the postgres site seems so sticked > to PHP. My personal opinion is it just does not match up with the > overall quality of the project. But sure I can't say much on the > expertise of the web and system team when it comes to scripting > languages and web frameworks. Today, I'd say the main reason it looks the way it does is legacy. We have code. It's looked that way for a while. nad it works pretty well. I'm more concerned about the html/layout side of things where we currently don't have anybody who *really* knows how things are tied together between the HTML and the CSS. It's very much a guessing game whenever we try to change something... So if you want to offer your services, that's a good place to start :D /Magnus
Joshua D. Drake wrote: > On Tue, 2008-12-30 at 18:20 +0100, Magnus Hagander wrote: >> Joshua D. Drake wrote: >>> On Tue, 2008-12-30 at 15:50 +0200, Peter Eisentraut wrote: >>> >>>> * Low-tech, standard tools available through FreeBSD ports collection, >>>> or whatever the sysadmins want to deal with. >>>> >>>> * PostgreSQL-themable. >>>> >>>> * Preferrably understandable and maintainable by more than one person. >>>> >>>> Recommendations would be greatly appreciated. >>> Drupal. >> I think that mail fail point nr 1 above :-P > > Drupal is in ports. It is already used within the standard network > (pugs), is themeable, and for what Peter wants is a frankly perfect > choice. > I still wonder why the web stuff for the postgres site seems so sticked to PHP. My personal opinion is it just does not match up with the overall quality of the project. But sure I can't say much on the expertise of the web and system team when it comes to scripting languages and web frameworks. I wish a happy new year (soon :) Tino
On Tue, 2008-12-30 at 18:59 +0100, Magnus Hagander wrote: > Tino Wildenhain wrote: > > I still wonder why the web stuff for the postgres site seems so sticked > > to PHP. My personal opinion is it just does not match up with the > > overall quality of the project. But sure I can't say much on the > > expertise of the web and system team when it comes to scripting > > languages and web frameworks. > > Today, I'd say the main reason it looks the way it does is legacy. We > have code. It's looked that way for a while. nad it works pretty well. > And there is a certain contingent of people that would love to see it moved to python :P. > I'm more concerned about the html/layout side of things where we > currently don't have anybody who *really* knows how things are tied > together between the HTML and the CSS. It's very much a guessing game > whenever we try to change something... So if you want to offer your > services, that's a good place to start :D +1 on this. Joshua D. Drake > > /Magnus > -- PostgreSQL Consulting, Development, Support, Training 503-667-4564 - http://www.commandprompt.com/ The PostgreSQL Company,serving since 1997
Magnus Hagander wrote: > Tino Wildenhain wrote: >> Joshua D. Drake wrote: ... > Today, I'd say the main reason it looks the way it does is legacy. We > have code. It's looked that way for a while. nad it works pretty well. > > I'm more concerned about the html/layout side of things where we > currently don't have anybody who *really* knows how things are tied > together between the HTML and the CSS. It's very much a guessing game > whenever we try to change something... So if you want to offer your > services, that's a good place to start :D Yeah, I was actually offering the same during the early start of the new design but never ever got answer. Maybe I restart this time :-) Cheers Tino
Joshua D. Drake wrote: > And if nothing else, there is *nothing* else that I can think of that > meats the low tech standard and can be managed by more than one person. I think "more than one person" does not mean "any random guy round the corner", it means "somebody else from the team, preferrably people who is already is charge of the website". Note that there are a total of 3 static pages (which can be done with plain HTML as far as I'm concerned, though Peter might disagree; but since they change so rarely I fail to see the point of anything much more elaborate) and one page with a bunch of tables which is currently generated by, I think, a mix of shell + perl. I think this last page is the one giving trouble. I'd suggest dumping the list of languages and numbers in some easy-to-generate format (say YAML or JSON) and reading that to generate the static tables using a basic template and a plain Perl or PHP program. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Alvaro Herrera wrote: > I think this last page is the one giving trouble. I'd suggest dumping > the list of languages and numbers in some easy-to-generate format (say > YAML or JSON) and reading that to generate the static tables using a > basic template and a plain Perl or PHP program. FWIW the archives.postgresql.org is already using a mixture of Perl and PHP using JSON as glue, and it seems to work fine; see here for the code https://pgweb.postgresql.org/browser/trunk/archives -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
Alvaro Herrera wrote: > Joshua D. Drake wrote: > >> And if nothing else, there is *nothing* else that I can think of that >> meats the low tech standard and can be managed by more than one person. > > I think "more than one person" does not mean "any random guy round the > corner", it means "somebody else from the team, preferrably people who > is already is charge of the website". Now we know some of the goals it would be nice to learn about the people already in charge, who are they and what do they know about languages and frameworks? This would make it much more easy to recommend something. I read that we have freebsd, perl and PHP so far... Cheers Tino
Tino Wildenhain wrote: > Alvaro Herrera wrote: >> Joshua D. Drake wrote: >> >>> And if nothing else, there is *nothing* else that I can think of that >>> meats the low tech standard and can be managed by more than one person. >> >> I think "more than one person" does not mean "any random guy round the >> corner", it means "somebody else from the team, preferrably people who >> is already is charge of the website". > > Now we know some of the goals it would be nice to learn about the people > already in charge, who are they and what do they know about languages > and frameworks? This would make it much more easy to recommend > something. I read that we have freebsd, perl and PHP so far... Oh, if you're into what we *have*, we also have python, django, postgresql (d'uh), mediawiki.. Ehh. I'm sure you can find a lot more. //Magnus
Magnus Hagander wrote: > Tino Wildenhain wrote: >> Alvaro Herrera wrote: >>> Joshua D. Drake wrote: >>> >>>> And if nothing else, there is *nothing* else that I can think of that >>>> meats the low tech standard and can be managed by more than one person. >>> I think "more than one person" does not mean "any random guy round the >>> corner", it means "somebody else from the team, preferrably people who >>> is already is charge of the website". >> Now we know some of the goals it would be nice to learn about the people >> already in charge, who are they and what do they know about languages >> and frameworks? This would make it much more easy to recommend >> something. I read that we have freebsd, perl and PHP so far... > > Oh, if you're into what we *have*, we also have python, django, > postgresql (d'uh), mediawiki.. Ehh. I'm sure you can find a lot more. a _LOT_ more actually :-) Stefan
Stefan Kaltenbrunner wrote: > Magnus Hagander wrote: >> Tino Wildenhain wrote: >>> Alvaro Herrera wrote: >>>> Joshua D. Drake wrote: >>>> >>>>> And if nothing else, there is *nothing* else that I can think of that >>>>> meats the low tech standard and can be managed by more than one >>>>> person. >>>> I think "more than one person" does not mean "any random guy round the >>>> corner", it means "somebody else from the team, preferrably people who >>>> is already is charge of the website". >>> Now we know some of the goals it would be nice to learn about the people >>> already in charge, who are they and what do they know about languages >>> and frameworks? This would make it much more easy to recommend >>> something. I read that we have freebsd, perl and PHP so far... >> >> Oh, if you're into what we *have*, we also have python, django, >> postgresql (d'uh), mediawiki.. Ehh. I'm sure you can find a lot more. > > a _LOT_ more actually :-) Ah yes, what I wanted is more an overview what technologies are supportable, not what the zoo already has :-) (Sure one can conclude that what is there at the moment is at least somewhat supported :-) Cheers Tino
On Tuesday 30 December 2008 13:44:36 Alvaro Herrera wrote: > Joshua D. Drake wrote: > > And if nothing else, there is *nothing* else that I can think of that > > meats the low tech standard and can be managed by more than one person. > Didn't some of our south american cohorts just look into a web based translation system, which includes status outputs? -- Robert Treat Conjecture: http://www.xzilla.net Consulting: http://www.omniti.com
Peter Eisentraut a écrit : > > > Requirements are roughly: > > * Perfect and flawless table support is essential. The page > <http://pgtranslation.projects.postgresql.org/status.html> is pretty > much the core of the service, so it must work well. I currently create > HTML tables using a script and include them, but pretty much every > toolkit has problems in this area. I am not attached to the HTML > markup, however. > > * Low-tech, standard tools available through FreeBSD ports collection, > or whatever the sysadmins want to deal with. > > * PostgreSQL-themable. > > * Preferrably understandable and maintainable by more than one person. > > Recommendations would be greatly appreciated. > dokuwiki seems to be a good response to your requirements : * it's easy to install : http://www.dokuwiki.org/install:freebsd * it's easy to create custom themes : http://www.postgresql.fr * it's easy to maintain : http://www.linux.com/feature/138888 * the syntax is low-tech : http://www.dokuwiki.org/syntax * the HTML tables are clean : http://www.dokuwiki.org/syntax#tables For http://www.postgresql.fr, we've been using (i.e. "struggling with")Drupal for years. We had only two persons who fullyunderstood the website and were able to maintain and add content. Now that we have switched for dokuwiki, more people are involved in management of the website. The maintenance is just peace of cake ( upgrading, backups and ACL are fast and intuitive tasks ). Furthermore, dokuwiki is so easy to hack : you can make or adapt your own plugins... We have our own plugins for cosmetic and Single Sign-On If you want any help with it don't hesitate to ask. We can provide our PostgreSQL theme and plugins if you want to see how it works. -- damien clochard http://dalibo.org | http://dalibo.com
damien@dalibo.info wrote: > Peter Eisentraut a écrit : >> >> Requirements are roughly: >> >> * Perfect and flawless table support is essential. The page >> <http://pgtranslation.projects.postgresql.org/status.html> is pretty >> much the core of the service, so it must work well. I currently create >> HTML tables using a script and include them, but pretty much every >> toolkit has problems in this area. I am not attached to the HTML >> markup, however. >> >> * Low-tech, standard tools available through FreeBSD ports collection, >> or whatever the sysadmins want to deal with. >> >> * PostgreSQL-themable. >> >> * Preferrably understandable and maintainable by more than one person. >> >> Recommendations would be greatly appreciated. >> > > dokuwiki seems to be a good response to your requirements : > > * it's easy to install : http://www.dokuwiki.org/install:freebsd > * it's easy to create custom themes : http://www.postgresql.fr > * it's easy to maintain : http://www.linux.com/feature/138888 > * the syntax is low-tech : http://www.dokuwiki.org/syntax > * the HTML tables are clean : http://www.dokuwiki.org/syntax#tables > > For http://www.postgresql.fr, we've been using (i.e. "struggling with") > Drupal for years. We had only two persons who fully understood the > website and were able to maintain and add content. > > Now that we have switched for dokuwiki, more people are involved in > management of the website. The maintenance is just peace of cake ( > upgrading, backups and ACL are fast and intuitive tasks ). > > Furthermore, dokuwiki is so easy to hack : you can make or adapt your > own plugins... We have our own plugins for cosmetic and Single Sign-On > > If you want any help with it don't hesitate to ask. We can provide our > PostgreSQL theme and plugins if you want to see how it works. Either I'm missing the point, or a lot of other people are missing the point here. Does dokuwiki have any features for automatically pulling statistics from .po files in a cvs repository? If not, I don't see what the win is. This is *not* supposed to be a website where you edit pages, AFAIK... //Magnus
Magnus Hagander a écrit : > damien@dalibo.info wrote: >> Peter Eisentraut a écrit : >>> Requirements are roughly: >>> >>> * Perfect and flawless table support is essential. The page >>> <http://pgtranslation.projects.postgresql.org/status.html> is pretty >>> much the core of the service, so it must work well. I currently create >>> HTML tables using a script and include them, but pretty much every >>> toolkit has problems in this area. I am not attached to the HTML >>> markup, however. >>> >>> * Low-tech, standard tools available through FreeBSD ports collection, >>> or whatever the sysadmins want to deal with. >>> >>> * PostgreSQL-themable. >>> >>> * Preferrably understandable and maintainable by more than one person. >>> >>> Recommendations would be greatly appreciated. >>> >> dokuwiki seems to be a good response to your requirements : >> >> * it's easy to install : http://www.dokuwiki.org/install:freebsd >> * it's easy to create custom themes : http://www.postgresql.fr >> * it's easy to maintain : http://www.linux.com/feature/138888 >> * the syntax is low-tech : http://www.dokuwiki.org/syntax >> * the HTML tables are clean : http://www.dokuwiki.org/syntax#tables >> >> For http://www.postgresql.fr, we've been using (i.e. "struggling with") >> Drupal for years. We had only two persons who fully understood the >> website and were able to maintain and add content. >> >> Now that we have switched for dokuwiki, more people are involved in >> management of the website. The maintenance is just peace of cake ( >> upgrading, backups and ACL are fast and intuitive tasks ). >> >> Furthermore, dokuwiki is so easy to hack : you can make or adapt your >> own plugins... We have our own plugins for cosmetic and Single Sign-On >> >> If you want any help with it don't hesitate to ask. We can provide our >> PostgreSQL theme and plugins if you want to see how it works. > > Either I'm missing the point, or a lot of other people are missing the > point here. > > Does dokuwiki have any features for automatically pulling statistics > from .po files in a cvs repository? If not, I don't see what the win is. > This is *not* supposed to be a website where you edit pages, AFAIK... > I may be missing the point. I just gave a quick look at the status page ( http://pgtranslation.projects.postgresql.org/status.html ) Dokuwiki doesn't have a feature to analyse po files. My point is just that it would be easy to write a plugin that fetch a .po file, parse it and return some statistic. For instance, we can imagine a plugin that would count that number of msgid lines in a given .po files. This plugin will add a new ky word in the standard doku syntax and the line to analyse the german translation of the 8.2's initdb page could look like this : {{po>initdb 8.2 de}} This would grab the po-8.2-branch/initdb-de.po file and simply return the numeric value into the web page. Apart from this specific job, the other tasks needed to display the page can be left to dokuwiki. Things like HTML formating, CSS semantic, result caching, versioning, etc. are already provided by doku. Keeping with my example, let's say we want to create the 8.2 status table : http://pgtranslation.projects.postgresql.org/status.html#t8.2-branch The wiki syntax to generate the table would look like this : ^ ^ af ^ cs ^ de ^ |ecpg|{{po>ecpg 8.2 af}}|{{po>ecpg 8.2 cs}}|{{po>ecpg 8.2 de}}| |initdb|{{po>initdb 8.2 af}}|{{po>initdb 8.2 cs}}|{{po>initdb 8.2 de}}| |libpq|{{po>libpq 8.2 af}}|{{po>libpq 8.2 cs}}|{{po>libpq 8.2 de}}| and so on... i'm not saying this is the best way to do it. But it seems to me that with dokuwiki, you can concentrate on writing a few lines of php code that do the specific treatment you need and don't bother with the HTML ouput. Once again i might be totally out of context. If it's the case, i apologize for the noise and i won't bother you with dokuwiki again ;-) -- damien clochard http://dalibo.org | http://dalibo.com
On Friday 02 January 2009 07:55:47 Magnus Hagander wrote: > damien@dalibo.info wrote: > > Peter Eisentraut a écrit : > >> Requirements are roughly: > >> > >> * Perfect and flawless table support is essential. The page > >> <http://pgtranslation.projects.postgresql.org/status.html> is pretty > >> much the core of the service, so it must work well. I currently create > >> HTML tables using a script and include them, but pretty much every > >> toolkit has problems in this area. I am not attached to the HTML > >> markup, however. > >> > >> * Low-tech, standard tools available through FreeBSD ports collection, > >> or whatever the sysadmins want to deal with. > >> > >> * PostgreSQL-themable. > >> > >> * Preferrably understandable and maintainable by more than one person. > >> > >> Recommendations would be greatly appreciated. > > > > dokuwiki seems to be a good response to your requirements : > > > > * it's easy to install : http://www.dokuwiki.org/install:freebsd > > * it's easy to create custom themes : http://www.postgresql.fr > > * it's easy to maintain : http://www.linux.com/feature/138888 > > * the syntax is low-tech : http://www.dokuwiki.org/syntax > > * the HTML tables are clean : http://www.dokuwiki.org/syntax#tables > > > > For http://www.postgresql.fr, we've been using (i.e. "struggling with") > > Drupal for years. We had only two persons who fully understood the > > website and were able to maintain and add content. > > > > Now that we have switched for dokuwiki, more people are involved in > > management of the website. The maintenance is just peace of cake ( > > upgrading, backups and ACL are fast and intuitive tasks ). > > > > Furthermore, dokuwiki is so easy to hack : you can make or adapt your > > own plugins... We have our own plugins for cosmetic and Single Sign-On > > > > If you want any help with it don't hesitate to ask. We can provide our > > PostgreSQL theme and plugins if you want to see how it works. > > Either I'm missing the point, or a lot of other people are missing the > point here. > > Does dokuwiki have any features for automatically pulling statistics > from .po files in a cvs repository? If not, I don't see what the win is. > This is *not* supposed to be a website where you edit pages, AFAIK... > right... as i noted earier, we just had this discussion. Have the ES guys had any luck with pootle? does anyone know if it would work well for peter's needs? -- Robert Treat Conjecture: http://www.xzilla.net Consulting: http://www.omniti.com
damien@dalibo.info wrote: > Magnus Hagander a écrit : >> damien@dalibo.info wrote: >>> Peter Eisentraut a écrit : >>>> Requirements are roughly: >>>> >>>> * Perfect and flawless table support is essential. The page >>>> <http://pgtranslation.projects.postgresql.org/status.html> is pretty >>>> much the core of the service, so it must work well. I currently create >>>> HTML tables using a script and include them, but pretty much every >>>> toolkit has problems in this area. I am not attached to the HTML >>>> markup, however. >>>> >>>> * Low-tech, standard tools available through FreeBSD ports collection, >>>> or whatever the sysadmins want to deal with. >>>> >>>> * PostgreSQL-themable. >>>> >>>> * Preferrably understandable and maintainable by more than one person. >>>> >>>> Recommendations would be greatly appreciated. >>>> >>> dokuwiki seems to be a good response to your requirements : >>> >>> * it's easy to install : http://www.dokuwiki.org/install:freebsd >>> * it's easy to create custom themes : http://www.postgresql.fr >>> * it's easy to maintain : http://www.linux.com/feature/138888 >>> * the syntax is low-tech : http://www.dokuwiki.org/syntax >>> * the HTML tables are clean : http://www.dokuwiki.org/syntax#tables >>> >>> For http://www.postgresql.fr, we've been using (i.e. "struggling with") >>> Drupal for years. We had only two persons who fully understood the >>> website and were able to maintain and add content. >>> >>> Now that we have switched for dokuwiki, more people are involved in >>> management of the website. The maintenance is just peace of cake ( >>> upgrading, backups and ACL are fast and intuitive tasks ). >>> >>> Furthermore, dokuwiki is so easy to hack : you can make or adapt your >>> own plugins... We have our own plugins for cosmetic and Single Sign-On >>> >>> If you want any help with it don't hesitate to ask. We can provide our >>> PostgreSQL theme and plugins if you want to see how it works. >> Either I'm missing the point, or a lot of other people are missing the >> point here. >> >> Does dokuwiki have any features for automatically pulling statistics >> from .po files in a cvs repository? If not, I don't see what the win is. >> This is *not* supposed to be a website where you edit pages, AFAIK... >> > > I may be missing the point. I just gave a quick look at the status page > ( http://pgtranslation.projects.postgresql.org/status.html ) > > Dokuwiki doesn't have a feature to analyse po files. My point is just > that it would be easy to write a plugin that fetch a .po file, parse it > and return some statistic. > > For instance, we can imagine a plugin that would count that number of > msgid lines in a given .po files. This plugin will add a new ky word in > the standard doku syntax and the line to analyse the german translation > of the 8.2's initdb page could look like this : > > {{po>initdb 8.2 de}} > > This would grab the po-8.2-branch/initdb-de.po file and simply return > the numeric value into the web page. > > Apart from this specific job, the other tasks needed to display the page > can be left to dokuwiki. Things like HTML formating, CSS semantic, > result caching, versioning, etc. are already provided by doku. > > Keeping with my example, let's say we want to create the 8.2 status > table : http://pgtranslation.projects.postgresql.org/status.html#t8.2-branch > > The wiki syntax to generate the table would look like this : > > ^ ^ af ^ cs ^ de ^ > |ecpg|{{po>ecpg 8.2 af}}|{{po>ecpg 8.2 cs}}|{{po>ecpg 8.2 de}}| > |initdb|{{po>initdb 8.2 af}}|{{po>initdb 8.2 cs}}|{{po>initdb 8.2 de}}| > |libpq|{{po>libpq 8.2 af}}|{{po>libpq 8.2 cs}}|{{po>libpq 8.2 de}}| > > and so on... > > i'm not saying this is the best way to do it. But it seems to me that > with dokuwiki, you can concentrate on writing a few lines of php code > that do the specific treatment you need and don't bother with the HTML > ouput. I fail to see how this is a win over a single, well-define, *static webpage*. If we're having a script to generate it anyway.. All we need to do is merge peters script for getting statistics with one of the templating engines we're already using. > Once again i might be totally out of context. If it's the case, i > apologize for the noise and i won't bother you with dokuwiki again ;-) I'm sure you can find more reasons in the future :-) //Magnus
Robert Treat wrote: > right... as i noted earier, we just had this discussion. Have the ES guys had > any luck with pootle? does anyone know if it would work well for peter's > needs? I don't think Pootle is appropriate here. The only need here is to display a table with some numbers, and provide links to the PO files for a translator to download. Perhaps if we were interested in changing the translation workflow we could have some use for Pootle, but that's a different discussion. I tend to agree with Magnus -- something that easily generates a simple HTML page is more than enough. I don't necessarily disagree with Damien; maybe a script generating the dokuwiki syntax is OK for this, because it seems simpler to generate than full-blown HTML. But then it seems to me that a simple template-based approach on which one can tweak the HTML is more useful. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support