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>
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 >_<
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
Verified for 1.6.1
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
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
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
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.
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.
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.
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
Created attachment 405388 [details] This script finds screen elements nested inside para elements up to 5 deep
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
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.