I requested that <indexterm> be translatable even outside of translatables tags (see https://bugzilla.redhat.com/show_bug.cgi?id=582255). While implementing my request this change was apparently introduced.

But I agree with you, it should not split a paragraph or any other translatable tag that contains an <indexterm>.

As this bug affect the readability and clarity of the strings to be translated, leaving half phrases out of context, I have increase the severity of this bug.

Created attachment 415618 [details]
Proposed patch

The attached patch adds indexterm to IGNOREBLOCKS so that it doesn't split translatable tags like it does currently.

Hum somehow this doesn't work as expected. <indexterm> is no longer caught outside of translatable tags with this patch despite the fact that it's still listed in $TRANSTAGS.

Trying to fix this, I discovered that's because $node->look_up() (from XML::Element) would happily return the element itself. So the following change is also needed:
@@ -335,7 +335,7 @@ sub get_msgs {
             qr/$TRANSTAGS/,
             sub {
                 not defined(
-                    $_[0]->look_up(
+                    $_[0]->parent()->look_up(
                         '_tag',
                         qr/$IGNOREBLOCKS/,
                         sub {

With this, <indexterm> doesn't split the <para> anymore but it still doesn't appear in the translation string of the para, it has its own string. This might be ok but I have not been able to find the proper way to keep it inline. I'm not sure whether the above change has other undesired side-effects.

Hi Raphaël, which tree are you creating your patch against? There is already a patch for this checked in on the 1.6 branch, it's waiting for testing before this bug can be updated.

Gah, I just noticed this is still in new ... more coffee needed :(

Fixed in build 1.6.3-0.f12.t67

Hi Jeff, my patch was against the 1.6.3 tarball.

So this bug is fixed by r1215 and is in fact the same than https://bugzilla.redhat.com/show_bug.cgi?id=592666 if I understand correctly. You might want to merge both entries then.

Change Product to RHEL6, since this affects all the documents to be used in RHEL6.

This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.

Confirmed that Publican 1.99.t135 doesn't break the string. 

Given this XML:

<para>
This is a test <indexterm><primary>paragraph</primary></indexterm> paragraph in a section
</para>

the resulting PO file entry is:

#. Tag: para
#, no-c-format
msgid "This is a test <indexterm><primary>paragraph</primary></indexterm> paragraph in a section"
msgstr ""


Chester, could you please confirm that this is suitable?

Hi Rudi,

Yes, it is suitable.

Cheers,
Chester

(In reply to comment #12)
> Confirmed that Publican 1.99.t135 doesn't break the string. 
> 
> Given this XML:
> 
> <para>
> This is a test <indexterm><primary>paragraph</primary></indexterm> paragraph in
> a section
> </para>
> 
> the resulting PO file entry is:
> 
> #. Tag: para
> #, no-c-format
> msgid "This is a test <indexterm><primary>paragraph</primary></indexterm>
> paragraph in a section"
> msgstr ""
> 
> 
> Chester, could you please confirm that this is suitable?

publican-2.1-0.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.

publican-2.1-0.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.

Verified: publican-2.1-0.el6.x86_64

Build doc using publican, added xml from comment#12 , po updated as per Chester's orig description.

Output as described / approved in comment#13

#. Tag: para
#, no-c-format
msgid "This is a test <indexterm><primary>paragraph</primary></indexterm> paragraph in a section"
msgstr ""

Red Hat Enterprise Linux 6.0 is now available and should resolve
the problem described in this bug report. This report is therefore being closed
with a resolution of CURRENTRELEASE. You may reopen this bug report if the
solution does not work for you.