8:34 a.m.
Hello,
here are some doubts / little things I've found while messing around with
the code:
When adding a new module, one should add the module itself, the tests
about it, modify the test 1 to verify the new module's syntax, and modify
the chooser module to show the new module as available. It would be nice
if those last two things could be automatic. For example adding a new
function on each module that returns its description and a boolean that
tells if it's active or experimental (well, I'm sure you'll find better
ways for doing this :P).
This way, the test1 could test all the active (non-experimental) modules,
and the chooser could get the list of all available modules and their
descriptions without modifying them. This could also enhance the
translation of the list of available formats, because now, each time a new
module appears, the chooser string is modified, and translators have to
translate almost everything again.
(Should I send it as a feature request to alioth?)
The Chooser.pm file header talks about the Pod module and not about
himself. It's only an aesthetic issue :P (I haven't watched the other
modules)
I haven't been able to find the main po4a man page, although most of the
other man pages refer to it. Does it exist? Isn't it installed along with
the other ones?
It seems that t/10-data is the same as t/data-10. Could one of them go
away?
Another possible feature request: would it be so difficult to get the
master document (when gettextizing, or translating...) from stdin? This
way, for example as the Dia diagrams are normaly compressed, one could do
something like:
gunzip < document.dia | po4a-translate...
And now some personal questions: Is there any way to test the modules
while developing them without doing a make install? I didn't achieve it.
And the last one (for now): How could I see the po4a program translations
in action? (I refer to the french one in the CVS and the spanish I'm
doing). I've tried something like
LANG=fr po4a-gettextize
and things like that, but all appears in english, like before. What am I
missing?
That's all. Thanks in advance for your attention. (I hope not to be a pain
with all these things ;)
Regards,
Jordi Vilalta
2:22 p.m.
On Sat, May 22, 2004 at 03:34:28PM +0200, Jordi Vilalta wrote:
Hello,
here are some doubts / little things I've found while messing around with
the code:
When adding a new module, one should add the module itself, the tests
about it, modify the test 1 to verify the new module's syntax, and modify
the chooser module to show the new module as available. It would be nice
if those last two things could be automatic. For example adding a new
function on each module that returns its description and a boolean that
tells if it's active or experimental (well, I'm sure you'll find better
ways for doing this :P).
This way, the test1 could test all the active (non-experimental) modules,
and the chooser could get the list of all available modules and their
descriptions without modifying them. This could also enhance the
translation of the list of available formats, because now, each time a new
module appears, the chooser string is modified, and translators have to
translate almost everything again.
(Should I send it as a feature request to alioth?)
The chooser already act as an autoloader. And there is not that much
modules, I prefer to keep the control on the module order in the listing,
for example. Moreover, this solution would not be possible for man pages,
debian package description and so on. I prefer to keep everything manual.
The Chooser.pm file header talks about the Pod module and not about
himself. It's only an aesthetic issue :P (I haven't watched the other
modules)
I haven't been able to find the main po4a man page, although most of the
other man pages refer to it. Does it exist? Isn't it installed along with
the other ones?
man 7 po4a
pod2man doc/po4a.7.pod
It seems that t/10-data is the same as t/data-10. Could one of them
go
away?
Done.
Another possible feature request: would it be so difficult to get the
master document (when gettextizing, or translating...) from stdin? This
way, for example as the Dia diagrams are normaly compressed, one could do
something like:
gunzip < document.dia | po4a-translate...
Well, I seem to remember that Denis said it will be difficult to do with
encodings. I don't really remember.
I could also add a -z option to gunzip files before opening.
And now some personal questions: Is there any way to test the modules
while developing them without doing a make install? I didn't achieve it.
I added this to README:
USE WITHOUT INSTALLATION
If you want to use a version without installing it (such as the CVS one),
use the PERLLIB environment variable is such construction:
PERLLIB=~/CVSIMPORT/po4a/lib ~/CVSIMPORT/po4a/po4a-gettextize [usual args]
And the last one (for now): How could I see the po4a program
translations
in action? (I refer to the french one in the CVS and the spanish I'm
doing). I've tried something like
LANG=fr po4a-gettextize
and things like that, but all appears in english, like before. What am I
missing?
It depends on the way you installed it. I get it in french...
That's all. Thanks in advance for your attention. (I hope not to
be a pain
with all these things ;)
Nope, I love feedback.
Please try version 0.16 and report any problems you find.
Bye, Mt.
--
Le monde est dangereux à vivre! Non pas tant à cause de ceux qui font le
mal, mais à cause de ceux qui regardent et laissent faire.
-- Albert Einstein
8:53 a.m.
On Tue, 25 May 2004, Martin Quinson wrote:
On Sat, May 22, 2004 at 03:34:28PM +0200, Jordi Vilalta wrote:
[...]
> I haven't been able to find the main po4a man page, although most of the
> other man pages refer to it. Does it exist? Isn't it installed along with
> the other ones?
man 7 po4a
pod2man doc/po4a.7.pod
Yes, I can build it manually, but it isn't built nor installed
automaticaly with make (I think it should).
> Another possible feature request: would it be so difficult to
get the
> master document (when gettextizing, or translating...) from stdin? This
> way, for example as the Dia diagrams are normaly compressed, one could do
> something like:
> gunzip < document.dia | po4a-translate...
Well, I seem to remember that Denis said it will be difficult to do with
encodings. I don't really remember.
I could also add a -z option to gunzip files before opening.
I think we don't need it. The gunzipping is only needed by a particular
type of documents. Others will need other treatments. It would be nice to
send po4a a document by stdin, enabling any treatment with pipes, but if
it's difficult, I think it's important to mantain it simple.
> And now some personal questions: Is there any way to test the modules
> while developing them without doing a make install? I didn't achieve it.
I added this to README:
USE WITHOUT INSTALLATION
If you want to use a version without installing it (such as the CVS one),
use the PERLLIB environment variable is such construction:
PERLLIB=~/CVSIMPORT/po4a/lib ~/CVSIMPORT/po4a/po4a-gettextize [usual args]
Thanks! It's very useful.
> And the last one (for now): How could I see the po4a program translations
> in action? (I refer to the french one in the CVS and the spanish I'm
> doing). I've tried something like
> LANG=fr po4a-gettextize
> and things like that, but all appears in english, like before. What am I
> missing?
It depends on the way you installed it. I get it in french...
I've been looking it, and I saw that translations are not automaticaly
installed. I tried with:
make -C po install
and after upgrading gettext to 0.13, it seems now the po/bin/*.po catalogs
are installed. In spite of this, I can't get any translated message at
runtime.
The translations in po/pod/*.po aren't currently used to generate any
final file (as translated man's), are they?
While messing with the translations, I've updated po/bin/es.po (diff
attached).
Regards,
Jordi Vilalta
12:33 p.m.
On Wed, May 26, 2004 at 03:53:28PM +0200, Jordi Vilalta wrote:
On Tue, 25 May 2004, Martin Quinson wrote:
> On Sat, May 22, 2004 at 03:34:28PM +0200, Jordi Vilalta wrote:
> [...]
> > I haven't been able to find the main po4a man page, although most of the
> > other man pages refer to it. Does it exist? Isn't it installed along with
> > the other ones?
>
> man 7 po4a
> pod2man doc/po4a.7.pod
Yes, I can build it manually, but it isn't built nor installed
automaticaly with make (I think it should).
Yeah, the debian package does install it, but I didn't found how to add some
extra rules to the Makefile.PL. If anybody knows how to do so, it'd be cool.
> > Another possible feature request: would it be so difficult
to get the
> > master document (when gettextizing, or translating...) from stdin? This
> > way, for example as the Dia diagrams are normaly compressed, one could do
> > something like:
> > gunzip < document.dia | po4a-translate...
>
> Well, I seem to remember that Denis said it will be difficult to do with
> encodings. I don't really remember.
>
> I could also add a -z option to gunzip files before opening.
I think we don't need it. The gunzipping is only needed by a particular
type of documents. Others will need other treatments. It would be nice to
send po4a a document by stdin, enabling any treatment with pipes, but if
it's difficult, I think it's important to mantain it simple.
>
> > And the last one (for now): How could I see the po4a program translations
> > in action? (I refer to the french one in the CVS and the spanish I'm
> > doing). I've tried something like
> > LANG=fr po4a-gettextize
> > and things like that, but all appears in english, like before. What am I
> > missing?
>
> It depends on the way you installed it. I get it in french...
I've been looking it, and I saw that translations are not automaticaly
installed. I tried with:
make -C po install
and after upgrading gettext to 0.13, it seems now the po/bin/*.po catalogs
are installed.
How, the lack of sub-directory recursion in this stupid Makefile.PL again.
Sorry, I'm puzzeled.
In spite of this, I can't get any translated message at runtime.
ls /usr/share/locale/es/LC_MESSAGES/po4a.mo ?
I suspect the same kind of problem than above. Couldn't you try to install
the debian package? I though gentoo was based on debian anyhow...
The translations in po/pod/*.po aren't currently used to generate
any
final file (as translated man's), are they?
The translated man page generation takes place during the debian package
compilation. This is wrong again.
While messing with the translations, I've updated po/bin/es.po
(diff
attached).
Commited.
Bye, Mt.
--
Le sens commun n'est pas si commun.
-- Voltaire
[Common sense is not so common]
5:16 a.m.
Hi,
On Wed, 26 May 2004, Martin Quinson wrote:
On Wed, May 26, 2004 at 03:53:28PM +0200, Jordi Vilalta wrote:
> On Tue, 25 May 2004, Martin Quinson wrote:
> > On Sat, May 22, 2004 at 03:34:28PM +0200, Jordi Vilalta wrote:
> > [...]
> > > I haven't been able to find the main po4a man page, although most of
the
> > > other man pages refer to it. Does it exist? Isn't it installed along
with
> > > the other ones?
> >
> > man 7 po4a
> > pod2man doc/po4a.7.pod
>
> Yes, I can build it manually, but it isn't built nor installed
> automaticaly with make (I think it should).
Yeah, the debian package does install it, but I didn't found how to add some
extra rules to the Makefile.PL. If anybody knows how to do so, it'd be cool.
[..]
> >
> > > And the last one (for now): How could I see the po4a program translations
> > > in action? (I refer to the french one in the CVS and the spanish I'm
> > > doing). I've tried something like
> > > LANG=fr po4a-gettextize
> > > and things like that, but all appears in english, like before. What am I
> > > missing?
> >
> > It depends on the way you installed it. I get it in french...
>
> I've been looking it, and I saw that translations are not automaticaly
> installed. I tried with:
> make -C po install
> and after upgrading gettext to 0.13, it seems now the po/bin/*.po catalogs
> are installed.
How, the lack of sub-directory recursion in this stupid Makefile.PL again.
Sorry, I'm puzzeled.
> In spite of this, I can't get any translated message at runtime.
ls /usr/share/locale/es/LC_MESSAGES/po4a.mo ?
I suspect the same kind of problem than above. Couldn't you try to install
the debian package? I though gentoo was based on debian anyhow...
Yes, po4a.mo is there, and... it works (for french, spanish and catalan :)
It was my fault. I only watched to the help messages:
Usage:
po4a-gettextize -f <format> -m <master.doc> [-l <localized.doc>] -p
<translation.po>
Options:
...
This is already in english, but the module specific messages appears
translated :)
> The translations in po/pod/*.po aren't currently used to generate any
> final file (as translated man's), are they?
The translated man page generation takes place during the debian package
compilation. This is wrong again.
About these other issues (translating and installing manpages, and
treating the po directory) I've been watching for an alternative solution:
I've seen that debian/rules is a kind of Makefile. There are some parts of
debian specific stuff, but the major part seems platform independent. It
would be nice to extract these common parts and create a main Makefile
with them. This way, everyone could have access to the translated
manpages, and debian/rules could use this main Makefile. The recusion
issue would be solved.
The second part is that this Makefile would collide with the one generated
from Makefile.PL. I've been reading a little about ExtUtils::MakeMaker and
I've seen that there's another project (Module::Build) that aims to
replace this. It's here: http://search.cpan.org/dist/Module-Build/
I also found this introductory article, that tells the advantages of
Module::Build, and some small steps for migrating from
ExtUtils::MakeMaker, http://www.perl.com/pub/a/2003/02/12/module1.html
This aims to be completely perl-based, so there aren't intermediate
Makefiles and it's used this way:
perl Build.PL
./Build
./Build test
./Build install
It's very similar to the current process, but it frees the Makefile name.
This way we could have the main Makefile call this script, and do all the
other things (and we could forget about the bootstrap, because this main
Makefile would do it all).
I think it could be a good enhancement. If you like the idea but don't
have the time to watch it, I could try to test it.
Regards,
Jordi Vilalta
4:18 p.m.
I've been reading a little about ExtUtils::MakeMaker and
I've seen that there's another project (Module::Build) that aims to
replace this. It's here: http://search.cpan.org/dist/Module-Build/
I also found this introductory article, that tells the advantages of
Module::Build, and some small steps for migrating from
ExtUtils::MakeMaker, http://www.perl.com/pub/a/2003/02/12/module1.html
This aims to be completely perl-based, so there aren't intermediate
Makefiles and it's used this way:
perl Build.PL
./Build
./Build test
./Build install
It's very similar to the current process, but it frees the Makefile name.
This way we could have the main Makefile call this script, and do all the
other things (and we could forget about the bootstrap, because this main
Makefile would do it all).
I think it could be a good enhancement. If you like the idea but don't
have the time to watch it, I could try to test it.
The right solution would be to get the manpage and mo file generation out of
the regular Makefile, and include them properly to the Perl build system.
If you want to look at this issue, you're more than welcome.
Thanks in advance, Mt.
--
Les rebelles disaient que les débutants avaient le droit d'utiliser un
"éditeur", qui ressemblait à MSWord comme sa mère à Pamela Anderson.
"Vihaille" comme les rebelles l'appellaient, était sans doute un bizutage
-- L'histoire des pingouins
9:42 a.m.
Hi there,
On Fri, 4 Jun 2004, Martin Quinson wrote:
The right solution would be to get the manpage and mo file generation
out of
the regular Makefile, and include them properly to the Perl build system.
If you want to look at this issue, you're more than welcome.
The MakeMaker FAQ says: "Module::Build is the official heir apparent to
MakeMaker and we encourage people to work on M::B rather than spending
time improving MakeMaker". So this is what I've done. I attach the new
files, and the ones I modified. Now, the basic distribution can be
installed with:
perl Build.PL
./Build
./Build test
./Build install
and it doesn't deppend on make. I've transformed the debian/rules into a
main Makefile, so that it makes this process for you, and it includes the
locales and translated manpages generation. This way, one can install the
complete application and documents from the tar.gz. I've also reworked
debian/rules to use this main makefile. I haven't tested it (I have no
debian at home) so it may need some changes. The biggest change is in the
manpages generation: it writes each file in a hierarchy as they should be
installed on the system; it eases the installation without the
dh_installman tool, but I dont know if it's so bad for the debian package
generation...
The next step could be to watch how to integrate locales and manpages
generation into the Build.PL (as the manual says, Module::Build is more
easily custmoizable than MakeMaker), but for now, it lets you install the
complete file set on every distribution, not only debian.
I've also improved (in my opinion) the po/{bin,pod} Makefiles, using the
LANGS variable, instead of the redundant POFILES and MOFILES. The biggest
change has been in the pod Makefile, where I've made it able to translate
pods to many languages, instead of only the hardcoded french (I'll send
you a partial spanish translation of the pods soon).
I hope I didn't break so many things...
Regards,
Jordi Vilalta
2:14 p.m.
Selon Jordi Vilalta <jvprat(a)wanadoo.es>:
Hi there,
On Fri, 4 Jun 2004, Martin Quinson wrote:
> The right solution would be to get the manpage and mo file generation out
of
> the regular Makefile, and include them properly to the Perl build system.
>
> If you want to look at this issue, you're more than welcome.
The MakeMaker FAQ says: "Module::Build is the official heir apparent to
MakeMaker and we encourage people to work on M::B rather than spending
time improving MakeMaker". So this is what I've done. I attach the new
files, and the ones I modified. Now, the basic distribution can be
installed with:
perl Build.PL
./Build
./Build test
./Build install
and it doesn't deppend on make.
Nice job ! I'm currently working on integrating it into the CVS. I have a few
question for you. Sorry for the delay.
I've transformed the debian/rules into a
main Makefile, so that it makes this process for you, and it includes the
locales and translated manpages generation. This way, one can install the
complete application and documents from the tar.gz.
Do you need the Makefile anyhow, or is the Build system enough for everything?
I would really love to get completely ride of any makefiles around there. It
looks like the Right Thing to do in a perl module to me, and may help the
portability to non-unix OSes.
I've also reworked
debian/rules to use this main makefile. I haven't tested it (I have no
debian at home) so it may need some changes.
There was no need for that, thanks. If we manage to create a proper perl module,
packaging this to debian will be really easier using a tool called cdbs, but
that's a bit out of topic for now.
The biggest change is in the
manpages generation: it writes each file in a hierarchy as they should be
installed on the system; it eases the installation without the
dh_installman tool, but I dont know if it's so bad for the debian package
generation...
No, no problem.
The next step could be to watch how to integrate locales and manpages
generation into the Build.PL (as the manual says, Module::Build is more
easily custmoizable than MakeMaker), but for now, it lets you install the
complete file set on every distribution, not only debian.
Yes, that's definitively where I want to go.
I've also improved (in my opinion) the po/{bin,pod} Makefiles,
using the
LANGS variable, instead of the redundant POFILES and MOFILES. The biggest
change has been in the pod Makefile, where I've made it able to translate
pods to many languages, instead of only the hardcoded french (I'll send
you a partial spanish translation of the pods soon).
Nice job ! I didn't knew about the define construct in makefiles. It's just
awsom.
I hope I didn't break so many things...
It does not look so, and even if it were the case, it wouldn't be an issue...
Thanks again, Mt.
PS: No need to CC me, I'm already subscribed twice on that damn mailing list ;)
3:06 p.m.
New subject: [Po4a-devel]New makefiles
Selon Jordi Vilalta <jvprat(a)wanadoo.es>:
Hi there,
On Fri, 4 Jun 2004, Martin Quinson wrote:
> The right solution would be to get the manpage and mo file generation out
of
> the regular Makefile, and include them properly to the Perl build system.
>
> If you want to look at this issue, you're more than welcome.
The MakeMaker FAQ says: "Module::Build is the official heir apparent to
MakeMaker and we encourage people to work on M::B rather than spending
time improving MakeMaker". So this is what I've done. I attach the new
files, and the ones I modified. Now, the basic distribution can be
installed with:
Ouch, that hurts:
mquinson@basalt:~/src/PERSO/PACKAGES/po4a/po4a-cvs$ make tar
perl Build.PL installdirs=vendor
Can't locate Module/Build.pm in @INC (@INC contains: /usr/local/lib/perl/5.6.1
/usr/local/share/perl/5.6.1 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.6.1
/usr/share/perl/5.6.1 /usr/local/lib/site_perl .) at Build.PL line 1.
BEGIN failed--compilation aborted at Build.PL line 1.
make: *** [Build] Error 2
The damm machine I have to use until my laptop is fixed uses the stable version
of Debian, which is more than a year old...
Could you please fetch the CVS and check that I commited your changes correctly?
Sorry about that, and thanks for your great job.
Mt.
4:51 p.m.
New subject: [Po4a-devel]New makefiles
On Tue, 29 Jun 2004 martin.quinson(a)free.fr wrote:
Ouch, that hurts:
mquinson@basalt:~/src/PERSO/PACKAGES/po4a/po4a-cvs$ make tar
perl Build.PL installdirs=vendor
Can't locate Module/Build.pm in @INC (@INC contains: /usr/local/lib/perl/5.6.1
/usr/local/share/perl/5.6.1 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.6.1
/usr/share/perl/5.6.1 /usr/local/lib/site_perl .) at Build.PL line 1.
BEGIN failed--compilation aborted at Build.PL line 1.
make: *** [Build] Error 2
The damm machine I have to use until my laptop is fixed uses the stable version
of Debian, which is more than a year old...
Could you please fetch the CVS and check that I commited your changes correctly?
It seems okay. The only missing file is the main Makefile, and the
bootstrap can be deleted. Using my local makefile all works well.
It seems that libmodule-build-perl isn't available for woody :(
http://packages.debian.org/libmodule-build-perl
In testing you have the version 0.25. I've tested it with versions 0.19
and 0.22 and it all works.
Regards,
Jordi Vilalta
5:10 p.m.
New subject: [Po4a-devel]New makefiles
Selon Jordi Vilalta <jvprat(a)wanadoo.es>:
On Tue, 29 Jun 2004 martin.quinson(a)free.fr wrote:
>
> Could you please fetch the CVS and check that I commited your changes
correctly?
It seems okay. The only missing file is the main Makefile, and the
bootstrap can be deleted. Using my local makefile all works well.
Ok, done, thanks.
It seems that libmodule-build-perl isn't available for woody :(
http://packages.debian.org/libmodule-build-perl
In testing you have the version 0.25. I've tested it with versions 0.19
and 0.22 and it all works.
I know. But my laptop should be fixed before wenesday, so I do not have the
courage to make this damn desktop fit my needs...
Mt.
7263
days inactive
7301
days old
10 comments
3 participants
participants (3)
-
Jordi Vilalta -
Martin Quinson -
martin.quinson＠free.fr