Bug 571633 - Publican delete the new lines on the screen Tags when creating POTs
Publican delete the new lines on the screen Tags when creating POTs
Status: CLOSED ERRATA
Product: Publican
Classification: Community
Component: publican (Show other bugs)
2.0
All Linux
low Severity medium
: ---
: ---
Assigned To: Michael Hideo
Joshua Wulf
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-03-08 23:22 EST by Manuel Ospina
Modified: 2016-06-17 17:06 EDT (History)
5 users (show)

See Also:
Fixed In Version: 1.6.1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-03-23 20:53:31 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
This script finds screen elements nested inside para elements up to 5 deep (1.03 KB, application/octet-stream)
2010-04-08 15:41 EDT, Douglas Silas
no flags Details

  None (edit)
Description Manuel Ospina 2010-03-08 23:22:31 EST
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 00:10:14 EST
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 18:54:02 EST
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 02:35:17 EDT
Verified for 1.6.1
Comment 4 Fedora Update System 2010-03-23 20:13:12 EDT
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-23 20:13:46 EDT
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-23 20:14:16 EDT
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-23 20:46:30 EDT
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 19:36:05 EDT
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 19:37:45 EDT
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 15:01:51 EDT
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 15:41:35 EDT
Created attachment 405388 [details]
This script finds screen elements nested inside para elements up to 5 deep
Comment 12 Douglas Silas 2010-04-08 15:44:27 EDT
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 17:48:13 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.