9:42 a.m.
Hello,
On Tue, 1 Feb 2005, Jordi Vilalta wrote:
I might be wrong, but I think it's time to create a new module
with common
functions used by several scripts, like the config file loading, or a
function to show wrapped messages using the proposed syntax in
https://alioth.debian.org/tracker/index.php?func=detail&aid=300889&am...
Any ideas about this? What name should it take? (Common, Utils, Tools,
...?)
I've begun working on it (with the temporary name "Common").
While moving common parts of the scripts to this module, I've found an
undocumented option in the po4a script: split. What does it do? It adds a big
amount of code. Should it be documented or is it there just for testing?
hmm, I'm now thinking on posponing these big moves and concentrating in the
gcc-like syntax/wrapping stuff.
Regards,
Jordi Vilalta
1:51 p.m.
New subject: [Po4a-devel]Re: Translating NEWS.Debian files: a (crude) first try
Hi,
On Thu, 3 Feb 2005, Jordi Vilalta wrote:
hmm, I'm now thinking on posponing these big moves and
concentrating in the
gcc-like syntax/wrapping stuff.
I've been testing Text::WrapI18N and it gives great results. With this
we'll be able to remove line breaks in a lot of messages and let this
module wrap the messages dynamically.
Now I have some questions about how you want to show the messages:
Should we attach "po4a::module_name" in front of all the messages?
And "po4a" for all that comes from the main program?
If the message is more than one line long, how should the other lines
begin? with the same stamp (1), spaces (2) or nothing (3)?
(1)
po4a::man: this is a test message, this is a test message, this is a
po4a::man: test message.
(2)
po4a::man: this is a test message, this is a test message, this is a
test message.
(3)
po4a::man: this is a test message, this is a test message, this is a
test message.
For the errors, we should begin the messages with "file:line: " (the
gcc-like syntax). Should this appear just on the first line or in all the
lines of the message?
Should these error messages also contain the module stamp commented above,
or we suppose that people already knows what module comes it from? If
affirmative, it should appear just in the first line (1) or in all (2)?
(1)
file.doc:4: po4a::man: this is an example error, this is an example
file.doc:4: error, this is an example error
(2)
file.doc:4: po4a::man: this is an example error, this is an example
file.doc:4: po4a::man: error, this is an example error
You can also propose other styles. Thanks for your patience ;)
Regards,
Jordi Vilalta
2:51 p.m.
New subject: [Po4a-devel]Re: Translating NEWS.Debian files: a (crude) first try
On Fri, Feb 04, 2005 at 08:51:20PM +0100, Jordi Vilalta wrote:
[...]
Now I have some questions about how you want to show the messages:
Should we attach "po4a::module_name" in front of all the messages?
And "po4a" for all that comes from the main program?
If the message is more than one line long, how should the other lines
begin? with the same stamp (1), spaces (2) or nothing (3)?
(1)
po4a::man: this is a test message, this is a test message, this is a
po4a::man: test message.
IIRC this is the current implementation, but I for one do not like it.
(2)
po4a::man: this is a test message, this is a test message, this is a
test message.
(3)
po4a::man: this is a test message, this is a test message, this is a
test message.
If the madule name is short, I prefer 2 > 3 > 1.
When it is long, either 3 > 2 > 1 or 2 > 3 > 1.
For the errors, we should begin the messages with "file:line:
" (the
gcc-like syntax). Should this appear just on the first line or in all the
lines of the message?
Should these error messages also contain the module stamp commented above,
or we suppose that people already knows what module comes it from? If
affirmative, it should appear just in the first line (1) or in all (2)?
(1)
file.doc:4: po4a::man: this is an example error, this is an example
file.doc:4: error, this is an example error
(2)
file.doc:4: po4a::man: this is an example error, this is an example
file.doc:4: po4a::man: error, this is an example error
As with module name, I believe that repeating filename and line numbers
is not necessary and make error messages less readable.
You can also propose other styles. Thanks for your patience ;)
Maybe
file.doc:4: po4a::man
this is an example error, this is an example error, this is an
example error
Denis
3:16 p.m.
New subject: [Po4a-devel]Re: Translating NEWS.Debian files: a (crude) first try
On Fri, Feb 04, 2005 at 09:51:48PM +0100, Denis Barbier wrote:
On Fri, Feb 04, 2005 at 08:51:20PM +0100, Jordi Vilalta wrote:
[...]
> Now I have some questions about how you want to show the messages:
>
> Should we attach "po4a::module_name" in front of all the messages?
> And "po4a" for all that comes from the main program?
>
> If the message is more than one line long, how should the other lines
> begin? with the same stamp (1), spaces (2) or nothing (3)?
>
> (1)
> po4a::man: this is a test message, this is a test message, this is a
> po4a::man: test message.
IIRC this is the current implementation, but I for one do not like it.
> (2)
> po4a::man: this is a test message, this is a test message, this is a
> test message.
>
> (3)
> po4a::man: this is a test message, this is a test message, this is a
> test message.
If the madule name is short, I prefer 2 > 3 > 1.
When it is long, either 3 > 2 > 1 or 2 > 3 > 1.
If we manage to get 2, I like it the best. I dunno, it looks hard to do and
thus cool. ;) 3 is good, too, if we have to.
> For the errors, we should begin the messages with
"file:line: " (the
> gcc-like syntax). Should this appear just on the first line or in all the
> lines of the message?
>
> Should these error messages also contain the module stamp commented above,
> or we suppose that people already knows what module comes it from? If
> affirmative, it should appear just in the first line (1) or in all (2)?
>
> (1)
> file.doc:4: po4a::man: this is an example error, this is an example
> file.doc:4: error, this is an example error
>
> (2)
> file.doc:4: po4a::man: this is an example error, this is an example
> file.doc:4: po4a::man: error, this is an example error
As with module name, I believe that repeating filename and line numbers
is not necessary and make error messages less readable.
> You can also propose other styles. Thanks for your patience ;)
Maybe
file.doc:4: po4a::man
this is an example error, this is an example error, this is an
example error
file:line: (po4a::module)
toto tutu toto tutu toto tutu toto tutu toto tutu toto
toto tutu toto tutu toto tutu toto tutu toto tutu toto
?
It has the advantage of being easily readable. The best would be to use the
following value as indentation offset: >>max(length("$file:$line:
",10))<<
It would ensure that things keep readable when dealing with the file
../../../../../toto/tutu/tata/titotu/blabla/parts/sections/paragraphs/paragraph32.xml
But as usual. If you're the one coding, you're the one imposing your vision
of the world ;)
Thanks for your time, Mt.
5:41 p.m.
New subject: [Po4a-devel]Re: Translating NEWS.Debian files: a (crude) first try
Hi,
On Fri, 4 Feb 2005, Martin Quinson wrote:
[...]
file:line: (po4a::module)
toto tutu toto tutu toto tutu toto tutu toto tutu toto
toto tutu toto tutu toto tutu toto tutu toto tutu toto
?
It has the advantage of being easily readable. The best would be to use the
following value as indentation offset: >>max(length("$file:$line:
",10))<<
I've just commited an initial version of the new Common module, and it has
basic implementations of wrapping functions:
wrap_mod("po4a:man", "this is a long....") returns:
po4a::man: this is a long message this is a long message this is a long
message this is a long message this is a long message this is a
long message this is a long message this is a long message
wrap_ref_mod("document.sgml:34", "po4a::man", "this is a
long...") returns:
document.sgml:34: (po4a::man)
this is a long message this is a long message this is a long
message this is a long message this is a long message this is
a long message this is a long message this is a long message
I've expanded the maximum length of the space to 15 characters (10 was
shorter than "po4a::man: " ;)
Tomorrow I'll try to integrate this stuff with the other modules.
Regards,
Jordi Vilalta
6:02 p.m.
New subject: [Po4a-devel]Re: Translating NEWS.Debian files: a (crude) first try
On Sat, Feb 05, 2005 at 12:41:50AM +0100, Jordi Vilalta wrote:
I've just commited an initial version of the new Common module,
and it has
basic implementations of wrapping functions:
wrap_mod("po4a:man", "this is a long....") returns:
po4a::man: this is a long message this is a long message this is a long
message this is a long message this is a long message this is a
long message this is a long message this is a long message
wrap_ref_mod("document.sgml:34", "po4a::man", "this is a
long...") returns:
document.sgml:34: (po4a::man)
this is a long message this is a long message this is a long
message this is a long message this is a long message this is
a long message this is a long message this is a long message
Good work, dude.
Thanks, Mt.
8:54 a.m.
New subject: [Po4a-devel]General update
Hi,
I've just commited an update for the modules so that they use the new
wrapping functions. With this, we could close the bug on alioth asking for
gcc-like syntax (I've tried to adapt the messages to show them all with
the same syntax). Please, check that I didn't break your modules.
With this, many messages have changed (around 30). Most of them just
remove the reference of the file, some remove the new-lines (I think it's
easier for translators to not having to deal with new-lines), and others
remove the module reference at the beginning of each line. So, the
translations update should be so fast (it's mainly about removing parts of
the current messages).
Last week I added the po4a project at the Ubuntu Launchpad, and some
people has begun translating it to new languages (with Rosetta, a web
based translating interface):
https://launchpad.ubuntu.com/rosetta/products/po4a/po4a-0.19
Three months have past since the last release and we have support for many
new formats, and some bug fixes. Should we begin thinking on a new release
soon?
Regards,
Jordi Vilalta
6:30 p.m.
New subject: [Po4a-devel]General update
On Sat, 12 Feb 2005, Jordi Vilalta wrote:
I've updated the template and it's now at:
https://launchpad.ubuntu.com/rosetta/products/po4a/po4a-0.20
2:03 a.m.
New subject: [Po4a-devel]Release, and other considerations
Sorry, the email address I was subscribed to most lists went bad without
prior notice, so I was kicked out of the list for a long while. And then,
I'm currently completely overhelmed.
On Sat, Feb 12, 2005 at 03:54:16PM +0100, Jordi Vilalta wrote:
Hi,
I've just commited an update for the modules so that they use the new
wrapping functions. With this, we could close the bug on alioth asking for
gcc-like syntax (I've tried to adapt the messages to show them all with
the same syntax). Please, check that I didn't break your modules.
I've closed the bug, thanks for this.
Last week I added the po4a project at the Ubuntu Launchpad, and some
people has begun translating it to new languages (with Rosetta, a web
based translating interface):
https://launchpad.ubuntu.com/rosetta/products/po4a/po4a-0.19
Cool. Could you drop the fr_FR, fr_BE and de_DE translations? We really
don't need them, I think.
Three months have past since the last release and we have support for
many
new formats, and some bug fixes. Should we begin thinking on a new release
soon?
I strongly second you. Moreover, the email address given as maintainer of
0.19 is my tuxfamily.org one, which is dead. I vote for a rapid upload.
I think that this is Nekral's call. Could we release as is, or you still
have something to fix in TeX ? It's not released yet, but I think it should
since it almost works, if I understood well.
We are not in such a hurry either. If you need another month, that's cool
for me. Next month will be completely crazzy for me anyway. Moving to
another city again, soon a new baby and such.
I think I'll release a 0.19-2 with only my email change so that we can be
more relax about when we release.
Keep up the good work, dudes.
Mt.
6:01 a.m.
New subject: [Po4a-devel]Release, and other considerations
Hi,
On Mon, 14 Feb 2005, Martin Quinson wrote:
On Sat, Feb 12, 2005 at 03:54:16PM +0100, Jordi Vilalta wrote:
> Last week I added the po4a project at the Ubuntu Launchpad, and some
> people has begun translating it to new languages (with Rosetta, a web
> based translating interface):
> https://launchpad.ubuntu.com/rosetta/products/po4a/po4a-0.19
Cool. Could you drop the fr_FR, fr_BE and de_DE translations? We really
don't need them, I think.
Currently it shows them all, no way to remove them. (I also wanted to drop
es_ES)
Regards,
Jordi Vilalta
12:44 p.m.
New subject: [Po4a-devel]Release, and other considerations
Hello Jordi,
Do you know if there is a way to have a look at the PO without a Rosetta
login?
Thanks for submitting po4a to Rosetta.
--
Nekral
4:12 p.m.
New subject: [Po4a-devel]Release, and other considerations
Hi,
On Tue, 15 Feb 2005, Nicolas François wrote:
Do you know if there is a way to have a look at the PO without a
Rosetta
login?
Oops, I've got no idea. I haven't achieved to log out to test it (it's a
bug in the web page).
You can register here: http://www.ubuntulinux.org/join_form
Regards,
Jordi Vilalta
7 a.m.
New subject: [Po4a-devel]Release, and other considerations
Hi,
On Mon, 14 Feb 2005, Martin Quinson wrote:
On Sat, Feb 12, 2005 at 03:54:16PM +0100, Jordi Vilalta wrote:
> Three months have past since the last release and we have support for many
> new formats, and some bug fixes. Should we begin thinking on a new release
> soon?
I strongly second you. Moreover, the email address given as maintainer of
0.19 is my tuxfamily.org one, which is dead. I vote for a rapid upload.
I think that this is Nekral's call. Could we release as is, or you still
have something to fix in TeX ? It's not released yet, but I think it should
since it almost works, if I understood well.
Other modules still not distributed:
* LaTeX & PythonDoc: the same as above. It's Nekral's decision.
* Html: Yves sent some patches, and it seems to work for him. What should
we do with it? (If we distribute it, we also have to distribute the html
test suite)
* Debconf & NewsDebian: What's your feeling about them, Martin?
* Docbook: I think I will push it into the next release. I've seen that
videolan people use a patched xml module, which just adds some inline
tags
(http://developers.videolan.org/cgi-bin/viewcvs.cgi/www.videolan.org/doc/p...),
and that's already done in the docbook module.
* Xml: It still lacks some functionality, but some people are using it
(the videolan people, and the chinese debian-installer team, IIRC).
Well, it's distributed to support the Dia and Guide modules, but it
isn't shown directly. Some people use it anyway, so I think it could be
announced as officialy supported.
I've also been watching the Chooser, and I suggest splitting the list of
modules into separate messages:
sub list {
warn wrap_msg(gettext("List of valid formats:")
."\n - ".gettext("kernelhelp: Help messages of each kernel
compilation option.")
."\n - ".gettext("man: Good old manual page format.")
."\n - ".gettext("pod: Perl Online Documentation format.")
...
This makes it easier for translators to update the translation when we add
a new module.
Another thing. The new wrapping functions require the Text::WrapI18N
module. This should be reflected in the /debian files.
Regards,
Jordi Vilalta
10:36 a.m.
New subject: [Po4a-devel]Release, and other considerations
On Mon, Feb 14, 2005 at 02:00:46PM +0100, Jordi Vilalta wrote:
* Html: Yves sent some patches, and it seems to work for him. What
should
we do with it? (If we distribute it, we also have to distribute the html
test suite)
I don't think it's still in a usable state to be honest.
It's actually barely good enough for my own, limited
purpose. The parsing needs to be changed so that in-line
tags don't create new msgids (as lengthily discussed earlier :) )
which I'm hoping a module I discovered recently should make
easy (HTML::Tree).
Unfortunately I'm looking for a new job in a new country,
moving countries in 40 days, and getting married soon, so my
only chance of having free time will be unemployment in 40
days.
IOW, I'd suggest you go ahead with the release without
changing the status of the html module, i.e. "in
development, get it from CVS". (and whatever new version I
hope to do in the future _will_ break all the po files).
Y.
3:04 p.m.
New subject: [Po4a-devel]Release, and other considerations
On Mon, Feb 14, 2005 at 02:00:46PM +0100, Jordi Vilalta wrote:
Hi,
On Mon, 14 Feb 2005, Martin Quinson wrote:
>On Sat, Feb 12, 2005 at 03:54:16PM +0100, Jordi Vilalta wrote:
>>Three months have past since the last release and we have support for many
>>new formats, and some bug fixes. Should we begin thinking on a new release
>>soon?
>
>I strongly second you. Moreover, the email address given as maintainer of
>0.19 is my tuxfamily.org one, which is dead. I vote for a rapid upload.
I uploaded a version with my email change, so we're more serene.
>I think that this is Nekral's call. Could we release as is,
or you still
>have something to fix in TeX ? It's not released yet, but I think it should
>since it almost works, if I understood well.
Other modules still not distributed:
* LaTeX & PythonDoc: the same as above. It's Nekral's decision.
* Html: Yves sent some patches, and it seems to work for him. What should
we do with it? (If we distribute it, we also have to distribute the html
test suite)
* Debconf & NewsDebian: What's your feeling about them, Martin?
It's better to hide it too for now. It's only a hand tend in Denis
direction. In my mind, he could use it as first draft of a po-debconf based
on po4a and not intl-tools. He decides.
* Docbook: I think I will push it into the next release. I've
seen that
videolan people use a patched xml module, which just adds some inline
tags
(http://developers.videolan.org/cgi-bin/viewcvs.cgi/www.videolan.org/doc/p...),
and that's already done in the docbook module.
Why don't we include this patch, if it's useful to someone? (stupid question)
* Xml: It still lacks some functionality, but some people are using
it
(the videolan people, and the chinese debian-installer team, IIRC).
Well, it's distributed to support the Dia and Guide modules, but it
isn't shown directly. Some people use it anyway, so I think it could be
announced as officialy supported.
I've also been watching the Chooser, and I suggest splitting the list of
modules into separate messages:
sub list {
warn wrap_msg(gettext("List of valid formats:")
."\n - ".gettext("kernelhelp: Help messages of each kernel
compilation option.")
."\n - ".gettext("man: Good old manual page format.")
."\n - ".gettext("pod: Perl Online Documentation format.")
...
This makes it easier for translators to update the translation when we add
a new module.
Agreed.
Another thing. The new wrapping functions require the Text::WrapI18N
module. This should be reflected in the /debian files.
Done, thanks for the reminder.
Thanks, Mt.
3:31 p.m.
New subject: [Po4a-devel]Release, and other considerations
On Mon, 14 Feb 2005, Martin Quinson wrote:
On Mon, Feb 14, 2005 at 02:00:46PM +0100, Jordi Vilalta wrote:
> * Docbook: I think I will push it into the next release. I've seen that
> videolan people use a patched xml module, which just adds some inline
> tags
>
(http://developers.videolan.org/cgi-bin/viewcvs.cgi/www.videolan.org/doc/p...),
> and that's already done in the docbook module.
Why don't we include this patch, if it's useful to someone? (stupid question)
They apply the patch to the generic Xml module. It's included in our
Docbook module.
Regards,
Jordi Vilalta
3 p.m.
New subject: [Po4a-devel]Release, and other considerations
On Mon, Feb 14, 2005 at 09:03:55AM +0100, Martin Quinson wrote:
On Sat, Feb 12, 2005 at 03:54:16PM +0100, Jordi Vilalta wrote:
> Three months have past since the last release and we have support for many
> new formats, and some bug fixes. Should we begin thinking on a new release
> soon?
I strongly second you. Moreover, the email address given as maintainer of
0.19 is my tuxfamily.org one, which is dead. I vote for a rapid upload.
I think that this is Nekral's call. Could we release as is, or you still
have something to fix in TeX ? It's not released yet, but I think it should
since it almost works, if I understood well.
Short version: some small things to commit, I can probably be ready in one
or two weeks.
Long version:
Here is what is mostly lacking to TeX* modules:
- Documentation
(I'm probably the only one who can use them)
I may manage to add a minimal documentation and propose support on the
list
=> This should not stop/delay a release
- tabular environment
It may change users PO in later versions.
I've failed my first try. It may require a design change of the
parser. => This should not stop/delay a release (but may change
its releasable state;)
- Tests
A release could provide these tests. => This should not stop/delay a
relese
- Known bug, not fixed, which may require a design change:
% in verbatim environment are handled as comments
(this is triggered by Python)
=> This should not stop/delay a release (it could be documented)
I've got the feeling that they are not perfect, but "usable".
I may have done an error by committing the PythonDoc module: it is
probably a pure LaTeX module (this only permits to avoid some "% po4a:"
lines)
I've got some updates that I can push now or really soon:
- a "generic" command subroutine, which permits to specify which
arguments have to be translated.
- definitions for all LaTeX2 commands I could find, using this "generic"
command processing
- a way to specify which commands the parser is allowed to separate
(I'm using a '*' prefix for the command)
- handling of unterminated arguments (when an arguments contains an empty
line)
- including files with \input
- adding \clearpage before and after inclusions done by \include
I discovered this while trying to understand why the TOC of Nicolas'
book was modified after a gettextization. (I will stop investigation
on this issue, since manually inserting the file, with and without
\clearpage, also produce the TOC diff)
There is another design issue: I assumed that commands are always followed
by optional arguments and then by mandatory arguments. This is wrong: some
are followed by arguments between parenthesis (e.g. dashbox); some have
optional arguments preceded by mandatory arguments (e.g. newcommand,
savebox). I have an idea on how to fix this, but this will change the way
user provide "generic" commands (this should not produce any PO diff).
That's all folks!
To conclude, I advocate for a release (maybe with a 20-1 ;), and think
the LaTeX module can be included (with TeX). I need to test the Python
Documentation with the LaTeX module, and see if there really are some
Python specific commands.
We are not in such a hurry either. If you need another month,
that's cool
for me. Next month will be completely crazzy for me anyway. Moving to
another city again, soon a new baby and such.
congratulations!
--
Nekral
5:06 p.m.
New subject: [Po4a-devel]Release, and other considerations
Hi,
Here is a status update of the TeX related modules.
On Tue, Feb 15, 2005 at 10:00:47PM +0100, Nicolas François wrote:
Short version: some small things to commit, I can probably be ready
in one
or two weeks.
I still think it's feasible for the end of this week-end.
Long version:
Here is what is mostly lacking to TeX* modules:
- Documentation
(I'm probably the only one who can use them)
I may manage to add a minimal documentation and propose support on the
list
=> This should not stop/delay a release
I've documented some parts. More documentation is probably needed, but it
should be sufficient for stating working with the LaTeX module.
- tabular environment
It may change users PO in later versions.
I've failed my first try. It may require a design change of the
parser. => This should not stop/delay a release (but may change
its releasable state;)
Not done, won't be done in a short period of time.
- Tests
A release could provide these tests. => This should not stop/delay a
relese
- Known bug, not fixed, which may require a design change:
% in verbatim environment are handled as comments
(this is triggered by Python)
=> This should not stop/delay a release (it could be documented)
It was more nasty than expected. I decided to fix it now.
I will commit tomorrow.
Another big patch will be committed: I'm using generic commands for most
of the LaTeX module commands. Since I'm using it since 2 week without
problem, I think it is OK.
I may have done an error by committing the PythonDoc module: it is
probably a pure LaTeX module (this only permits to avoid some "% po4a:"
lines)
Yes, this module should not be released (I'm thinking about removing it).
There is another design issue: I assumed that commands are always
followed
by optional arguments and then by mandatory arguments. This is wrong: some
are followed by arguments between parenthesis (e.g. dashbox); some have
optional arguments preceded by mandatory arguments (e.g. newcommand,
savebox). I have an idea on how to fix this, but this will change the way
user provide "generic" commands (this should not produce any PO diff).
Maybe this will be for 0.21
Others points related to the release:
- The french translation need to be updated
(I nobody has time to do this, maybe we can plan a 0.20.1)
- Jordi raised an issue with the man module
- taking translations from Rosetta
I still believe the TeX and LaTeX could be released with 0.20, but would
like another opinion (there's probably more bugs than in the NewsDebian or
Xml modules).
By the way, if you have any pointer to another book written in LaTeX, I'm
interested.
Kind Regards,
--
Nekral
3:20 p.m.
New subject: [Po4a-devel]Release, and other considerations
El día Fri, Feb 25, 2005, Nicolas François <nicolas.francois(a)centraliens.net>
escribió:
By the way, if you have any pointer to another book written in LaTeX,
I'm
interested.
Well, OFSET's Freeduc-doc is going to create its documentation with
hyperlatex.
http://www.ofset.org/freeduc-doc
http://www.ofset.org:8080/freeduc-doc
http://linux5.cc.ntu.edu.tw/~freeduc-dev/translation.html
As I mean to work on the Spanish translation it could be a good
testing experiment.
--
jr <juanrafael.fernandez at hispalinux.es>
# gpg --keyserver wwwkeys.pgp.net --recv-keys 0D709914
2:10 p.m.
New subject: [Po4a-devel]LaTeX module test on freeduc documentation
Hi,
On Sun, Mar 06, 2005 at 10:20:48PM +0100, juanrafael.fernandez(a)hispalinux.es wrote:
El día Fri, Feb 25, 2005, Nicolas François
<nicolas.francois(a)centraliens.net> escribió:
> By the way, if you have any pointer to another book written in LaTeX, I'm
> interested.
Well, OFSET's Freeduc-doc is going to create its documentation with
hyperlatex.
http://www.ofset.org/freeduc-doc
http://www.ofset.org:8080/freeduc-doc
http://linux5.cc.ntu.edu.tw/~freeduc-dev/translation.html
Thanks for the pointers. I will give it a try, and post results here.
It seems there is mostly French LaTeX files. Is This correct?
Is French the master language for other translations?
Regards,
--
Nekral
3:27 p.m.
New subject: [Po4a-devel]LaTeX module test on freeduc documentation
> OFSET's Freeduc-doc
It seems there is mostly French LaTeX files. Is This correct?
For the moment (there will be English, Italian, Chinese and Spanish, I hope).
Is French the master language for other translations?
Not necessarily, but in practise yes. First `granule' accepted (piece
of documentation about an application) is the `master granule'. And
most authors of documentation are French. Besides, we don't have many
Chinese translators :-).
--
jr <juanrafael.fernandez at hispalinux.es>
# gpg --keyserver wwwkeys.pgp.net --recv-keys 0D709914
3:46 p.m.
New subject: [Po4a-devel]LaTeX module test on freeduc documentation
Hello Juan Rafael,
I gave it a try.
I already encountered a bug:
macro.tex, line 14, contains:
\xml*{table width="100%" cellpadding=0 cellspacing=2}\xml{tr}
the '%' here is quite disturbing for the TeX parser, which consider the
end of the line as a comment, thus miss a closing }, and thus spend most
of its time on is_closed and cannot separate paragraphs for the following
files.
I will have to add another category of commands.
Does the xml command behave like a verbatim block?
What appens if there is an end of line inside an xml command argument? (is
it reproduced in the output document?)
But anyway, after removing the % sign (or change it to
PERCENT_SIGN_TO_RESTORE not to forgot it), I could use the tex files.
Here is the command I use (in the fr directory, after executing the
all-in-one.sh script):
TEXINPUTS=/usr/share/texmf/tex/latex/base \
PERLLIB=/home/fzt/sources/po4a/cvs/lib \
/home/fzt/sources/po4a/cvs/po4a-gettextize -f latex -m book.tex \
-p freeduc.pot -o exclude_include=content-fr:application-fr \
-M ISO-8859-1
Some explanations:
TEXINPUTS: needed because of the book documentclass.
documentclass files are read because they are allowed to contain
"% po4a:" line for the po4a parser.
=>I will change this in order to just warn if the document class is not
found.
PERLLIB: not needed if po4a is installed. I wanted to test cvs version
(currently equal to the released one)
-f latex: use the LaTeX parser
-m book.tex: indicate the parser to use this document as input. It will
find the other included document (i.e. granules and other files)
-p freeduc.pot: the generated PO file
-o exclude_include=content-fr:application-fr:
book.tex contains a \input{content-fr}, but I could not find or
generate it. So I indicated po4a that it should not try to include it
on the fly.
-M ISO-8859-1
I also added the following lines in macro.tex file:
% po4a: environment ifhtml push_environment
% po4a: environment iftex push_environment
The freeduc.pot PO file was generated without any more difficulty.
I will now start adding "%po4a: command" line to describe the behavior of
the unknown commands.
I will send the diff with the macro.tex file once it will be ready.
Then I will have a look at the differences between the french book.pdf and
the one translated by po4a (without translation, so still in French).
Kind Regards,
--
Nekral
3:42 p.m.
New subject: [Po4a-devel]LaTeX module test on freeduc documentation
Hello,
Here is the patch to the freeduc-doc cvs that permits to handle the TeX
documentation.
It is quite small.
The modification in xfig.tex is needed because a an \item is followed by:
{\small ...}
This is probably perfectly correct, but the parser take it for an
argument, whereas I specified the \item command as only having an optional
argument.
The patch specifies temporarily that the \item command can have any number
of mandatory arguments which are all translated.
This could probably be safely specified with the other commands, but I
wanted to play and test if the command definitions could be used to
define temporary behavior.
After applying this patch, po4a deals like a charm with this LaTeX
documentation. (with the exception of the % in the xml command)
Regarding the xml command, I will try to add the ability to specify
commands with the same behavior as the verbatim environment (no rewrap,
and no comments). At this time, a workaround could be to specify the new
HlxTopPanel command in a separate file, excluded from the po4a inclusion
(or excluding the macro.tex file, and translating it manualy).
The translation, once the PO file is translated is obtained by:
TEXINPUTS=/usr/share/texmf/tex/latex/base \
PERLLIB=/home/fzt/sources/po4a/cvs/lib \
/home/fzt/sources/po4a/cvs/po4a-translate -f latex -m book.tex \
-p freeduc.pot -o exclude_include=content-fr:application-fr \
-M ISO-8859-1 \
-l book-po4a.tex -L ISO-8859-1
The -l switch specifies where the translated document is output,
and the -L switch, its encoding.
Note: A patch for the Transtractor is available on the CVS
an additional -k 0 switch can be added to test the translation when only a
small part of the PO is translated.
I had a look at the PO file, it seems quite nice to me (strings are not
too much split, not too much grouped).
You will find itemize paragraphs very ugly. I have locally a patch that
permits to translate separately each items. It also permits to split cells
in tabular environments or commands like authors where \\ permits to
separate different fields.
A last concern:
It seems the freeduc-doc project has multiple master languages.
This may be more difficult to handle than translation from a single
language. The po4a command provided previously permits to translate
the French document into another language, and generates a single
book-<lang>.tex document. In order to translate granules (the LaTeX
chapters found in different files) from different languages, it could be
better to translate each granule separately. This could be done by adding
this line in every granules:
\input{po4a-definitions}
and having all the po4a definitions ("% po4a: " line) in this
po4a-definitions.tex file.
A po4a config file could then be used to ease translator's life (less
commands, more reuse of translations)
Best Regards,
--
Nekral
3:18 p.m.
New subject: [Po4a-devel]Re: Translating NEWS.Debian files: a (crude) first try
On Thu, Feb 03, 2005 at 04:42:07PM +0100, Jordi Vilalta wrote:
Hello,
On Tue, 1 Feb 2005, Jordi Vilalta wrote:
>I might be wrong, but I think it's time to create a new module with common
>functions used by several scripts, like the config file loading, or a
>function to show wrapped messages using the proposed syntax in
>https://alioth.debian.org/tracker/index.php?func=detail&aid=300889&group_id=30267&atid=410622
>
>Any ideas about this? What name should it take? (Common, Utils, Tools,
>...?)
I've begun working on it (with the temporary name "Common").
Cool! Thanks.
While moving common parts of the scripts to this module, I've
found an
undocumented option in the po4a script: split. What does it do? It adds a
big amount of code. Should it be documented or is it there just for testing?
No, it's an attempt to keep all the strings in separate po files,
corresponding each to a given master file. But after this try, I realized
that it is impossible to merge the files back after a modification. I cannot
guess which of the proposed translations is the old one and which is the
brand new reviewed one. So, we have to put all translations in the same po
file (and kill this dead code).
hmm, I'm now thinking on posponing these big moves and
concentrating in the
gcc-like syntax/wrapping stuff.
You're coding, you're the boss.
Mt.
3:57 p.m.
New subject: [Po4a-devel]Re: Translating NEWS.Debian files: a (crude) first try
Hi
On Fri, Feb 04, 2005 at 10:18:12PM +0100, Martin Quinson wrote:
> While moving common parts of the scripts to this module,
I've found an
> undocumented option in the po4a script: split. What does it do? It adds a
> big amount of code. Should it be documented or is it there just for testing?
No, it's an attempt to keep all the strings in separate po files,
corresponding each to a given master file. But after this try, I realized
that it is impossible to merge the files back after a modification. I cannot
guess which of the proposed translations is the old one and which is the
brand new reviewed one. So, we have to put all translations in the same po
file (and kill this dead code).
I concur.
For some manpages translations, I was asked to split the big PO in smaller
ones. I used a small script to split, and merged with msgmerge -N (but
had to manually check the results after re-splitting).
Splitting may be convenient, but the merge is error prone and has to be
done manually.
--
Nekral
7192
days inactive
7231
days old
24 comments
6 participants
participants (6)
-
Denis Barbier -
Jordi Vilalta -
juanrafael.fernandez＠hispalinux.es -
Martin Quinson -
Nicolas François -
Yves Rutschle