On Thu, May 26, 2005 at 01:32:27PM +0200, Francois Gouget wrote:
Martin Quinson wrote:
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.
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.
@@ -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
Maybe change $attribute{uc $_} to an array of embeeding tags?
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.
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.
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"
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.