Bug 571633
Summary: | Publican delete the new lines on the screen Tags when creating POTs | ||||||
---|---|---|---|---|---|---|---|
Product: | [Community] Publican | Reporter: | Manuel Ospina <mospina> | ||||
Component: | publican | Assignee: | Michael Hideo <mhideo> | ||||
Status: | CLOSED ERRATA | QA Contact: | Joshua Wulf <jwulf> | ||||
Severity: | medium | Docs Contact: | |||||
Priority: | low | ||||||
Version: | 2.0 | CC: | 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
Manuel Ospina
2010-03-09 04:22:31 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 >_< 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. |