Re: [pgadmin-hackers] gitignore
On Fri, Sep 24, 2010 at 10:17, Guillaume Lelarge guilla...@lelarge.info wrote: I was reading pgsql-hackers this morning while waiting for my colleagues. There's an interesting thread on gitignore files. Right now, when you grab a git branch, bootstrap it, configure it and make it, git status shows a lot of uninteresting files. A .gitignore file would help to notice changed files. I've come with the file attached, but would like to get comments on this. Haven't looked at the contents of the file, but definitely +1 on the concept in genereal (probably not surprising, since I did the same thing for the postgresql repo :P) -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-hackers
[pgadmin-hackers] Documentation
Documentation for pgAdmin is really weak right now. Just to take an example, I don't know where a plugin file is described. The real question is how we do this. Right now, the documentation is a set of HTML files. Which is fine for some people and not for others. Kind of hard to get a consistent style. Kind of hard to get a good PDF and CHM file out of it. Not sure we really need these formats, I'm sure we want a consistent style. The only way to get all these options, AFAICT, is to use Docbook. SGML or XML. I have no problem working with Docbook, but I'm not sure everyone feels the same. I really prefer XML because of the toolset we can use (which seems, at least to me, in much better shape than the SGML one). Anyone has better ideas? -- Guillaume http://www.postgresql.fr http://dalibo.com -- Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-hackers
Re: [pgadmin-hackers] gitignore
Le 24/09/2010 10:21, Dave Page a écrit : On Fri, Sep 24, 2010 at 9:17 AM, Guillaume Lelarge guilla...@lelarge.info wrote: I was reading pgsql-hackers this morning while waiting for my colleagues. There's an interesting thread on gitignore files. Right now, when you grab a git branch, bootstrap it, configure it and make it, git status shows a lot of uninteresting files. A .gitignore file would help to notice changed files. I've come with the file attached, but would like to get comments on this. Sounds good. What about pgadmin/Debug and pgadmin/Release, to ignore the Windows build directories? I forgot about those, but you're right. I need to add them. -- Guillaume http://www.postgresql.fr http://dalibo.com -- Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-hackers
Re: [pgadmin-hackers] gitignore
+1 -- Thanks Regards, Ashesh Vashi EnterpriseDB INDIA: Enterprise Postgres Companyhttp://www.enterprisedb.com On Fri, Sep 24, 2010 at 1:53 PM, Magnus Hagander mag...@hagander.netwrote: On Fri, Sep 24, 2010 at 10:17, Guillaume Lelarge guilla...@lelarge.info wrote: I was reading pgsql-hackers this morning while waiting for my colleagues. There's an interesting thread on gitignore files. Right now, when you grab a git branch, bootstrap it, configure it and make it, git status shows a lot of uninteresting files. A .gitignore file would help to notice changed files. I've come with the file attached, but would like to get comments on this. Haven't looked at the contents of the file, but definitely +1 on the concept in genereal (probably not surprising, since I did the same thing for the postgresql repo :P) -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-hackers
Re: [pgadmin-hackers] gitignore
Le 24/09/2010 10:23, Magnus Hagander a écrit : On Fri, Sep 24, 2010 at 10:17, Guillaume Lelarge guilla...@lelarge.info wrote: I was reading pgsql-hackers this morning while waiting for my colleagues. There's an interesting thread on gitignore files. Right now, when you grab a git branch, bootstrap it, configure it and make it, git status shows a lot of uninteresting files. A .gitignore file would help to notice changed files. I've come with the file attached, but would like to get comments on this. Haven't looked at the contents of the file, but definitely +1 on the concept in genereal (probably not surprising, since I did the same thing for the postgresql repo :P) Yeah, I took a look at the mail where you show all the changes done, and I worked from this. I have one question about it. There is many .gitignore files. Why not a single one? what are the advantages of the multi-file way? -- Guillaume http://www.postgresql.fr http://dalibo.com -- Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-hackers
Re: [pgadmin-hackers] gitignore
Le 24/09/2010 10:31, Guillaume Lelarge a écrit : Le 24/09/2010 10:21, Dave Page a écrit : On Fri, Sep 24, 2010 at 9:17 AM, Guillaume Lelarge guilla...@lelarge.info wrote: I was reading pgsql-hackers this morning while waiting for my colleagues. There's an interesting thread on gitignore files. Right now, when you grab a git branch, bootstrap it, configure it and make it, git status shows a lot of uninteresting files. A .gitignore file would help to notice changed files. I've come with the file attached, but would like to get comments on this. Sounds good. What about pgadmin/Debug and pgadmin/Release, to ignore the Windows build directories? I forgot about those, but you're right. I need to add them. And I forgot to ask. Which branches? I was thinking of master (obviously), 1.12, and 1.10 (since Dave still works on it for EDB). Objection? -- Guillaume http://www.postgresql.fr http://dalibo.com -- Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-hackers
Re: [pgadmin-hackers] gitignore
On Fri, Sep 24, 2010 at 10:34, Guillaume Lelarge guilla...@lelarge.info wrote: Le 24/09/2010 10:23, Magnus Hagander a écrit : On Fri, Sep 24, 2010 at 10:17, Guillaume Lelarge guilla...@lelarge.info wrote: I was reading pgsql-hackers this morning while waiting for my colleagues. There's an interesting thread on gitignore files. Right now, when you grab a git branch, bootstrap it, configure it and make it, git status shows a lot of uninteresting files. A .gitignore file would help to notice changed files. I've come with the file attached, but would like to get comments on this. Haven't looked at the contents of the file, but definitely +1 on the concept in genereal (probably not surprising, since I did the same thing for the postgresql repo :P) Yeah, I took a look at the mail where you show all the changes done, and I worked from this. I have one question about it. There is many .gitignore files. Why not a single one? what are the advantages of the multi-file way? That you'll always find the local targets in the directory you're currently working, and when you need to add a new one, you do it next to the file where it was done. That was actually discussed in the thread on -hackers :P -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-hackers
Re: [pgadmin-hackers] Documentation
On Fri, Sep 24, 2010 at 10:29, Guillaume Lelarge guilla...@lelarge.info wrote: Documentation for pgAdmin is really weak right now. Just to take an example, I don't know where a plugin file is described. The real question is how we do this. Right now, the documentation is a set of HTML files. Which is fine for some people and not for others. Kind of hard to get a consistent style. Kind of hard to get a good PDF and CHM file out of it. Not sure we really need these formats, I'm sure we want a consistent style. The only way to get all these options, AFAICT, is to use Docbook. SGML or XML. I have no problem working with Docbook, but I'm not sure everyone feels the same. I really prefer XML because of the toolset we can use (which seems, at least to me, in much better shape than the SGML one). Anyone has better ideas? I've chatted with Dave about this a couple of times lately. at the time I suggested using RST and sphinx (http://sphinx.pocoo.org/). I think this is a much nicer thing to work with than docbook. It might not scale to as complex documentation (I'm not sure I'd like to see the pg docs redone in it), but the pgadmin docs aren't that complex - and probably shouldn't be. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-hackers
Re: [pgadmin-hackers] Documentation
On Fri, Sep 24, 2010 at 9:29 AM, Guillaume Lelarge guilla...@lelarge.info wrote: Documentation for pgAdmin is really weak right now. Just to take an example, I don't know where a plugin file is described. The real question is how we do this. Right now, the documentation is a set of HTML files. Which is fine for some people and not for others. Kind of hard to get a consistent style. Kind of hard to get a good PDF and CHM file out of it. Not sure we really need these formats, I'm sure we want a consistent style. The only way to get all these options, AFAICT, is to use Docbook. SGML or XML. I have no problem working with Docbook, but I'm not sure everyone feels the same. I really prefer XML because of the toolset we can use (which seems, at least to me, in much better shape than the SGML one). Anyone has better ideas? Yeah, I was looking at this the other day, but ran out of time. Looking at using Sphinx (http://sphinx.pocoo.org/). I really don't want to use SGML or XML. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-hackers
Re: [pgadmin-hackers] gitignore
Le 24/09/2010 10:36, Magnus Hagander a écrit : On Fri, Sep 24, 2010 at 10:34, Guillaume Lelarge guilla...@lelarge.info wrote: Le 24/09/2010 10:23, Magnus Hagander a écrit : On Fri, Sep 24, 2010 at 10:17, Guillaume Lelarge guilla...@lelarge.info wrote: I was reading pgsql-hackers this morning while waiting for my colleagues. There's an interesting thread on gitignore files. Right now, when you grab a git branch, bootstrap it, configure it and make it, git status shows a lot of uninteresting files. A .gitignore file would help to notice changed files. I've come with the file attached, but would like to get comments on this. Haven't looked at the contents of the file, but definitely +1 on the concept in genereal (probably not surprising, since I did the same thing for the postgresql repo :P) Yeah, I took a look at the mail where you show all the changes done, and I worked from this. I have one question about it. There is many .gitignore files. Why not a single one? what are the advantages of the multi-file way? That you'll always find the local targets in the directory you're currently working, and when you need to add a new one, you do it next to the file where it was done. OK, should we do that? It would be really easy to do. That was actually discussed in the thread on -hackers :P Didn't remember that. -- Guillaume http://www.postgresql.fr http://dalibo.com -- Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-hackers
Re: [pgadmin-hackers] Documentation
Le 24/09/2010 10:39, Dave Page a écrit : On Fri, Sep 24, 2010 at 9:29 AM, Guillaume Lelarge guilla...@lelarge.info wrote: Documentation for pgAdmin is really weak right now. Just to take an example, I don't know where a plugin file is described. The real question is how we do this. Right now, the documentation is a set of HTML files. Which is fine for some people and not for others. Kind of hard to get a consistent style. Kind of hard to get a good PDF and CHM file out of it. Not sure we really need these formats, I'm sure we want a consistent style. The only way to get all these options, AFAICT, is to use Docbook. SGML or XML. I have no problem working with Docbook, but I'm not sure everyone feels the same. I really prefer XML because of the toolset we can use (which seems, at least to me, in much better shape than the SGML one). Anyone has better ideas? Yeah, I was looking at this the other day, but ran out of time. Looking at using Sphinx (http://sphinx.pocoo.org/). Seems interesting. Just at the same time, we (Dalibo) get rid of our documents in ReST format, so I'll still have to work with it for pgadmin :-/ Anyway, I need to test it a bit before going further on this. I really don't want to use SGML or XML. I supposed so :) -- Guillaume http://www.postgresql.fr http://dalibo.com -- Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-hackers
Re: [pgadmin-hackers] Documentation
On Fri, Sep 24, 2010 at 11:16, Guillaume Lelarge guilla...@lelarge.info wrote: Le 24/09/2010 10:39, Dave Page a écrit : On Fri, Sep 24, 2010 at 9:29 AM, Guillaume Lelarge guilla...@lelarge.info wrote: Documentation for pgAdmin is really weak right now. Just to take an example, I don't know where a plugin file is described. The real question is how we do this. Right now, the documentation is a set of HTML files. Which is fine for some people and not for others. Kind of hard to get a consistent style. Kind of hard to get a good PDF and CHM file out of it. Not sure we really need these formats, I'm sure we want a consistent style. The only way to get all these options, AFAICT, is to use Docbook. SGML or XML. I have no problem working with Docbook, but I'm not sure everyone feels the same. I really prefer XML because of the toolset we can use (which seems, at least to me, in much better shape than the SGML one). Anyone has better ideas? Yeah, I was looking at this the other day, but ran out of time. Looking at using Sphinx (http://sphinx.pocoo.org/). Seems interesting. Just at the same time, we (Dalibo) get rid of our documents in ReST format, so I'll still have to work with it for pgadmin :-/ Why do you get rid of ReST, and what are you changing to? -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-hackers
Re: [pgadmin-hackers] Documentation
Le 24/09/2010 11:59, Magnus Hagander a écrit : On Fri, Sep 24, 2010 at 11:16, Guillaume Lelarge guilla...@lelarge.info wrote: Le 24/09/2010 10:39, Dave Page a écrit : On Fri, Sep 24, 2010 at 9:29 AM, Guillaume Lelarge guilla...@lelarge.info wrote: Documentation for pgAdmin is really weak right now. Just to take an example, I don't know where a plugin file is described. The real question is how we do this. Right now, the documentation is a set of HTML files. Which is fine for some people and not for others. Kind of hard to get a consistent style. Kind of hard to get a good PDF and CHM file out of it. Not sure we really need these formats, I'm sure we want a consistent style. The only way to get all these options, AFAICT, is to use Docbook. SGML or XML. I have no problem working with Docbook, but I'm not sure everyone feels the same. I really prefer XML because of the toolset we can use (which seems, at least to me, in much better shape than the SGML one). Anyone has better ideas? Yeah, I was looking at this the other day, but ran out of time. Looking at using Sphinx (http://sphinx.pocoo.org/). Seems interesting. Just at the same time, we (Dalibo) get rid of our documents in ReST format, so I'll still have to work with it for pgadmin :-/ Why do you get rid of ReST, and what are you changing to? Not really because of ReST. Our real issue was the tool we used to build HTML, PDF, etc. This tool was first written by dalibo, but nobody really maintains it and it became more and more difficult to install it on recent laptops. So, as you can see, not really an issue with ReST. And we are changing to... dokuwiki. You surely know Damien felt in love with this tool :) -- Guillaume http://www.postgresql.fr http://dalibo.com -- Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-hackers
Re: [pgadmin-hackers] Documentation
Le 24/09/2010 12:06, Marek Černocký a écrit : It would be nice to choice format the gettext (or similar tool) know about. It's very difficult to track changes in the current documentation for translators. Gettext really doesn't work for documentation. It's much harder to know the context of each sentence. I'm translating the PostgreSQL manuel since 7.4.7 IIRC, and I'm completely against using a .po toolchain for the french translation. It could help to make it quicker and simpler to update, but it would quickly degrade the quality of the translation. Of course, this is only my opinion, and I know some that don't agree with me on this. -- Guillaume http://www.postgresql.fr http://dalibo.com -- Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-hackers
Re: [pgadmin-hackers] Documentation
On Fri, Sep 24, 2010 at 11:13 AM, Guillaume Lelarge guilla...@lelarge.info wrote: Not really because of ReST. Our real issue was the tool we used to build HTML, PDF, etc. This tool was first written by dalibo, but nobody really maintains it and it became more and more difficult to install it on recent laptops. So, as you can see, not really an issue with ReST. And we are changing to... dokuwiki. You surely know Damien felt in love with this tool :) I know you're not suggesting it, but just so we're clear - the day pgAdmin starts to use docuwiki is the day that Microsoft release a Linux distro, Apple BSD licence all their code, pigs around the world spontaneously sprout wings and world peace is declared. When all those things happen at once, I'll gladly install docuwiki. :-p -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-hackers
Re: [pgadmin-hackers] Documentation
On Fri, Sep 24, 2010 at 12:23, Dave Page dp...@pgadmin.org wrote: On Fri, Sep 24, 2010 at 11:13 AM, Guillaume Lelarge guilla...@lelarge.info wrote: Not really because of ReST. Our real issue was the tool we used to build HTML, PDF, etc. This tool was first written by dalibo, but nobody really maintains it and it became more and more difficult to install it on recent laptops. So, as you can see, not really an issue with ReST. And we are changing to... dokuwiki. You surely know Damien felt in love with this tool :) I know you're not suggesting it, but just so we're clear - the day pgAdmin starts to use docuwiki is the day that Microsoft release a Linux distro, Apple BSD licence all their code, pigs around the world spontaneously sprout wings and world peace is declared. When all those things happen at once, I'll gladly install docuwiki. I think we should also require steve jobs to wear a suit during a presentation. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-hackers
Re: [pgadmin-hackers] Documentation
On Fri, Sep 24, 2010 at 12:16 PM, Magnus Hagander mag...@hagander.net wrote: I know you're not suggesting it, but just so we're clear - the day pgAdmin starts to use docuwiki is the day that Microsoft release a Linux distro, Apple BSD licence all their code, pigs around the world spontaneously sprout wings and world peace is declared. When all those things happen at once, I'll gladly install docuwiki. I think we should also require steve jobs to wear a suit during a presentation. Well that just sets the barrier ridiculously high. There's no need to go over the top. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-hackers
Re: [pgadmin-hackers] Documentation
I comprehend your concern for quality. But now I have no clear info about documentation changes. I would have to study git changelogs or do other frustration work. It has impact on documentation translation completeness and quality too. I translate Gnome (which uses own tools for work with documentation po/pot) and I don't see any problem with quality. Documentation translator is usually the same as UI translator so he has knowledge about application. I thing the limit to translation quality is translator at first, using .po is the matter in question. Guillaume Lelarge píše v Pá 24. 09. 2010 v 12:22 +0200: Le 24/09/2010 12:06, Marek Černocký a écrit : It would be nice to choice format the gettext (or similar tool) know about. It's very difficult to track changes in the current documentation for translators. Gettext really doesn't work for documentation. It's much harder to know the context of each sentence. I'm translating the PostgreSQL manuel since 7.4.7 IIRC, and I'm completely against using a .po toolchain for the french translation. It could help to make it quicker and simpler to update, but it would quickly degrade the quality of the translation. Of course, this is only my opinion, and I know some that don't agree with me on this. -- Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-hackers
Re: [pgadmin-hackers] pgAdmin III commit: Branch refs/heads/mybugfixwork was created
Le 23/09/2010 22:47, Magnus Hagander a écrit : On Thu, Sep 23, 2010 at 22:20, Guillaume Lelarge guilla...@lelarge.info wrote: Le 23/09/2010 22:12, g...@pgadmin.org a écrit : [...] the repo. I just pushed a branch there. I deleted it, so I don't think it's really that bad. Magnus, any idea on this? a git push origin :mybugfixwork should be enough, right? /me hopes no one had the time to grab it. Yeah, that should be enough. If somebody has cloned it meanwhile, they'll just have to undo it themselves. For example, I just removed it from the github mirror ;) It's still there on github. How did you remove it? -- Guillaume http://www.postgresql.fr http://dalibo.com -- Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-hackers
Re: [pgadmin-hackers] pgAdmin III commit: Branch refs/heads/mybugfixwork was created
On Fri, Sep 24, 2010 at 15:40, Guillaume Lelarge guilla...@lelarge.info wrote: Le 23/09/2010 22:47, Magnus Hagander a écrit : On Thu, Sep 23, 2010 at 22:20, Guillaume Lelarge guilla...@lelarge.info wrote: Le 23/09/2010 22:12, g...@pgadmin.org a écrit : [...] the repo. I just pushed a branch there. I deleted it, so I don't think it's really that bad. Magnus, any idea on this? a git push origin :mybugfixwork should be enough, right? /me hopes no one had the time to grab it. Yeah, that should be enough. If somebody has cloned it meanwhile, they'll just have to undo it themselves. For example, I just removed it from the github mirror ;) It's still there on github. How did you remove it? It's not. It's cached on the web there somehow, but it's not in the git repo. At least it wasn't last night (not in a position to check right now). I just pushed it with : at the start to the repo. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-hackers
Re: [pgadmin-hackers] Documentation
Le 24/09/2010 15:16, Marek Černocký a écrit : I comprehend your concern for quality. But now I have no clear info about documentation changes. I would have to study git changelogs or do other frustration work. It has impact on documentation translation completeness and quality too. You just need this command: git diff REL-1_10_0_PATCHES -- docs/en_US Which gives you 439 lines of changes (many are from binary files). With this, you easily know changes on the documentation. I translate Gnome (which uses own tools for work with documentation po/pot) and I don't see any problem with quality. Documentation translator is usually the same as UI translator so he has knowledge about application. Problem is not knowledge on the software. Translating a UI is a complete different business than translating a documentation. There's not really a context when you translate a UI, but there is one when you translate a manual. I thing the limit to translation quality is translator at first, using .po is the matter in question. Anyway, there are tools that helps you to build .po files from various text formats. po4a for example. -- Guillaume http://www.postgresql.fr http://dalibo.com -- Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-hackers
Re: [pgadmin-hackers] pgAdmin III commit: Branch refs/heads/mybugfixwork was created
Le 24/09/2010 15:44, Magnus Hagander a écrit : On Fri, Sep 24, 2010 at 15:40, Guillaume Lelarge guilla...@lelarge.info wrote: Le 23/09/2010 22:47, Magnus Hagander a écrit : On Thu, Sep 23, 2010 at 22:20, Guillaume Lelarge guilla...@lelarge.info wrote: Le 23/09/2010 22:12, g...@pgadmin.org a écrit : [...] the repo. I just pushed a branch there. I deleted it, so I don't think it's really that bad. Magnus, any idea on this? a git push origin :mybugfixwork should be enough, right? /me hopes no one had the time to grab it. Yeah, that should be enough. If somebody has cloned it meanwhile, they'll just have to undo it themselves. For example, I just removed it from the github mirror ;) It's still there on github. How did you remove it? It's not. It's cached on the web there somehow, but it's not in the git repo. At least it wasn't last night (not in a position to check right now). I just pushed it with : at the start to the repo. OK. I'll check a bit later. -- Guillaume http://www.postgresql.fr http://dalibo.com -- Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-hackers
Re: [pgadmin-hackers] Documentation
Guillaume Lelarge píše v Pá 24. 09. 2010 v 16:20 +0200: Le 24/09/2010 15:16, Marek Černocký a écrit : I comprehend your concern for quality. But now I have no clear info about documentation changes. I would have to study git changelogs or do other frustration work. It has impact on documentation translation completeness and quality too. You just need this command: git diff REL-1_10_0_PATCHES -- docs/en_US Which gives you 439 lines of changes (many are from binary files). With this, you easily know changes on the documentation. I translate Gnome (which uses own tools for work with documentation po/pot) and I don't see any problem with quality. Documentation translator is usually the same as UI translator so he has knowledge about application. Problem is not knowledge on the software. Translating a UI is a complete different business than translating a documentation. There's not really a context when you translate a UI, but there is one when you translate a manual. Messages in .po file are sorted sequentially much like original document. And messages are full sentences or even paragraphs. Context you see directly. Documentation translation is exacting only for its length. Translating UI si difficult because you see isolated words or snippets and you must search context in application. I thing the limit to translation quality is translator at first, using .po is the matter in question. Anyway, there are tools that helps you to build .po files from various text formats. po4a for example. -- Guillaume http://www.postgresql.fr http://dalibo.com -- Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-hackers
[pgadmin-hackers] pgAdmin III commit: Add .gitignore files.
Add .gitignore files. Branch -- REL-1_12_0_PATCHES Details --- http://git.postgresql.org/gitweb?p=pgadmin3.git;a=commitdiff;h=d7b1bd697b5faea355ce6a3f7476045cbc4cf807 Modified Files -- .gitignore| 14 ++ pgadmin/.gitignore|5 + pgadmin/include/.gitignore|2 ++ pkg/mac/.gitignore|3 +++ pkg/mandrake/.gitignore |2 ++ pkg/redhat/.gitignore |2 ++ pkg/slackware/.gitignore |2 ++ pkg/src/.gitignore|2 ++ pkg/suse/.gitignore |2 ++ xtra/pgscript/bin/.gitignore |2 ++ xtra/pgscript/lib/.gitignore |2 ++ xtra/pgscript/test/.gitignore |2 ++ 12 files changed, 40 insertions(+), 0 deletions(-) -- Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-hackers
[pgadmin-hackers] pgAdmin III commit: Add .gitignore files.
Add .gitignore files. Branch -- master Details --- http://git.postgresql.org/gitweb?p=pgadmin3.git;a=commitdiff;h=f1ed23412a79fabb55b81c01a31a012485725d4e Modified Files -- .gitignore| 14 ++ pgadmin/.gitignore|5 + pgadmin/include/.gitignore|2 ++ pkg/mac/.gitignore|3 +++ pkg/mandrake/.gitignore |2 ++ pkg/redhat/.gitignore |2 ++ pkg/slackware/.gitignore |2 ++ pkg/src/.gitignore|2 ++ pkg/suse/.gitignore |2 ++ xtra/pgscript/bin/.gitignore |2 ++ xtra/pgscript/lib/.gitignore |2 ++ xtra/pgscript/test/.gitignore |2 ++ 12 files changed, 40 insertions(+), 0 deletions(-) -- Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-hackers
[pgadmin-hackers] pgAdmin III commit: Add .gitignore files.
Add .gitignore files. Branch -- REL-1_10_0_PATCHES Details --- http://git.postgresql.org/gitweb?p=pgadmin3.git;a=commitdiff;h=5ff2f1096d3018dcc4b8e3275d90bf660531e641 Modified Files -- .gitignore| 14 ++ pgadmin/.gitignore|5 + pgadmin/include/.gitignore|2 ++ pkg/mac/.gitignore|3 +++ pkg/mandrake/.gitignore |2 ++ pkg/redhat/.gitignore |2 ++ pkg/slackware/.gitignore |2 ++ pkg/src/.gitignore|2 ++ pkg/suse/.gitignore |2 ++ xtra/pgscript/bin/.gitignore |2 ++ xtra/pgscript/lib/.gitignore |2 ++ xtra/pgscript/test/.gitignore |2 ++ 12 files changed, 40 insertions(+), 0 deletions(-) -- Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-hackers
[pgadmin-hackers] [pgAdmin III] #240: Trigger Display Bugs in 1.12 pgAdmin
#240: Trigger Display Bugs in 1.12 pgAdmin -+-- Reporter: Christopher A Hotchkiss | Owner: gleu Type: bug | Status: new Priority: minor| Milestone: Component: pgadmin | Version: 1.12 Keywords: browser |Platform: all -+-- I am using the new 1.12 pgAdmin on Windows XP SP3 and I have notice two display inaccuracies when connecting to a Postgres 9 database. For example when creating the following trigger: CREATE TRIGGER c_aud_trg BEFORE INSERT OR UPDATE OR DELETE ON ca FOR EACH ROW EXECUTE PROCEDURE c_aud_trg_trfunc(); It will get created correctly (checking with pgdump based on suggestions from the pgsql list). However it will be displayed as: CREATE TRIGGER c_aud_trg BEFORE INSERT OR UPDATE ON ca FOR EACH ROW EXECUTE PROCEDURE c_aud_trg_func(E'\\x'); If that same trigger is dropped and re-added using what is in the database, the following shows up: CREATE TRIGGER c_aud_trg BEFORE INSERT OR UPDATE ON ca FOR EACH ROW EXECUTE PROCEDURE c_aud_trg_func(E'\\x5c7800'); The second issue is the ordering of 'update of' triggers. For example when creating the following trigger: CREATE TRIGGER ca_trig BEFORE UPDATE OF columnA OR DELETE ON ca FOR EACH ROW EXECUTE PROCEDURE c_h_trg_func (); It will be displayed as: CREATE TRIGGER ca_trig BEFORE UPDATE OR DELETE OF columnA ON ca FOR EACH ROW EXECUTE PROCEDURE c_h_trg_func (); This is a syntax error. -- Ticket URL: http://code.pgadmin.org/trac/ticket/240 pgAdmin III http://code.pgadmin.org/trac/ pgAdmin III -- Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-hackers
