11:37 a.m.
Hi all,
It looks like my spare time has shrunk further, hence my
long silence. Martin's last comments, and my spending some
time reading Sgml.pm and Xml.pm, along with running into
harder files from my site, have me almost convinced that
Martin is right and Html.pm is going the wrong way.
Here is the patch to it that I currently use. This brings it
to state in which it is useful for "simple" files (i.e.
files with simple paragraphs, little in-line formatting),
which I think still is useful for sites that contain a lot
of simple text (how-to's, for example, would be good
candidates if they used html as their primary format).
It doesn't change the fundamentals of its working, so all of
Martin's objections still hold true. Rather, it fixes the
module's shortcomings:
* Paragraphs are now spit along paragraphs, instead of
random 512-byte-aligned boundaries,
* title and alt attribute contents now create msgids.
I hope to get some time to play with Sgml.pm and Xml.pm soon
(because, let's face it, it's much more fun than actually
doing translations).
Y.
1:58 p.m.
On Wed, Nov 24, 2004 at 05:37:31PM +0000, Yves Rutschle wrote:
Hi all,
It looks like my spare time has shrunk further, hence my
long silence. Martin's last comments, and my spending some
time reading Sgml.pm and Xml.pm, along with running into
harder files from my site, have me almost convinced that
Martin is right and Html.pm is going the wrong way.
Here is the patch to it that I currently use. This brings it
to state in which it is useful for "simple" files (i.e.
files with simple paragraphs, little in-line formatting),
which I think still is useful for sites that contain a lot
of simple text (how-to's, for example, would be good
candidates if they used html as their primary format).
Can you please send a test file, so that we can
1. See which files can currently be processed.
2. Make sure that future changes in other parts do not break
your work.
If you can write tests directly under the t/ directory, that would
be great, otherwise simply send files and we will package then.
Denis
9:03 p.m.
On Wed, Nov 24, 2004 at 08:58:10PM +0100, Denis Barbier wrote:
Can you please send a test file, so that we can
1. See which files can currently be processed.
2. Make sure that future changes in other parts do not break
your work.
Woha, you're making me work in a stricter environment than
my workplace :-)
Ok, I'm getting my head around the whole testing stuff right
now. My first impression is that quite some code could be
consolidated (Dia.pm and Xml.pm are essentially the same
thing).
For the sake of testing, it'd be convenient to fill all the
msgstr of an empty PO file with a copy of the msgid. That
way, you can apply the PO to the original file, and check it
looks the same (through whatever kind of browser is relevant
to the format). Does such a tool exist? If not, would one be
welcome in po4a?
Y.
5:18 a.m.
On Sat, Nov 27, 2004 at 03:03:41AM +0000, Yves Rutschle wrote:
On Wed, Nov 24, 2004 at 08:58:10PM +0100, Denis Barbier wrote:
> Can you please send a test file, so that we can
> 1. See which files can currently be processed.
> 2. Make sure that future changes in other parts do not break
> your work.
Woha, you're making me work in a stricter environment than
my workplace :-)
Ok, I'm getting my head around the whole testing stuff right
now. My first impression is that quite some code could be
consolidated (Dia.pm and Xml.pm are essentially the same
thing).
Don't get me wrong, the problem with this HTML module is that few
people are interested in using it, thus adding tests seems to be
the only way to prevent us from making incompatible changes in
other parts of po4a. I did not write any single test here, so I
can not give lessons on good software practice ;)
For the sake of testing, it'd be convenient to fill all the
msgstr of an empty PO file with a copy of the msgid. That
way, you can apply the PO to the original file, and check it
looks the same (through whatever kind of browser is relevant
to the format). Does such a tool exist? If not, would one be
welcome in po4a?
See msgen, but I am not sure that it will be helpful here,
will have a closer look later.
Denis
6:43 a.m.
Hi,
On Sat, 27 Nov 2004, Yves Rutschle wrote:
For the sake of testing, it'd be convenient to fill all the
msgstr of an empty PO file with a copy of the msgid. That
way, you can apply the PO to the original file, and check it
looks the same (through whatever kind of browser is relevant
to the format). Does such a tool exist? If not, would one be
welcome in po4a?
I think you should have a look at po4a-normalize. It parses the document
and writes it back without translating anything.
Regards,
Jordi Vilalta
9:54 a.m.
On Sat, Nov 27, 2004 at 01:43:50PM +0100, Jordi Vilalta wrote:
Hi,
On Sat, 27 Nov 2004, Yves Rutschle wrote:
>For the sake of testing, it'd be convenient to fill all the
>msgstr of an empty PO file with a copy of the msgid. That
>way, you can apply the PO to the original file, and check it
>looks the same (through whatever kind of browser is relevant
>to the format). Does such a tool exist? If not, would one be
>welcome in po4a?
I think you should have a look at po4a-normalize. It parses the document
and writes it back without translating anything.
yeah, po4a-normalize is exactly what you describe. It is called that way
because the sgml module reindent the source, so after a run through
-normalize, the source file is supposed to look better.
But I now stop to rewrite the man page:
The "po4a-normalize" script is a debugging tool used to make sure that
po4a don't change the document when it's not supposed to. Only use it if
you're developping a new module, or if you doubt the sanity of the tools.
Bye, Mt.
10:36 p.m.
On Wed, Nov 24, 2004 at 05:37:31PM +0000, Yves Rutschle wrote:
Hi all,
It looks like my spare time has shrunk further, hence my
long silence. Martin's last comments, and my spending some
time reading Sgml.pm and Xml.pm, along with running into
harder files from my site, have me almost convinced that
Martin is right and Html.pm is going the wrong way.
Good point ;)
Here is the patch to it that I currently use. This brings it
to state in which it is useful for "simple" files (i.e.
files with simple paragraphs, little in-line formatting),
which I think still is useful for sites that contain a lot
of simple text (how-to's, for example, would be good
candidates if they used html as their primary format).
AFAIK, they use sgml or xml, but I understand what you mean
It doesn't change the fundamentals of its working, so all of
Martin's objections still hold true. Rather, it fixes the
module's shortcomings:
* Paragraphs are now spit along paragraphs, instead of
random 512-byte-aligned boundaries,
* title and alt attribute contents now create msgids.
This does not makes me think about including this module as is in the next
release, but I agree that these changes should be commited. There is no net
in these train. Please someone, commit this.
I hope to get some time to play with Sgml.pm and Xml.pm soon
(because, let's face it, it's much more fun than actually
doing translations).
100% agreed :)
Mt.
8:07 a.m.
Hello Yves,
Here are some comments.
On Wed, Nov 24, 2004 at 05:37:31PM +0000, Yves Rutschle wrote:
@@ -97,14 +99,36 @@
# $encoded = HTML::Entities::encode($a);
# $decoded = HTML::Entities::decode($a);
#print STDERR $token->[0];
- $self->pushline( " ".$self->translate($text,
+ $self->pushline( $self->translate($text,
"FIXME:0",
(scalar @type ? $type[scalar @type-1]:
"NOTYPE")
- )." " );
+ ),
+ 'wrap' => 1
+ );
I don't know why the string was surrounded by spaces. Do you think it may
be important? Is it related to the correction of the trim function?
(in the later case, just forget about the first question)
next NEXT;
} elsif ($token->[0] eq 'S') {
push @type,$token->[1];
- $self->pushline( get_tag( $token ) );
+ my $text = get_tag( $token );
+ if ( $token->[1] eq 'img' ) {
+ my %foo = %{$token->[2]};
+ my $title = (exists
$foo{"title"}?$foo{"title"}:"")."\n";
+ my $alt = (exists
$foo{"alt"}?$foo{"alt"}:"")."\n";
+ for my $attr ($title, $alt) {
+ if (defined $attr) {
+ $attr = trim($attr),
+ my $translated = $self->translate(
+ $attr,
+ "FIXME:0",
+ (scalar @type?
+ $type[scalar @type-1]:
+ "NOTYPE")
+ );
The type could be set to either "title" or "alt".
+ $attr = quotemeta $attr;
+ $text =~ s/$attr/$translated/;
Is it possible to only
change the attribute?
(change it in the %foo hash, and reconstruct $text afterwards)
I'm worried about something like:
<img src="http://nekral.homelinux.net/foo" title="home"
alt="nekral">
(and %foo could be renamed %attributes, or something like that)
Regards,
--
Nekral
3:37 p.m.
On Fri, Nov 26, 2004 at 03:07:11PM +0100, Nicolas François wrote:
> @@ -97,14 +99,36 @@
> # $encoded = HTML::Entities::encode($a);
> # $decoded = HTML::Entities::decode($a);
> #print STDERR $token->[0];
> - $self->pushline( " ".$self->translate($text,
> + $self->pushline( $self->translate($text,
> "FIXME:0",
> (scalar @type ? $type[scalar @type-1]:
"NOTYPE")
> - )." " );
> + ),
> + 'wrap' => 1
> + );
I don't know why the string was surrounded by spaces. Do you think it may
be important? Is it related to the correction of the trim function?
(in the later case, just forget about the first question)
I think it was an attempt to do so, but either didn't work
well or was better done with the changes I did to the trim
function (I don't remember). However, your comment made me
noticed that the module joins lines without leaving a space,
which is wrong (in HTML a newline is equivalent to a space).
I'll make sure to introduce relevant cases to the test that
I'm about to write (as soon as I work out how).
> next NEXT;
> } elsif ($token->[0] eq 'S') {
> push @type,$token->[1];
> - $self->pushline( get_tag( $token ) );
> + my $text = get_tag( $token );
> + if ( $token->[1] eq 'img' ) {
> + my %foo = %{$token->[2]};
> + my $title = (exists
$foo{"title"}?$foo{"title"}:"")."\n";
> + my $alt = (exists
$foo{"alt"}?$foo{"alt"}:"")."\n";
> + for my $attr ($title, $alt) {
> + if (defined $attr) {
> + $attr = trim($attr),
> + my $translated = $self->translate(
> + $attr,
> + "FIXME:0",
> + (scalar @type?
> + $type[scalar @type-1]:
> + "NOTYPE")
> + );
The type could be set to either "title" or "alt".
Indeed, or rather $tag_title (e.g. "img_title", otherwise
it could be confused for the content of <title>). Thanks, I
now what the type is about :-)
> + $attr = quotemeta $attr;
> + $text =~ s/$attr/$translated/;
Is it possible to only change the attribute?
(change it in the %foo hash, and reconstruct $text afterwards)
I'm worried about something like:
<img src="http://nekral.homelinux.net/foo" title="home"
alt="nekral">
Indeed. I went for the fastest way, which must be wrong :-)
I'll add that to the test as well.
(and %foo could be renamed %attributes, or something like that)
Yeah, we don't want to waste such an important symbol to
something as mundane as a temporary variable :-)
Y.
7297
days inactive
7302
days old
8 comments
5 participants
participants (5)
-
Denis Barbier -
Jordi Vilalta -
Martin Quinson -
Nicolas François -
Yves Rutschle