4:59 a.m.
I am putting po4a in place for the translation of the Wine
documentation. Pretty much the only issue is that the text generated by
DocBook itself, 'Table of Contents' for instance, is not translated. The
reason is that the language to use for this text is defined by the
'lang' attribute as in:
<book lang="en">
...
</book>
But the value of the lang attribute is passed as is by po4a-translate. I
checked the Sgml.pm module and indeed it does not have any provision for
translating attributes :-(
It looks like it should be done near this code (line 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;
}
Unfortunately that's as far as I got and now I don't have any idea on
how to modify this code to add this functionality. Maybe if someone can
provide me some pointers...
--
Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/
May your Tongue stick to the Roof of your Mouth with the Force of a Thousand Caramels.
2:34 a.m.
On Thu, May 19, 2005 at 11:59:52AM +0200, Francois Gouget wrote:
Yes, that would be here. Something like:
if (lc($attr) eq "lang") {
$tag .= ' '.lc($attr).'='.$NEWLANG;
} else {
$tag .= ' '.lc($attr).'='.$value;
}
Not necessary really clean and robust, but working, I *guess*. But do you
know where we can get NEWLANG from? I don't remember of having this
information explecitely anywhere in po4a. we use to use this info as
rootname for the po files, but nothing enforces this until now. Maybe a new
module option?
Bye, Mt.
6:32 a.m.
Martin Quinson wrote:
[...]
Thanks for the hint. I started from here and looked at what Xml.pm was
doing and I think I have a solution. This turned out to be simpler than
I expected, but then maybe I missed something.
Not necessary really clean and robust, but working, I *guess*. But do
you
know where we can get NEWLANG from?
The Xml.pm module simply creates an msgid with the lang value and lets
the translator provide the new value. In fact it has a list of
attributes that need translation so that one can provide translations
for arbitrary attributes.
I think this approach makes sense so here is what I did:
* I added a new 'attribute' 'tag kind'. I know that and attribute is
not a tag but this lets me reuse the framework.
* I added support for an 'attribute' option which lets the user expand
the list of attributes that need to be translated. It works exactly like
the existing 'translate', 'section', 'indent', etc. options...
* For the DocBook document type I added 'lang' to the 'attribute' list.
* And finally near line 690 I translate the attribute value if its
name is in the %attribute hash.
There's one thing that Xml.pm supports that this does not support:
Xml.pm lets you specify that an attribute must only be translated if it
is found in a specific tag list:
You can specify the attributes by their name (for example, "lang"),
but you can prefix it with a tag hierarchy, to specify that this
attribute will only be translated when it's into the specified tag.
For example: <bbb><aaa>lang specifies that the lang attribute will
only be translated if it's into an <aaa> tag, and it's into a
<bbb>
tag.
I think this functionality can be added later if needed. For now it
seems mostly overkill to me.
There is another aspect that could be criticised: the patch will
typically result in the following msgid:
msgid "en"
msgstr "fr"
That can be a bit ambiguous. Maybe the documentation has an 'en' that
needs to be translated differently somewhere else. If it is felt that
this is an issue it would be pretty easy to modify the patch so that the
msgid reads as follows:
msgid "lang=en"
msgstr "lang=fr"
This could be done with the following (untested) code:
if ($attribute{uc($attr)})
{
my $name=lc($attr);
my $translated = $self->translate("$name=$value", "",
"attribute
".lc($attr));
if ($translated =~ s/^$name=//)
{
$value=$translated;
}
else
{
print "warning bad translation for...";
}
}
Note that this code should not have any quoting issue.
Let me know if you prefer this alternate version. In that case it would
be best to modify Xml.pm in the same way to keep things consistent.
Changelog:
* lib/Locale/Po4a/Sgml.pm
Francois Gouget <fgouget(a)codeweavers.com>
Add support for translating attribute values.
--
Francois Gouget
fgouget(a)codeweavers.com
Index: lib/Locale/Po4a/Sgml.pm
===================================================================
RCS file: /cvsroot/po4a/po4a/lib/Locale/Po4a/Sgml.pm,v
retrieving revision 1.57
diff -u -p -r1.57 Sgml.pm
--- lib/Locale/Po4a/Sgml.pm 25 May 2005 16:55:20 -0000 1.57
+++ lib/Locale/Po4a/Sgml.pm 26 May 2005 10:44:59 -0000
@@ -82,6 +82,10 @@ they can be part of an msgid. For exampl
for this category since putting it in the translate section would create
msgids not being whole sentences, which is bad.
+=item attribute
+
+A space separated list of attributes that need to be translated.
+
=item force
Proceed even if the DTD is unknown.
@@ -274,13 +286,13 @@ sub set_tags_kind {
my $self=shift;
my (%kinds)=@_;
- foreach (qw(translate empty section verbatim ignore)) {
+ foreach (qw(translate empty section verbatim ignore attribute)) {
$self->{SGML}->{k}{$_} = $self->{options}{$_} ? $self->{options}{$_}.'
' : '';
}
foreach (keys %kinds) {
die "po4a::sgml: internal error: set_tags_kind called with unrecognized arg
$_"
- if ($_ !~ /^(translate|empty|verbatim|ignore|indent)$/);
+ if ($_ !~ /^(translate|empty|verbatim|ignore|indent|attribute)$/);
$self->{SGML}->{k}{$_} .= $kinds{$_};
}
@@ -426,7 +438,8 @@ sub parse_file {
"varname ".
"wordasword ".
"xref ".
- "year");
+ "year",
+ "attribute" => "lang");
} else {
if ($self->{options}{'force'}) {
@@ -616,7 +629,7 @@ sub parse_file {
open (IN,$cmd) || die wrap_mod("po4a::sgml", dgettext("po4a",
"Can't run nsgmls: %s"), $!);
# The kind of tags
- my (%translate,%empty,%verbatim,%indent,%exist);
+ my (%translate,%empty,%verbatim,%indent,%exist,%attribute);
foreach (split(/ /, ($self->{SGML}->{k}{'translate'}||'') )) {
$translate{uc $_} = 1;
$indent{uc $_} = 1;
@@ -639,7 +652,10 @@ sub parse_file {
foreach (split(/ /, ($self->{SGML}->{k}{'ignore'}) || '')) {
$exist{uc $_} = 1;
}
-
+ foreach (split(/ /, ($self->{SGML}->{k}{'attribute'}) || ''))
{
+ $attribute{uc $_} = 1;
+ }
+
# What to do before parsing
@@ -704,6 +720,10 @@ sub parse_file {
if ($val->type() eq 'CDATA' ||
$val->type() eq 'IMPLIED') {
if (defined $value && length($value)) {
+ if ($attribute{uc($attr)})
+ {
+ $value = $self->translate($value, "",
"attribute ".lc($attr));
+ }
if ($value =~ m/"/) { #"
$value = "'".$value."'";
} else {
9:30 a.m.
On Thu, May 26, 2005 at 01:32:27PM +0200, Francois Gouget wrote:
Well. That may be an issue. In html, some attibutes need to be translated
when in a specific tag and not in others. I think we don't need to keep the
whole stack, but the embeeding tag seem important to me.
Maybe change $attribute{uc $_} to an array of embeeding tags?
That's why you did add a comment in the po file using the last arguments of
the translate function (or you should :).
Maybe the documentation has an 'en' that needs to be
translated
differently somewhere else.
That's more problematic.
Well. Why not? We could then translate the whole tag, something like:
# Please translate the lang attribute
msgid "<book lang=en>"
msgstr "<book lang=fr>"
If it's feasible, it'd be even better.
I didn't commit it yet. I prefer to discuss it a bit further, if you don't
mind.
12:32 p.m.
Martin Quinson wrote:
[...]
But does the Sgml module actually support Html? I did not see it in the
'$prolog' switch. Which attributes need to be translated in Html?
[...]
[...]
Maybe change $attribute{uc $_} to an array of embeeding tags?
Or rather a hashtable so we can do check on the embedding tag name like
this:
if ($attribute{$attr}->{""} or
$attribute{$attr}->{$event->data->name()})
With {""} catching the case where we we translate the attribute for all
tags.
Hmm, I have just realised that in DocBook the 'lang' tag is a common
attribute which means it can be put on any tag. This means it would be a
good idea to make it possible to restrict its translation to specific
tag hierarchies :-(
[...]
A given tag may have more than one attribute that needs to be translated
and also one or more attributes that don't need to be translated. I'm
not sure it would be a good idea to translate them all together.
Part of the issue in deciding this is to see what other attributes would
need to be translated. For DocBook I can't think of any.
I didn't commit it yet. I prefer to discuss it a bit further, if
you don't
mind.
No problem.
--
Francois Gouget
fgouget(a)codeweavers.com
2:15 p.m.
On Thu, May 26, 2005 at 07:32:10PM +0200, Francois Gouget wrote:
Not yet, actually. But it could/should. The main blocker was the need to
translate a bunch of attributes. Now that it's possible, it opens the way to
a proper html support in po4a (note that xhtml is already supported by
xml.pm, if I remember well).
The "value" attribute of <submit> have to be translated since it's
the
button label. But it shouldn't be translated elsewhere as in radio buttons
(I can't remember the tag name right now). It would even be *bad* to
translate them in there since it would break CGI scripts and such.
[...]
You are right. Let's stick to
>>># Please translate the lang attribute of the book tag
>>msgid "lang=en"
>>msgstr "lang=fr"
, then. I feel concerned about the value (like "en") being used elsewhere,
even if it's quite unprobable given the fact that po4a tries to translate
whole paragraphs. But two tag attributes may need different translations in
some catastrophic settings.
Thanks for your time,
Mt.
7257
days inactive
7266
days old
5 comments
3 participants
participants (3)
-
Francois Gouget -
Francois Gouget -
Martin Quinson