From: "Francois Gouget" fgouget@codeweavers.com
[...] here's a patch to translate the Wine FAQ to French using the new po4a/ directory.
OK, I've applied the patch to make your life easier, but it needs a lot of work: A. It doesn't work for me (details below) B. The po-rules need to be moved to Make.rules.in C. We need to get rid of the .posgml and sed hack
Let's fix these before we put in more translations. So, in reverse order:
C. We can do so by patching po4a-translate to do the replacement itself, from within perl. This should also get rid of the .posgml
B. They need to be in the same format as the other rules in Make.rules.in (eg .sgml.txt)
A. I think we need to check in the generated .sgml too to make it simple to use, so others don't have to go through the pain. Look:
[dimi@dimi fr]$ make updatepo cd ../en && PERLLIB=../po4a/lib perl ../po4a/po4a-updatepo -f sgml -m wine-faq.s gml -p ../fr/wine-faq.po perl: warning: Setting locale failed. perl: warning: Please check that your locale settings: LANGUAGE = (unset), LC_ALL = (unset), LANG = "fr" are supported and installed on your system. perl: warning: Falling back to the standard locale ("C"). Can't locate Locale/gettext.pm in @INC (@INC contains: ../po4a/lib /usr/lib/perl 5/5.8.5/i386-linux-thread-multi /usr/lib/perl5/5.8.5 /usr/lib/perl5/site_perl/5. 8.5/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.4/i386-linux-thread-mul ti /usr/lib/perl5/site_perl/5.8.3/i386-linux-thread-multi /usr/lib/perl5/site_pe rl/5.8.2/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.1/i386-linux-threa d-multi /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi /usr/lib/perl5/si te_perl/5.8.5 /usr/lib/perl5/site_perl/5.8.4 /usr/lib/perl5/site_perl/5.8.3 /usr /lib/perl5/site_perl/5.8.2 /usr/lib/perl5/site_perl/5.8.1 /usr/lib/perl5/site_pe rl/5.8.0 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.8.5/i386-linux-th read-multi /usr/lib/perl5/vendor_perl/5.8.4/i386-linux-thread-multi /usr/lib/per l5/vendor_perl/5.8.3/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.2/i3 86-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.1/i386-linux-thread-multi / usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi /usr/lib/perl5/vendor_pe rl/5.8.5 /usr/lib/perl5/vendor_perl/5.8.4 /usr/lib/perl5/vendor_perl/5.8.3 /usr/ lib/perl5/vendor_perl/5.8.2 /usr/lib/perl5/vendor_perl/5.8.1 /usr/lib/perl5/vend or_perl/5.8.0 /usr/lib/perl5/vendor_perl .) at ../po4a/lib/Locale/Po4a/Common.pm line 32. BEGIN failed--compilation aborted at ../po4a/lib/Locale/Po4a/Common.pm line 32. Compilation failed in require at ../po4a/lib/Locale/Po4a/TransTractor.pm line 21 . BEGIN failed--compilation aborted at ../po4a/lib/Locale/Po4a/TransTractor.pm lin e 21. Compilation failed in require at ../po4a/lib/Locale/Po4a/Po.pm line 59. BEGIN failed--compilation aborted at ../po4a/lib/Locale/Po4a/Po.pm line 59. Compilation failed in require at ../po4a/po4a-updatepo line 117. BEGIN failed--compilation aborted at ../po4a/po4a-updatepo line 117. make: *** [wine-faq.updatepo] Error 2
Dimitrie Paun wrote:
From: "Francois Gouget" fgouget@codeweavers.com
[...] here's a patch to translate the Wine FAQ to French using the new po4a/ directory.
OK, I've applied the patch to make your life easier, but it needs a lot of work: A. It doesn't work for me (details below) B. The po-rules need to be moved to Make.rules.in C. We need to get rid of the .posgml and sed hack
Let's fix these before we put in more translations. So, in reverse order:
C. We can do so by patching po4a-translate to do the replacement itself, from within perl. This should also get rid of the .posgml
I have started looking into this. The right fix is for po4a Sgml module to support translating attributes. I guess it has not been done yet because it's only useful for one attribute: lang. The problem is that this is not supported at all and I'm a bit lost as to how to modify it. It looks like it should be done near this code (line Sgml.pm:680):
if ($val->type() eq 'CDATA' || $val->type() eq 'IMPLIED') { if (defined $value && length($value)) { if ($value =~ m/"/) { #" $value = "'".$value."'"; } else { $value = '"'.$value.'"'; } $tag .= ' '.lc($attr).'='.$value; }
B. They need to be in the same format as the other rules in Make.rules.in (eg .sgml.txt)
They can't because the generated file depends on two source files and not just one. At least for this rule (but maybe you were thinking about another one):
%.posgml: $(SGMLDIR)/%.sgml %.po
Why is this not good?
A. I think we need to check in the generated .sgml too to make it simple to use, so others don't have to go through the pain.
This itself is going to be annoying.
Look:[dimi@dimi fr]$ make updatepo cd ../en && PERLLIB=../po4a/lib perl ../po4a/po4a-updatepo -f sgml -m wine-faq.s gml -p ../fr/wine-faq.po perl: warning: Setting locale failed. perl: warning: Please check that your locale settings: LANGUAGE = (unset), LC_ALL = (unset), LANG = "fr" are supported and installed on your system. perl: warning: Falling back to the standard locale ("C").
It looks like perl is being run in a French locale. Is this your doing or po4a's?
Can't locate Locale/gettext.pm in @INC (@INC contains: ../po4a/lib /usr/lib/perl5/5.8.5/i386-linux-thread-multi /usr/lib/perl5/5.8.5
po4a depends on the gettext perl module. It's a standard Perl module so there should be an RPM for it. What's ironic is that this is just so po4a can issue localized error messages, AFAIK it's not needed for po4a to perform its work. Once this is fixed you may find that you have to install the SGMLS perl module but po4a should give you a nice error message. That should be all of po4a's requirements I think.
Note that to compile the SGML sources you also have to install a bunch of packages (docbook, docbook-dsssl, jade, etc). po4a only adds two extra packages to the list which should not be too bad. We could also detect that the Perl packages are missing in the configure script and either issue an error message or disable the compilation of translated documentation. It's up to you.
On Fri, 2005-05-20 at 11:16 +0200, Francois Gouget wrote:
Dimitrie Paun wrote:
C. We can do so by patching po4a-translate to do the replacement itself, from within perl. This should also get rid of the .posgml
I have started looking into this. The right fix is for po4a Sgml module to support translating attributes.
Cool. If you figure it out, I think you should also try to get it integrated upstream.
B. They need to be in the same format as the other rules in Make.rules.in (eg .sgml.txt)
They can't because the generated file depends on two source files and not just one. At least for this rule (but maybe you were thinking about another one):
%.posgml: $(SGMLDIR)/%.sgml %.po
Why is this not good?
Fine, I don't care much.
A. I think we need to check in the generated .sgml too to make it simple to use, so others don't have to go through the pain.
This itself is going to be annoying.
Too many dependencies. Unless we can remove them...
It looks like perl is being run in a French locale. Is this your doing or po4a's?
pa4a's: [dimi@dimi ~]$ echo $LANG en_US.UTF-8
Can't locate Locale/gettext.pm in @INC (@INC contains: ../po4a/lib /usr/lib/perl5/5.8.5/i386-linux-thread-multi /usr/lib/perl5/5.8.5
po4a depends on the gettext perl module. It's a standard Perl module so there should be an RPM for it.
Can we easily patch it to get rid of it? We don't need localized messages, maybe we can provide a dummy gettext.pm?
Am Freitag, den 20.05.2005, 07:39 -0400 schrieb Dimi Paun:
Can we easily patch it to get rid of it? We don't need localized messages, maybe we can provide a dummy gettext.pm?
For the winetools shell-script, i use this function, ...
-----------
wt_find_gettext() {
which "gettext.sh" > /dev/null 2>/dev/null if [ "$?" -eq "0" ] then WT_TRACE "gettext found in path" . gettext.sh else for data in "/bin" "/usr/bin" "/usr/local/bin" do if [ -r "$data/gettext.sh" ] then WT_TRACE "gettext found in $data" . "$data/gettext.sh" fi done fi
type "eval_gettext" &>/dev/null if [ "$?" -ne "0" ] then
WT_TRACE "gettext.sh not found on your system. Translations disabled"
# internal "eval_gettext" - replacement: # eval_gettext() { echo -n "$1" } 2>/dev/null fi } -----------
... but pearl is not my language.
Detlef Riekenberg wrote:
Am Freitag, den 20.05.2005, 07:39 -0400 schrieb Dimi Paun:
Can we easily patch it to get rid of it? We don't need localized messages, maybe we can provide a dummy gettext.pm?
For the winetools shell-script, i use this function, ...
po4a is all perl so this does not work. What we would need is to either edit out every reference to Locale::gettext and dgettext, or somehow provide a fake Locale::gettext module. However it seems kind of ironical to me to disable localization in a tool meant to produce a localized version of the documentation: the first action means we don't care about localization and people who whant stuff in their language, while the second says we do. So I'd prefer to add a configure test to tell users which perl modules they are missing.
On Mon, 2005-05-23 at 13:18 +0200, Francois Gouget wrote:
However it seems kind of ironical to me to disable localization in a tool meant to produce a localized version of the documentation
People that do the translation must know English anyhow. I think it's way more important to have a working tool. I haven't seen anyone complain that our tools/* are not translated.
A simple configure check will not do. We should just work even if we don't have the module. If you care about i18n on po4a, we can use it *if* it's present. But forcing users to install it is not a solution.
Am Montag, den 23.05.2005, 13:18 +0200 schrieb Francois Gouget:
Can we easily patch it to get rid of it? We don't need localized messages, maybe we can provide a dummy gettext.pm?
For the winetools shell-script, i use this function, ...
po4a is all perl so this does not work.
See my words below the Code "... but pearl is not my language." :-)
The Code was just a hint, that it was very easy to modify this part in winetools 2.1.1 for wt3 in such a way, that it does not break, if "gettext" is not installed on the system. The user does not need to install a fake "gettext.sh", the buildin-Version works without a Message (bash). When using ash as shell, it works also, but give you a warning-message.
Very Simple, but not done before.
So I'd prefer to add a configure test to tell users which perl modules they are missing.
Or let configure create the fake modules and a po4awrapper that use the system-installed or the fake modules, depending what is found on the system "--without-included-fakes" :-).
Detlef Riekenberg wrote:
Am Montag, den 23.05.2005, 13:18 +0200 schrieb Francois Gouget:
Can we easily patch it to get rid of it? We don't need localized messages, maybe we can provide a dummy gettext.pm?
For the winetools shell-script, i use this function, ...
po4a is all perl so this does not work.
See my words below the Code "... but pearl is not my language." :-)
The Code was just a hint,
I understand. All I was saying is that po4a does not just call the 'gettext' command line utility. It links to the Locale::gettext perl module and then calls its gettext() and dgettext() functions. So it's not as simple as just wrapping the gettext tool in a script.
And, the gettext.pm perl module does not use the command line utility either. Instead it directly links with libgettext.so and won't load if it's missing.
So we basically have four solutions: 1) rip out all references to '.*gettext.*' from po4a. But this will result in a big diff which will make it hard to merge with later versions. 2) modify po4a to abstract all calls to gettext. This will also result in a big diff but might possibly be accepted upstream. 3) write a fake Locale::gettext perl module and force po4a to use it by hacking PO4AENV. Plus more hacks so users who have a real gettext.pm module can use it and get errors in their own language. 4) accept that Locale::gettext.pm is a requisite to running po4a and instruct users to install it.
But I have completed an analysis of the Wine documentation dependencies and I think that solutions 1-3 above are moot as they solve only a tiny bit of the problem. Here's the dependency list:
* docbook2html / db2html & co (command line tools) Needed to generate Html, Pdf, etc. Provided by docbook-utils on Debian, Fedora Core and SUSE.
* Locale::gettext (perl module) Needed by po4a for localization. Provided by liblocale-gettext-perl on Debian, perl-Locale-gettext on Mandrake, perl-gettext on SUSE.
* Text::WrapI18N (perl module) Needed by po4a, probably to wrap the text to put it into the po file and to generate the sgml file. Pure perl (so easy to check in) but depends on Text::CharWidth which is not pure perl. This one was not used in po4a 0.16.2 but I suspect this caused trouble with multibyte locales. Provided by libtext-wrapi18n-perl on Debian. Not found on SUSE.
* Term::ReadKey (perl module) Needed by po4a. Not sure why. Provided by libterm-readkey-perl on Debian, perl-Term-ReadKey on Mandrake, perl-TermReadKey on SUSE.
* SGMLS Needed by po4a to interface with the nsgmls parser. Pure perl (so easy to check in). Provided by libsgmls-perl on Debian, perl-SGMLS on SUSE.
* nsgmls (command line tool) Needed by po4a to parse the Sgml files. Provided by sp on Debian, opensp on SUSE.
So there's really no point to focus on Locale::gettext.pm. Also we cannot remove all these dependencies without breaking po4a completely. Finally we could check in all of those. But, except for the pure perl modules, these require a C compiler, which means headers and libraries to link with... We'd be adding more dependencies than we remove.
So I think the best is to check for those in the configure script and inform the user of missing dependencies. I attached a patch that does that for illustration purposes.
On Wed, 2005-05-25 at 02:15 +0200, Francois Gouget wrote:
So there's really no point to focus on Locale::gettext.pm.
You are right, all these dependencies are crazy.
First, perl modules are evil. They are outside the packaging system, and I had only pain and suffering from them.
Second, if there are no neat Fedora Code 3 .rpm package available, it doesn't exist as far as I'm concerned.
Third, the SGML tools are already a big pain. Multiplying it 10 fold is not a step forward. We need to find a way to deal with this, and I'd much rather have a self-contained po4a.
This is a tough one. Is there any way we can get the number of dependencies to a sane level? (And that level being that it consists of a few packages that are readily available for most distros)
Dimi Paun wrote:
On Wed, 2005-05-25 at 02:15 +0200, Francois Gouget wrote:
So there's really no point to focus on Locale::gettext.pm.
You are right, all these dependencies are crazy.
First, perl modules are evil. They are outside the packaging system, and I had only pain and suffering from them.
I don't understand this argument 'perl modules are outside the packaging system'. When I installed the po4a package on my Debian system it automatically installed all the required packages.
Of course here we are not installing a package but using the source directly so the packaging system won't take care of the dependencies for us. But that would be just as true for Wine: Wine's configure will tell you that you're mising the OpenGL library, that you don't have any sound library, and the X development environment is missing. But then you will be on your own to identify the needed packages. Just the same as with any missing perl module.
Maybe you were referring to CPAN which is a perl-specific alternate solution to packages. In that case I agree, I don't like it either and just don't use it.
When I looked for packages providing some of the needed dependencies I had no problem finding all the Debian packages. The trick there is there's a URL where you can give the name of a file and it gives you the name of the required package even if it is not installed. SUSE's Yast2 provided much the same ability. Mandrake's packaging was a bit more primitive but would at least let me search for packages by name so with a bit of guessing I made some progress. However the RedHat / Fedora Core package manager was awfully inadequate, offering no search functionality at all (<flame>they probably think the dumbed-down categories remove the need for it</flame>). In fact I did not find *any* perl package listed in RedHat's package manager! (<gripe>It also forced me to switch CDs >10 times when I tried installing the DocBook stuff, and to add insult to injury it would give me an error if I did not manually umount the CD after inserting it and before letting the packaging system look for stuff on it!</gripe>) The crux is that, while I was able to find the packages needed for SUSE, I had no such luck with RedHat / Fedora Core and only very limited luck with Mandrake. But maybe this is just because I don't know the magic URL like the one I used for Debian. IOW maybe someone more familiar with Mandrake / RedHat / Fedora Core can find more packages than I did.
[...]
Third, the SGML tools are already a big pain. Multiplying it 10 fold is not a step forward. We need to find a way to deal with this, and I'd much rather have a self-contained po4a.
I'd prefer po4a to be as self-contained as possible too. I'll ask about that on the po4a mailing list (and cross-post).
On Wed, 2005-05-25 at 12:36 +0200, Francois Gouget wrote:
Maybe you were referring to CPAN which is a perl-specific alternate solution to packages. In that case I agree, I don't like it either and just don't use it.
Yes, I was referring to CPAN.
However the RedHat / Fedora Core package manager was awfully inadequate, offering no search functionality at all (<flame>they probably think the dumbed-down categories remove the need for it</flame>).
The package manager does not do that. Did you try http://rpmfind.net? Also, the packages should be available via yum (most likely at DAG http://dag.wieers.com/home-made/apt/rpmforge.php)
In fact I did not find *any* perl package listed in RedHat's package manager!
And herein lies the problem: hate it or love it, it's the most used distribution, and it should work on it first and foremost. If it doesn't, we have a problem.
On a slightly different note, I think you are comparing apples to oranges: you want rpm to provide search equivalent to what an indexing site does for Debian. It shouldn't and there are such sites out there.
Dimi Paun wrote: [...]
However the RedHat / Fedora Core package manager was awfully inadequate, offering no search functionality at all (<flame>they probably think the dumbed-down categories remove the need for it</flame>).
The package manager does not do that. Did you try http://rpmfind.net? Also, the packages should be available via yum (most likely at DAG http://dag.wieers.com/home-made/apt/rpmforge.php)
As far as I could see neither will let me search for a package based on the name of a file it contains. For instance in both cases a search on 'gettext.pm' returns no result though both know about perl-Locale-gettext.
But I found http://rpm.pbone.net/ which seems to be giving good results. However it often gives more than one result for a given distribution and it's not always clear which packages are official and which are not. For instance nsgmls seems to be provided by opensp and openjade on Fedora. I think openjade is the official package...
In fact I did not find *any* perl package listed in RedHat's package manager!
And herein lies the problem: hate it or love it, it's the most used distribution, and it should work on it first and foremost.
Hehe, maybe.. maybe not. According to DesktopLinux RedHat (including Fedora Core) was third behind Mandrake and SUSE. http://www.desktoplinux.com/articles/AT2127420238.html Not that their 'survey' is very reliable or that this is very important, Fedora is one of the main Linux distributions anyway.
On a slightly different note, I think you are comparing apples to oranges: you want rpm to provide search equivalent to what an indexing site does for Debian. It shouldn't and there are such sites out there.
True but I also mentioned that SUSE's Yast2 let me search for the package providing a given file even if that package was not installed. This is exactly the functionality that is missing from RedHat's package manager (and from Debian's). I also mentioned that the problem I encountered was probably at least partly related to my inexperience with RPM.
Am Freitag, den 20.05.2005, 07:39 -0400 schrieb Dimi Paun:
It looks like perl is being run in a French locale. Is this your doing or po4a's?
pa4a's: [dimi@dimi ~]$ echo $LANG en_US.UTF-8
make[1]: Verlasse Verzeichnis »/home/detlef/wine.cvs/bin/en« make[1]: Gehe in Verzeichnis »/home/detlef/wine.cvs/bin/fr« cd ../../docs/en && PERLLIB=../../docs/po4a/lib perl ../../docs/po4a/po4a-translate -v -f sgml -m wine-faq.sgml -p ../../docs/fr/wine-faq.po -l ../../docs/fr/wine-faq.posgml -k 1 perl: warning: Setting locale failed. perl: warning: Please check that your locale settings: LANGUAGE = "de_DE:en_GB", LC_ALL = (unset), LANG = "fr" are supported and installed on your system. perl: warning: Falling back to the standard locale ("C"). Can't open perl script "../../docs/po4a/po4a-translate": No such file or directory make[1]: *** [wine-faq.posgml] Fehler 2 make[1]: Verlasse Verzeichnis »/home/detlef/wine.cvs/bin/fr«
Detlef Riekenberg wrote: [...]
I'm setting aside the French locale issue which confirms what Dimi is seeing because there's another error which is pretty strange there.
make[1]: Verlasse Verzeichnis »/home/detlef/wine.cvs/bin/en« make[1]: Gehe in Verzeichnis »/home/detlef/wine.cvs/bin/fr« cd ../../docs/en && PERLLIB=../../docs/po4a/lib
[...]
Can't open perl script "../../docs/po4a/po4a-translate": No such file or directory
How come make says it's going to '/home/detlef/wine.cvs/bin/fr'? This looks like the winedocs source is in the Wine CVS tree which is no longer the case. But more worrying is '../../docs/po4a/po4a-translate': there's one '..' too many. As far as I can tell this should be '../po4a/po4a-translate'. Is this some out-of-tree compilation or something like this?
Am Montag, den 23.05.2005, 13:22 +0200 schrieb Francois Gouget:
I'm setting aside the French locale issue which confirms what Dimi is seeing because there's another error which is pretty strange there.
make[1]: Verlasse Verzeichnis »/home/detlef/wine.cvs/bin/en« make[1]: Gehe in Verzeichnis »/home/detlef/wine.cvs/bin/fr« cd ../../docs/en && PERLLIB=../../docs/po4a/lib
[...]
Can't open perl script "../../docs/po4a/po4a-translate": No such file or directory
This was an out of tree compilation, but with a not really useful target-directory (sorry for that. I changed it already, because the docs-makefile overwrites the wine makefile).
My Wine Directory-Tree:
$WINEPREFIX (the normal ".wine" - tree) $WINEPREFIX/src (source-tree) $WINEPREFIX/bin (out-of-tree-compilation-target)
And $WINEPREFIX is one of: $HOME/wine.3 (20050310) $HOME/wine.4 (20050419) $HOME/wine.cvs
For the above text, i only want to show, that i got the conversation-error with LANG="fr" and LANGUAGE="de_DE:*".
I converted en/wine-faq.sgml to fr/wine-faq.sgml (calling the apps on the commandline) but sgml-header lang did not changed.
The Documentation-cvs was $HOME/wine.cvs/docs and the cd was $HOME/wine.cvs/bin (i hope, i remembered the right path...).
Some ideas, but no skill to implement it myself: po4a_use_system_installed=false, AC_CHECK_PROGS for po4a-* ; set po4a_use_system_installed=true
fallback to included po4a, when not found on the system or when forced with --with-included-po4a
Detlef Riekenberg wrote: [...]
This was an out of tree compilation, but with a not really useful target-directory (sorry for that. I changed it already, because the docs-makefile overwrites the wine makefile).
Ok. I have a patch that fixes the out-of-tree build issue. It relies on a fix to po4a so it interprets the path to files included in Sgml as relative to the directory of the master Sgml file. IOW, with this patch when ../en/wineuser-guide.sgml includes wineusr-introduction.sgml we look for ../en/wineuser-introduction.sgml (which is what the other Sgml tools like docbook2html seem to do).
I have submitted the patch to the po4a folks and I'm hoping they will commit it. I have also attached the patch to this email together with the Makefile.in change for review.
Francois Gouget wrote: [...]
C. We can do so by patching po4a-translate to do the replacement itself, from within perl. This should also get rid of the .posgml
I have started looking into this. The right fix is for po4a Sgml module to support translating attributes. I guess it has not been done yet because it's only useful for one attribute: lang.
I have a patch for this one. I have attached the po4a part to this email for reference. Then we can modify our Makefile to generate the .sgml file directly instead of generating the intermediate .posgml file.
Cool. If you figure it out, I think you should also try to get it integrated upstream.
I have been sending them my Po4a patches and they have already merged almost all of them. Currently pending is: * this attribute translation patch * a patch to correctly detect that nsgmls is missing (I need to rework this patch)
In particular they have merged the patch that changes the way included files are handled and which lets us fix the out-of-tree builds.
Maybe it's time to figure out how we want to integrate the latest Po4a modifications. I see three approaches:
1) we manually apply the patches to our CVS This lets us apply patches at any time but runs the risk of getting conflicts the next time we import Po4a if the version that gets committed to their CVS is a bit different.
2) we import the next Po4a release I'm not sure when the next release is scheduled. We may want to be able to integrate our patches earlier.
3) we import Po4a CVS snapshots This lets us update our Po4a independently of the Po4a releases while making sure we don't diverge from the official Po4a codebase.
I think that until we are happy with the Po4a version in the winedocs CVS 3) is the best option. Then we can use 2) (or even not update at all if there is no need).
On Thu, 2005-05-26 at 14:01 +0200, Francois Gouget wrote:
- we manually apply the patches to our CVS This lets us apply patches at any time but runs the risk of
getting conflicts the next time we import Po4a if the version that gets committed to their CVS is a bit different.
- we import the next Po4a release I'm not sure when the next release is scheduled. We may want to
be able to integrate our patches earlier.
- we import Po4a CVS snapshots This lets us update our Po4a independently of the Po4a releases
while making sure we don't diverge from the official Po4a codebase.
Right, short term (3), then (2). However, I don't have a big problem to maintain _small_ changes in our tree. So for example, if they don't want to get rid of Text::WrapI18N and Term::ReadKey, I think we should get rid of them in our tree.
Just let me know when you think we should have the next import from their CVS. If a release is close, we can wait for that.
Dimi Paun wrote: [...]
Right, short term (3), then (2). However, I don't have a big problem to maintain _small_ changes in our tree. So for example, if they don't want to get rid of Text::WrapI18N and Term::ReadKey, I think we should get rid of them in our tree.
They response to my email regarding the Po4a dependencies was very positive. They waid they were ok with making the Locale::gettext, Text::WrapI18N and Term::ReadKey dependencies optional.
I have already sent a patch to make the Locale::gettext optional. I'll do a patch for Text::WrapI18N and Term::ReadKey next but I'll wait a little bit because the changes are in the same file and I'd like the first part committed first.
So we will be left with SGMLS and nsgmls.
SGMLS is a pure perl module so the best is to just check it in. The quick and dirty way would be to check it in as po4a/lib/SGMLS.pm. The cleaner way would be to import the module in the SGMLSpm directory.
wget \ http://search.cpan.org/CPAN/authors/id/D/DM/DMEGG/SGMLSpm-1.03ii.tar.gz tar xfz SGMLSpm-1.03ii.tar.gz cd SGMLSpm cvs -d ... import -ko -m "Import of SGMLSpm release 1.03ii" docs/SGMLSpm SGMLSPM sgmlspm-1_03ii
Then we are just left with the nsgmls dependency which is packaged with each distribution (it's either the sp, opensp, openjade or sgml-tools package).
Just let me know when you think we should have the next import from their CVS. If a release is close, we can wait for that.
The po4a team has been pretty responsive. They have already committed a lot of my patches (9 of them so far). I need to rework the attribute translation patch a bit but I hope I can get it in in the first half of next week. I may also get the patch making Text::WrapI18N and Term::ReadKey a soft dependency some time next week and once all this is in I think we'll be ready to do a CVS import.
On Sun, 2005-05-29 at 02:27 +0200, Francois Gouget wrote:
They response to my email regarding the Po4a dependencies was very positive. They waid they were ok with making the Locale::gettext, Text::WrapI18N and Term::ReadKey dependencies optional.
Beautiful. It is actually great that they are receptive to our suggestions, I think it will help them too.
SGMLS is a pure perl module so the best is to just check it in. The quick and dirty way would be to check it in as po4a/lib/SGMLS.pm. The cleaner way would be to import the module in the SGMLSpm directory.
If it's only a file, maybe the quick and dirty method is simpler. What about suggesting to the po4a folks that _they_ do the import in their tree?
Then we are just left with the nsgmls dependency which is packaged with each distribution (it's either the sp, opensp, openjade or sgml-tools package).
Yeah, that's cool. Isn't this the same package we need anyway to process our SGML?
The po4a team has been pretty responsive. They have already committed a lot of my patches (9 of them so far). I need to rework the attribute translation patch a bit but I hope I can get it in in the first half of next week. I may also get the patch making Text::WrapI18N and Term::ReadKey a soft dependency some time next week and once all this is in I think we'll be ready to do a CVS import.
Perfect! World domination is at hand... :)
This is great Francois, thanks for doing all the hard work on getting this cleaned up properly. It's important to simplify things, as translation is the type of project where we can expect less technical people to contribute. And we really don't want to scare them off.
From: "Francois Gouget" fgouget@codeweavers.com
So we will be left with SGMLS and nsgmls.
SGMLS is a pure perl module so the best is to just check it in. The quick and dirty way would be to check it in as po4a/lib/SGMLS.pm. The cleaner way would be to import the module in the SGMLSpm directory.
wget \ http://search.cpan.org/CPAN/authors/id/D/DM/DMEGG/SGMLSpm-1.03ii.tar.gz tar xfz SGMLSpm-1.03ii.tar.gz cd SGMLSpm cvs -d ... import -ko -m "Import of SGMLSpm release 1.03ii" docs/SGMLSpm SGMLSPM sgmlspm-1_03ii
Hmm, _if_ we only care about SGMLS.pm, I'd rather just import that, we don't care one bit about the rest of the stuff that comes with the SGMLSpm package. We can also avoid namespace polution too :)
But there seem to be 3 .pm files in the distribution: [dimi@dimi SGMLSpm]$ ls *.pm Output.pm Refs.pm SGMLS.pm
Do we not care about Output.pm, and Refs.pm?
Any other reasons why I shouldn't just import it as po4a/lib/SGMLS.pm?
Dimi Paun wrote:
From: "Francois Gouget" fgouget@codeweavers.com
So we will be left with SGMLS and nsgmls.
SGMLS is a pure perl module so the best is to just check it in. The quick and dirty way would be to check it in as po4a/lib/SGMLS.pm. The cleaner way would be to import the module in the SGMLSpm directory.
Importing the whole SGMLS distribution may be cleaner but it's much heavier so it's probably a wash in our case.
But there seem to be 3 .pm files in the distribution: [dimi@dimi SGMLSpm]$ ls *.pm Output.pm Refs.pm SGMLS.pm
Do we not care about Output.pm, and Refs.pm?
As far as I know we don't. It certainly was not needed in my tests.
Any other reasons why I shouldn't just import it as po4a/lib/SGMLS.pm?
No. That seems like a reasonable approach.
On Thu, 2005-06-16 at 22:40 +0200, Francois Gouget wrote:
Dimi Paun wrote:
From: "Francois Gouget" fgouget@codeweavers.com
So we will be left with SGMLS and nsgmls.
SGMLS is a pure perl module so the best is to just check it in. The quick and dirty way would be to check it in as po4a/lib/SGMLS.pm. The cleaner way would be to import the module in the SGMLSpm directory.
Importing the whole SGMLS distribution may be cleaner but it's much heavier so it's probably a wash in our case.
I brought this up before, but what about converting to XML and just using the XML doc tools that come much more commonly these days? We wouldn't need to bundle anything weird then, either. IIRC, the sgml files are almost exactly the same as XML files, it shouldn't be too much effort to switch.
Thanks, Scott Ritchie
From: "Scott Ritchie" scott@open-vote.org
I brought this up before, but what about converting to XML and just using the XML doc tools that come much more commonly these days? We wouldn't need to bundle anything weird then, either. IIRC, the sgml files are almost exactly the same as XML files, it shouldn't be too much effort to switch.
Sure, we can convert to XML, but let's do it one thing at a time. Let's first clean up the SGML building requirements (we have a good plan moving forward), then we can consider XML.
Scott Ritchie wrote: [...]
I brought this up before, but what about converting to XML and just using the XML doc tools that come much more commonly these days? We wouldn't need to bundle anything weird then, either. IIRC, the sgml files are almost exactly the same as XML files, it shouldn't be too much effort to switch.
Interestingly Po4a does not use a 'real' XML parser like XML::DOM or other similar perl module. So switching to XML could actually reduce dependencies.
However this would force us to switch to using Po4a's XML module which currently has trouble dealing with included files. There's a hack to workaround this issue but I'm not quite sure how it works.
Also in either case we need to deal with the Text::WrapI18N and Term::ReadKey dependencies (my next targets).
So I think it's better to continue with what we have. But if you want you can fix the Po4a XML issues to prepare the switch to XML.
-
Detlef Riekenberg -
Dimi Paun -
Dimitrie Paun
-
Francois Gouget -
Scott Ritchie