Bug 571633

Summary: Publican delete the new lines on the screen Tags when creating POTs
Product: [Community] Publican Reporter: Manuel Ospina <mospina>
Component: publicanAssignee: Michael Hideo <mhideo>
Status: CLOSED ERRATA QA Contact: Joshua Wulf <jwulf>
Severity: medium Docs Contact:
Priority: low    
Version: 2.0CC: jfearn, lcarlon, mmcallis, publican-list, yshao
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: 1.6.1 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-03-24 00:53:31 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
This script finds screen elements nested inside para elements up to 5 deep none

Description Manuel Ospina 2010-03-09 04:22:31 UTC
Description of problem:
Publican delete the new lines on the screen Tags when creating POT files. When building the localized versions, the content of the screen tag looks different.

Version-Release number of selected component (if applicable): 1.6


How reproducible: Always


Steps to Reproduce:
1. publican update_pot
2.
3.
  
Actual results:
Therefore, to install all packages but "
"conflicting packages, the kickstart file must contain: <screen> %packages "
"@Everything -@Conflicts </screen>"

Expected results:
 Therefore, to install all packages but conflicting packages, the kickstart file must contain:
<screen>
%packages
@Everything
-@Conflicts
</screen>

Additional info:
English XML:
<para>
        Previously, the kickstart installation method offered two options to select all
packages <command>@Everything</command> and <command>*</command> (wildcard). As of Red Hat Enterprise Linux 5.5, both of these options
have been <emphasis>deprecated</emphasis>. Attempting to use a select all packages option will fail, unless the kickstart file also includes package     
negation for conflicting packages. Therefore, to install all packages but conflicting packages, the kickstart file must contain:
<screen>
%packages
@Everything
-@Conflicts
</screen>
    </para> 

PO file:
msgid ""
"Previously, the kickstart installation method offered two options to select "
"all packages <command>@Everything</command> and <command>*</command> "
"(wildcard). As of Red Hat Enterprise Linux 5.5, both of these options have "
"been <emphasis>deprecated</emphasis>. Attempting to use a select all "
"packages option will fail, unless the kickstart file also includes package "
"negation for conflicting packages. Therefore, to install all packages but "
"conflicting packages, the kickstart file must contain: <screen> %packages "
"@Everything -@Conflicts </screen>"

Localized XML (Spanish):
<para>
            Anteriormente, el método de instalación kickstart ofrecía dos opciones para seleccionar todos los paquetes: <command>@           Everything</command> y <command>*</command> (comodín). A partir de Red Hat Enterprise Linux 5.5, estas dos opciones han sido                 <emphasis>descontinuadas</emphasis>. Tratar de usar una opción de seleccionar todos los paquetes fallará, a no ser que el archivo de         kickstart también incluya negación de paquete para paquetes en conflicto Por lo tanto, para instalar todos los paquetes sin los paquetes en  conflicto, el archivo de kickstart debe contener:  
<screen> %packages @Everything -@Conflicts
</screen>
            .
        </para>

Comment 1 Jeff Fearn 🐞 2010-03-09 05:10:14 UTC
I think the correct fix for this is to ban the para tag, mixed mode content is clearly a violation of both sane semantic mark-up and nature. Mixed mode content that embeds untranslatable content in translatable content is the worse kind of unnatural act.

I must ponder this ... perversion ... more ... pity me this study >_<

Comment 2 Jeff Fearn 🐞 2010-03-09 23:54:02 UTC
Added code to abort POT creation when verbatim tags are detected in translatable content.

e.g.

Processing file en-US/Building_a_Book.xml
ERROR: Verbatim content can not be embedded in translatable content, found a screen in a para! at /usr/bin/publican line 561

Comment 3 Ruediger Landmann 2010-03-22 06:35:17 UTC
Verified for 1.6.1

Comment 4 Fedora Update System 2010-03-24 00:13:12 UTC
publican-1.6.1-0.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/publican-1.6.1-0.fc12

Comment 5 Fedora Update System 2010-03-24 00:13:46 UTC
publican-1.6.1-0.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/publican-1.6.1-0.fc11

Comment 6 Fedora Update System 2010-03-24 00:14:16 UTC
publican-1.6.1-0.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/publican-1.6.1-0.fc13

Comment 7 Fedora Update System 2010-03-24 00:46:30 UTC
publican-1.6.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.

Comment 8 Fedora Update System 2010-03-24 23:36:05 UTC
publican-1.6.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.

Comment 9 Fedora Update System 2010-03-24 23:37:45 UTC
publican-1.6.1-0.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 10 Douglas Silas 2010-04-08 19:01:51 UTC
I agree with the spirit of the change in comment 1. However, this change is causing problems with the Deployment Guide. 

There are a lot of instances where <screen> is used inside <para>, and I am fixing them (so that I can run update_pot). But because of para's complex content model, it can be very difficult to see where this occurs.

For example, I have the following nested tags in the LDAP chapter: a <screen> (with several <para> siblings, which are not the problem, but complicate seeing it) inside a <listitem> inside an <itemizedlist> inside a <para>. (Don't ask me why someone did that...).

Also, these same instances will exist in all 5.x branches of the DG, making them all, AFAIK, unable to update their POT files.

Publican tells me which file the nesting problem occurs in, but doesn't provide any information about where it occurred. Would it be possible to output either a line number (of the file itself), or the content model that is causing the problem?

Alternatively, you can find these by doing the following:

install xmlstarlet: yum install xmlstarlet

in the repo: xmlstarlet sel -t -v "//para/screen" my_chapter.xml

If screen is nested directly inside a para, the screen's content will be output, providing you with a clue of where to look. (xmlstarlet is basically running an XPATH query on my_chapter.xml.)

For deeper nests such as the one described above, I had to do this:

temp!Deployment_Guide.git/tmp/en-US/xml_tmp *> xmlstarlet sel -t -v "//para/screen" Lightweight_Directory_Access_Protocol_LDAP.xml 
temp!Deployment_Guide.git/tmp/en-US/xml_tmp *> xmlstarlet sel -t -v "//para/*/screen" Lightweight_Directory_Access_Protocol_LDAP.xml 
temp!Deployment_Guide.git/tmp/en-US/xml_tmp *> xmlstarlet sel -t -v "//para/*/*/screen" Lightweight_Directory_Access_Protocol_LDAP.xml 

passwd: files ldap
shadow: files ldap
group: files ldap

...which finally showed the offending screen's content. If this change causes problems in lots of books, I think that this approach to finding the problems could be (bash-)scripted. 

Should I reopen this bug/file a new one?

Thanks,

Silas

Comment 11 Douglas Silas 2010-04-08 19:41:35 UTC
Created attachment 405388 [details]
This script finds screen elements nested inside para elements up to 5 deep

Comment 12 Douglas Silas 2010-04-08 19:44:27 UTC
After writing the comment 10 and then the script in comment 11, it turned out that there were only a few more to fix in all the files in the Deployment Guide.

So it was not as big a problem as I had feared. The attached script is useful for finding screen-para nesting errors; perhaps someone else will be able to use it.

-- Silas

Comment 13 Jeff Fearn 🐞 2010-04-08 21:48:13 UTC
You could optimise the search to:

xmlstarlet sel -t -v "//screen/ancestor::para"

There has been a bug opened at https://bugzilla.redhat.com/show_bug.cgi?id=580360

Cheers, Jeff.