From dmison at redhat.com Sun Aug 1 23:48:17 2010 From: dmison at redhat.com (Darrin Mison) Date: Mon, 02 Aug 2010 09:48:17 +1000 Subject: [publican-list] [Bug 616142] New: RFC: building only part of a book by altering xrefs In-Reply-To: <4C4E243C.9090106@redhat.com> References: <4C4E243C.9090106@redhat.com> Message-ID: <1280706497.23395.7.camel@dhcp-1-137.bne.redhat.com> Actually I would like this feature for a different usecase: debugging. It's useful to be able to comment out includes from the root document xml to quickly narrow down the source of the problem, but with projects that have lots of xrefs it's a nightmare. On Tue, 2010-07-27 at 02:11 +0200, Douglas Silas wrote: > https://bugzilla.redhat.com/show_bug.cgi?id=616142 > > I have a request for consideration for a controversial feature that > has two > important and related use cases: > > * I have a very large book to publish, but due to (various) reasons, > only want > to publish part of it. The content is all interlinked with xrefs, > though, so I > cannot build the book unless I manually change all of them. > > * I am working on a single chapter of a very large book that takes > up to 2 > minutes or more to build (with publican 1/2+, which is still a huge > improvement), and to view my work (to review as a draft, or to check the > formatting), I would like to build a single chapter. However, due to > the rigor > inherited by xrefs, I cannot. > > The best (and completely hypothetical) solution for these cases > would be if > xrefs were more like xi:includes: > > For more information about firewalls, refer to > some_unique_id > the Firewalls > section of > the Red Hat Enterprise Linux Security > Guide. > > I suppose technically that the mix of inline and block-level > elements there > wouldn't work, but that's the idea. > > In lieu of such a useful construct, I am wondering if: > > * there is any interest on behalf of others in building only part of > a book; > > * there are any suggestions for what to replace xrefs to nonexistent > targets > with; and, > > * this is a good idea or a bad one. > > This feature could be abused by users saying, "Well, if the book > doesn't build > because of broken xrefs, just turn on directive ignore_xrefs in > publican.cfg." > If this were a feature, publican could warn that it converted > linkends A, B and > C in X and Y chapters into ____ elements. Perhaps this could be a > feature that > could only be enabled on the command line, and thus could not set > for entire > books. I think its utility is undeniable, though, as it would save > many of us > time and effort. I currently cannot publish completed chapters of an > overall > 500+ page book I am editing (that is interlinked heavily with xrefs) > without > either changing all the xrefs manually in a publication branch, or > writing a > hack of a script that replaces these xrefs with s or some other > element. I've done the latter out of necessity, but it is almost > certainly > better if this problem is discussed on the list, where we could > perhaps come up > with a single band-aid instead of many individual ones :-) > > -- > Douglas Silas > Technical Writer | Red Hat, Inc. > Purky?ova 99 | Brno, Czech Republic > Office Direct Dial?62116 > Brno Office?(+420) 532 294 111 ext. 10718 > > _______________________________________________ > publican-list mailing list > publican-list at redhat.com > https://www.redhat.com/mailman/listinfo/publican-list > Wiki: https://fedorahosted.org/publican From jfearn at redhat.com Mon Aug 2 00:03:22 2010 From: jfearn at redhat.com (Jeffrey Fearn) Date: Mon, 02 Aug 2010 10:03:22 +1000 Subject: [publican-list] [Bug 616142] New: RFC: building only part of a book by altering xrefs In-Reply-To: <1280706497.23395.7.camel@dhcp-1-137.bne.redhat.com> References: <4C4E243C.9090106@redhat.com> <1280706497.23395.7.camel@dhcp-1-137.bne.redhat.com> Message-ID: <4C560B4A.5060403@redhat.com> Darrin Mison wrote: > Actually I would like this feature for a different usecase: debugging. > > It's useful to be able to comment out includes from the root document > xml to quickly narrow down the source of the problem, but with projects > that have lots of xrefs it's a nightmare. Any reason you can't use conditions as per my original response? Modifying the DTD to be incompatible with upstream is a huge step in the wrong direction IMHO. Doubly so since using conditions is a pretty simple work around, again IMHO. Cheers, Jeff. -- Jeff Fearn Software Engineer Engineering Operations Red Hat, Inc Freedom ... courage ... Commitment ... ACCOUNTABILITY From dhensley at redhat.com Tue Aug 3 06:38:22 2010 From: dhensley at redhat.com (Douglas Silas) Date: Tue, 03 Aug 2010 08:38:22 +0200 Subject: [publican-list] [Bug 616142] New: RFC: building only part of a book by altering xrefs In-Reply-To: <4C560B4A.5060403@redhat.com> References: <4C4E243C.9090106@redhat.com> <1280706497.23395.7.camel@dhcp-1-137.bne.redhat.com> <4C560B4A.5060403@redhat.com> Message-ID: <4C57B95E.3080507@redhat.com> Hi, On 08/02/2010 02:03 AM, Jeffrey Fearn wrote: > Darrin Mison wrote: >> Actually I would like this feature for a different usecase: >> debugging. >> >> It's useful to be able to comment out includes from the root document >> xml to quickly narrow down the source of the problem, but with >> projects >> that have lots of xrefs it's a nightmare. > > Any reason you can't use conditions as per my original response? I believe Jeff's suggestion would be implemented like this: For more information on checking package signatures, refer to . For more information on checking package signatures, refer to the forthcoming &NEXTVER; edition of the &MAJOROS; &BOOKTITLE;. Obviously, calling the conditions "ch1", "ch2" and so on would be a bad idea; instead, they should be meaningfully echo the names of chapters or sections. I had overlooked that multiple conditions can be set simultaneously (there's only a brief mention of that in one example in the Publican Users Guide). Jeff's solution works, and conforms with the DocBook DTD. However: * it can't be done ad-hoc (it would probably be overkill just for debugging) * it busies up the XML markup * in the case of large books, would add 40-50+ conditions to the build (two for each chapter, such as "RPM" and "NoRPM" above) * renaming a chapter (which happens occasionally) would suggest renaming the associated conditions everywhere they appear in the chapters * would force you to change the conditions set in publican.cfg quite often * would probably make maintaining and debugging the xrefs a nightmare Question: is there an upper limit on the number of conditions that can be set? This would be good to know & document. On the whole, using conditions for this purpose is probably not worth the effort and trouble. That is why I was looking for a more Publican-centric solution. Thanks, Silas > > Modifying the DTD to be incompatible with upstream is a huge step in > the wrong direction IMHO. Doubly so since using conditions is a > pretty simple work around, again IMHO. > > Cheers, Jeff. > From bugzilla at redhat.com Tue Aug 3 07:18:25 2010 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 3 Aug 2010 03:18:25 -0400 Subject: [publican-list] [Bug 486050] Publican Website In-Reply-To: References: Message-ID: <201008030718.o737IPJV002451@bzweb02.app.bz.hst.phx2.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=486050 errata-xmlrpc changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RELEASE_PENDING |CLOSED Resolution| |ERRATA --- Comment #5 from errata-xmlrpc 2010-08-03 03:18:24 EDT --- An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHEA-2010-0588.html -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From oguzyilmazlist at gmail.com Tue Aug 3 09:48:36 2010 From: oguzyilmazlist at gmail.com (Oguz Yilmaz) Date: Tue, 3 Aug 2010 12:48:36 +0300 Subject: [publican-list] Creating a book in Turkish language Message-ID: Dear all, I have just installed publican and tried to creae a book by following a guide. publican create --name Test_Book --lang tr-TR Note: When, I have used Turkihs chars in the name of the book, It has warned me about the name of the book for including chars other then latin set. Then I have just compiled the book with success. publican build --formats html --langs tr-TR --config publican.cfg When I change a chapter.xml to include some Turkish chars (8859-9, win-1254), it has given an error and exit during building the book. The OS was Windows Vista and publican version is 1.6.3. What do you suggest me for creating a book in Turkish chars? Best Regards, Oguz Yilmaz publican build --formats html --langs tr-TR --config publican.cfg Setting up tr-TR Processing file tmp/tr-TR/xml/Common_Content/Conventions.xml -> tmp/tr-T R/xml/Common_Content/Conventions.xml Processing file tmp/tr-TR/xml/Common_Content/Feedback.xml -> tmp/tr-TR/x ml/Common_Content/Feedback.xml Processing file tmp/tr-TR/xml/Common_Content/Legal_Notice.xml -> tmp/tr- TR/xml/Common_Content/Legal_Notice.xml Processing file tmp/tr-TR/xml_tmp/Author_Group.xml -> tmp/tr-TR/xml/Auth or_Group.xml Processing file tmp/tr-TR/xml_tmp/Book_Info.xml -> tmp/tr-TR/xml/Book_In fo.xml Can't calculate image size, image may render badly. Image File: tmp/tr-TR/xml/Co mmon_Content/images/title_logo.svg. Error Message: Processing file tmp/tr-TR/xml_tmp/Chapter.xml -> tmp/tr-TR/xml/Chapter.x ml not well-formed (invalid token) at line 14, column 29, byte 544: Test Section 1 This is a test paragraph o?uz y?lmaz ??????,q in a secti on ============================^ at XML/Parser.pm line 187 From r.landmann at redhat.com Tue Aug 3 17:30:15 2010 From: r.landmann at redhat.com (Ruediger Landmann) Date: Wed, 04 Aug 2010 03:30:15 +1000 Subject: [publican-list] Creating a book in Turkish language In-Reply-To: References: Message-ID: <4C585227.8090800@redhat.com> On 08/03/2010 07:48 PM, Oguz Yilmaz wrote: > Dear all, > > I have just installed publican and tried to creae a book by following a guide. > publican create --name Test_Book --lang tr-TR > > Note: When, I have used Turkihs chars in the name of the book, It has > warned me about the name of the book for including chars other then > latin set. Hi Oguz! One of Publican's key features is to produce RPM packages of books, and Publican uses the title of the book to create the RPM file name. File names of RPM packages can only have ASCII characters in them. However, you can still set the correct Turkish characters in the title like this: 1. Create the book with an ASCII version of the title: publican create --name Ag_Yonetimi --lang tr-TR 2. Edit the Book_Info.xml file to include the correct Turkish title: A? Y?netimi 3. Edit the publican.cfg file to point to the ASCII version of the title. Insert the line: docname: Ag_Yonetimi You can now build the book as normal and the title will be correct. > Then I have just compiled the book with success. > publican build --formats html --langs tr-TR --config publican.cfg > > When I change a chapter.xml to include some Turkish chars (8859-9, > win-1254), it has given an error and exit during building the book. Publican uses the UTF-8 character set. Unpredictable things might happen if you use a different encoding. I have tested a book with some paragraphs in Turkish encoded in UTF-8, and the book builds fine on Fedora; I believe that with UTF-8 encoding, it should build fine on Windows too, but I don't have a Windows machine to test. You can see the sample output here: http://rlandmann.fedorapeople.org/tr-TR/ You can see the paragraphs of Turkish here: http://rlandmann.fedorapeople.org/tr-TR/chap-Ag_Yonetimi-Test_Chapter.html Please let us know if this works for you. Kind regards R?diger From jfearn at redhat.com Wed Aug 4 04:22:18 2010 From: jfearn at redhat.com (Jeffrey Fearn) Date: Wed, 04 Aug 2010 14:22:18 +1000 Subject: [publican-list] [Bug 616142] New: RFC: building only part of a book by altering xrefs In-Reply-To: <4C57B95E.3080507@redhat.com> References: <4C4E243C.9090106@redhat.com> <1280706497.23395.7.camel@dhcp-1-137.bne.redhat.com> <4C560B4A.5060403@redhat.com> <4C57B95E.3080507@redhat.com> Message-ID: <4C58EAFA.7050608@redhat.com> Douglas Silas wrote: > On the whole, using conditions for this purpose is probably not worth > the effort and trouble. That is why I was looking for a more > Publican-centric solution. I can't imagine an argument that would move us to break DocBook compatibility in the way you suggested. Not saying it wouldn't happen, but it would have to be a brilliant argument. If you want functionality that requires DTD changes then you should be presenting your ideas upstream and trying to get it in to DocBook. If anyone has any other ideas on how to do this kind of thing without breaking DocBook compatibility, now is the time to speak up! Cheers, Jeff. -- Jeff Fearn Software Engineer Engineering Operations Red Hat, Inc Freedom ... courage ... Commitment ... ACCOUNTABILITY From oguzyilmazlist at gmail.com Wed Aug 4 05:35:37 2010 From: oguzyilmazlist at gmail.com (Oguz Yilmaz) Date: Wed, 4 Aug 2010 08:35:37 +0300 Subject: [publican-list] Creating a book in Turkish language In-Reply-To: <4C585227.8090800@redhat.com> References: <4C585227.8090800@redhat.com> Message-ID: Dear Ruediger, I have just tried with Fedora 13. Now I can have Turkish chars in the document. However, The problem on the book name continues: "tr-TR/Book_Info.xml": LbrUTM 2.1.1 S?r?m Notlar? $ publican build --formats html --langs tr-TR --config publican.cfg Invalid format for docname. Value (LbrUTM_2.1.1_S?r?m_Notlar?) does not conform to constraint ([^a-zA-Z_\-0-9.]) at /usr/bin/publican line 514 On Tue, Aug 3, 2010 at 8:30 PM, Ruediger Landmann wrote: > ?On 08/03/2010 07:48 PM, Oguz Yilmaz wrote: >> >> Dear all, >> >> I have just installed publican and tried to creae a book by following a >> guide. >> publican create --name Test_Book --lang tr-TR >> >> Note: When, I have used Turkihs chars in the name of the book, It has >> warned me about the name of the book for including chars other then >> latin set. > > Hi Oguz! > > One of Publican's key features is to produce RPM packages of books, and > Publican uses the title of the book to create the RPM file name. File names > of RPM packages can only have ASCII characters in them. However, you can > still set the correct Turkish characters in the title like this: > > 1. Create the book with an ASCII version of the title: > > publican create --name Ag_Yonetimi --lang tr-TR > > 2. Edit the Book_Info.xml file to include the correct Turkish title: > > A? Y?netimi > > 3. Edit the publican.cfg file to point to the ASCII version of the title. > Insert the line: > > docname: Ag_Yonetimi > > You can now build the book as normal and the title will be correct. > >> Then I have just compiled the book with success. >> publican build --formats html --langs tr-TR --config publican.cfg >> >> When I change a chapter.xml to include some Turkish chars (8859-9, >> win-1254), it has given an error and exit during building the book. > > Publican uses the UTF-8 character set. Unpredictable things might happen if > you use a different encoding. > > I have tested a book with some paragraphs in Turkish encoded in UTF-8, and > the book builds fine on Fedora; I believe that with UTF-8 encoding, it > should build fine on Windows too, but I don't have a Windows machine to > test. ?You can see the sample output here: > > http://rlandmann.fedorapeople.org/tr-TR/ > > You can see the paragraphs of Turkish here: > > http://rlandmann.fedorapeople.org/tr-TR/chap-Ag_Yonetimi-Test_Chapter.html > > Please let us know if this works for you. > > Kind regards > R?diger > > _______________________________________________ > publican-list mailing list > publican-list at redhat.com > https://www.redhat.com/mailman/listinfo/publican-list > Wiki: https://fedorahosted.org/publican From bugzilla at redhat.com Wed Aug 4 05:41:59 2010 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 4 Aug 2010 01:41:59 -0400 Subject: [publican-list] [Bug 616112] IDs not set on admonitions or varlistentry In-Reply-To: References: Message-ID: <201008040541.o745fxPN025110@bzweb01.app.bz.hst.phx2.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=616112 Jeff Fearn changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jfearn at redhat.com Summary|certain element IDs do not |IDs not set on admonitions |cause anchors to be |or varlistentry |generated, even if xref'd | |to | -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla at redhat.com Wed Aug 4 06:04:15 2010 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 4 Aug 2010 02:04:15 -0400 Subject: [publican-list] [Bug 616112] IDs not set on admonitions or varlistentry In-Reply-To: References: Message-ID: <201008040604.o7464FhQ012122@bzweb02.app.bz.hst.phx2.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=616112 Jeff Fearn changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ON_DEV --- Comment #3 from Jeff Fearn 2010-08-04 02:04:14 EDT --- Set IDs on admonitions & varlistentry Fixed in Build: 2.1-0%{?dist}.t13 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From r.landmann at redhat.com Wed Aug 4 06:14:07 2010 From: r.landmann at redhat.com (Ruediger Landmann) Date: Wed, 04 Aug 2010 16:14:07 +1000 Subject: [publican-list] Creating a book in Turkish language In-Reply-To: References: <4C585227.8090800@redhat.com> Message-ID: <4C59052F.2060000@redhat.com> On 08/04/2010 03:35 PM, Oguz Yilmaz wrote: > Dear Ruediger, > > I have just tried with Fedora 13. Now I can have Turkish chars in the document. > > However, The problem on the book name continues: > > "tr-TR/Book_Info.xml": > > LbrUTM 2.1.1 S?r?m Notlar? > > $ publican build --formats html --langs tr-TR --config publican.cfg > Invalid format for docname. Value (LbrUTM_2.1.1_S?r?m_Notlar?) does > not conform to constraint ([^a-zA-Z_\-0-9.]) at /usr/bin/publican line > 514 Hi again Oguz It looks to me like the "docname" parameter in the publican.cfg file is not quite right. Try this: 1. Create the book: publican create --name Surum_Notlari --product LbrUTM --version 2.1.1 --lang tr-TR 2. Edit the tr-TR/Book_Info.xml file: change Surum Notlari into S?r?m Notlar? 3. Edit the publican.cfg file and add a new line: docname: Surum_Notlari 4. Build the book: publican build --formats html --langs tr-TR (note: no need to specify the config file) If you still have trouble, maybe you could show us your publican.cfg file for this book? Regards Rudi From oguzyilmazlist at gmail.com Wed Aug 4 08:55:48 2010 From: oguzyilmazlist at gmail.com (Oguz Yilmaz) Date: Wed, 4 Aug 2010 11:55:48 +0300 Subject: [publican-list] Creating a book in Turkish language In-Reply-To: <4C59052F.2060000@redhat.com> References: <4C585227.8090800@redhat.com> <4C59052F.2060000@redhat.com> Message-ID: Yesi it works. Overriding with docname and product variables in publican.cfg will allow Turkish charactes Title and Product Name. Thanks Ruediger. On Wed, Aug 4, 2010 at 9:14 AM, Ruediger Landmann wrote: > ?On 08/04/2010 03:35 PM, Oguz Yilmaz wrote: >> >> Dear Ruediger, >> >> I have just tried with Fedora 13. Now I can have Turkish chars in the >> document. >> >> However, The problem on the book name continues: >> >> "tr-TR/Book_Info.xml": >> >> ? ? ? ? LbrUTM 2.1.1 S?r?m Notlar? >> >> $ publican build --formats html --langs tr-TR --config publican.cfg >> Invalid format for docname. Value (LbrUTM_2.1.1_S?r?m_Notlar?) does >> not conform to constraint ([^a-zA-Z_\-0-9.]) at /usr/bin/publican line >> 514 > > Hi again Oguz > > It looks to me like the "docname" parameter in the publican.cfg file is not > quite right. Try this: > > 1. Create the book: > > publican create --name Surum_Notlari --product LbrUTM --version 2.1.1 --lang > tr-TR > > 2. Edit the tr-TR/Book_Info.xml file: > > change Surum Notlari > > into S?r?m Notlar? > > 3. Edit the publican.cfg file and add a new line: > > docname: Surum_Notlari > > 4. Build the book: > > publican build --formats html --langs tr-TR > > (note: no need to specify the config file) > > If you still have trouble, maybe you could show us your publican.cfg file > for this book? > > Regards > Rudi > > _______________________________________________ > publican-list mailing list > publican-list at redhat.com > https://www.redhat.com/mailman/listinfo/publican-list > Wiki: https://fedorahosted.org/publican From bugzilla at redhat.com Wed Aug 4 22:28:44 2010 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 4 Aug 2010 18:28:44 -0400 Subject: [publican-list] [Bug 592823] should not break a paragraph for translation In-Reply-To: References: Message-ID: <201008042228.o74MSixM001032@bzweb02.app.bz.hst.phx2.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=592823 Jeff Fearn changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |MODIFIED Fixed In Version| |publican-2.1-0.el6 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla at redhat.com Thu Aug 5 04:15:58 2010 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 5 Aug 2010 00:15:58 -0400 Subject: [publican-list] [Bug 599258] table borders on in html/html-single In-Reply-To: References: Message-ID: <201008050415.o754Fwf6006941@bzweb02.app.bz.hst.phx2.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=599258 Ruediger Landmann changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ON_DEV |CLOSED Fixed In Version| |2.0 Resolution| |CURRENTRELEASE -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla at redhat.com Thu Aug 5 04:15:33 2010 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 5 Aug 2010 00:15:33 -0400 Subject: [publican-list] [Bug 596257] RFE: do not split admonitions across pages In-Reply-To: References: Message-ID: <201008050415.o754FXJr029170@bzweb01.app.bz.hst.phx2.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=596257 Ruediger Landmann changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ON_DEV |CLOSED Fixed In Version| |2.0 Resolution| |CURRENTRELEASE -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla at redhat.com Thu Aug 5 04:24:25 2010 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 5 Aug 2010 00:24:25 -0400 Subject: [publican-list] [Bug 595564] RFE: can xref links to formalpara go to the actual formalpara, rather than top of the page? In-Reply-To: References: Message-ID: <201008050424.o754OPoW008491@bzweb02.app.bz.hst.phx2.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=595564 Jeff Fearn changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ON_DEV |CLOSED Fixed In Version| |publican-2.1-0.el5 Resolution| |CURRENTRELEASE -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla at redhat.com Thu Aug 5 04:25:51 2010 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 5 Aug 2010 00:25:51 -0400 Subject: [publican-list] [Bug 604255] Problem with callouts In-Reply-To: References: Message-ID: <201008050425.o754PpEc009033@bzweb02.app.bz.hst.phx2.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=604255 Ruediger Landmann changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |r.landmann at redhat.com --- Comment #7 from Ruediger Landmann 2010-08-05 00:25:50 EDT --- (In reply to comment #6) > That satisfies my needs. The main disadvantage is that if you add a blank line > or something, the callouts can be in the wrong place, but this is plenty good > enough for my needs. Glad to hear that helps; I'll note the limitation in the User Guide. --Rudi -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From dhensley at redhat.com Thu Aug 5 15:30:27 2010 From: dhensley at redhat.com (Douglas Silas) Date: Thu, 05 Aug 2010 17:30:27 +0200 Subject: [publican-list] odd publican package error Message-ID: <4C5AD913.1000201@redhat.com> Hi, Trying to package the latest RHEL5 DG (after bumping the pubsnumber) on brew with this command: publican package --brew --lang=es-ES ...or seemingly any other non-en-US language, fails with the following excised error message in build.log: + export CLASSPATH=:/usr/share/java/ant/ant-trax-1.7.0.jar:/usr/share/java/xmlgraphics-commons.jar:/usr/share/java/batik-all.jar:/usr/share/java/xml-commons-apis.jar:/usr/share/java/xml-commons-apis-ext.jar + CLASSPATH=:/usr/share/java/ant/ant-trax-1.7.0.jar:/usr/share/java/xmlgraphics-commons.jar:/usr/share/java/batik-all.jar:/usr/share/java/xml-commons-apis.jar:/usr/share/java/xml-commons-apis-ext.jar + publican build --embedtoc --formats=html,html-single,html-desktop,pdf,epub --langs=es-ES --publish  DEBUG: Publican: config loaded Invalid format for release. Value (ARRAY(0xd12e2f0)) does not conform to constraint ([^0-9.]) at /usr/bin/publican line 514 RPM build errors: error: Bad exit status from /var/tmp/rpm-tmp.10233 (%build) Bad exit status from /var/tmp/rpm-tmp.10233 (%build) Child returncode was: 1 EXCEPTION: Command failed. See logs for output. # ['bash', '--login', '-c', 'rpmbuild -bb --target noarch --nodeps builddir/build/SPECS/Red_Hat_Enterprise_Linux-Deployment_Guide-5-web-es-ES.spec'] Traceback (most recent call last): The relevant error message there seems to be: Invalid format for release. Value (ARRAY(0xd12e2f0)) does not conform to constraint ([^0-9.]) at /usr/bin/publican line 514 According to Jarek, this error message means that publican is trying to run the regex [^0-9.] on an array itself, not one of its members (such as a string). Additionally, the line number the error message provides is incorrect. Packaging on brew succeeds as expected when lang=en-US. Any ideas about what might be happening here? Thanks, -- Douglas Silas Technical Writer | Red Hat, Inc. Purky?ova 99 | Brno, Czech Republic Office Direct Dial?62116 Brno Office?(+420) 532 294 111 ext. 10718 From r.landmann at redhat.com Thu Aug 5 19:09:53 2010 From: r.landmann at redhat.com (Ruediger Landmann) Date: Fri, 06 Aug 2010 05:09:53 +1000 Subject: [publican-list] odd publican package error In-Reply-To: <4C5AD913.1000201@redhat.com> References: <4C5AD913.1000201@redhat.com> Message-ID: <4C5B0C81.1060600@redhat.com> On 08/06/2010 01:30 AM, Douglas Silas wrote: > Hi, > > Trying to package the latest RHEL5 DG (after bumping the pubsnumber) > on brew with this command: > > publican package --brew --lang=es-ES > > The relevant error message there seems to be: > > Invalid format for release. Value (ARRAY(0xd12e2f0)) does not > conform to constraint ([^0-9.]) at /usr/bin/publican line 514 I'm note sure whether it's the cause of the error you're seeing, but note that the pubsnumber only governs the release number for packages in the language in which the XML is authored (in this case, en-US). The release number for packages in translated packages is governed by the "Project-Id-Version" parameter in the Book_Info.po file for that language. For example, if this is release 42 of the Spanish translation of the book, set: "Project-Id-Version: 42\n" in the es-ES/Book_Info.po file. I wonder whether you're seeing that error because you have something other than numerals or a dot in the "Project-Id-Version" parameter for the Spanish version of the DG? A few weeks ago, I realized this information was missing from the Publican User Guide; it's in there for the next release (2.2, out soon). Cheers Rudi From jfearn at redhat.com Thu Aug 5 22:52:02 2010 From: jfearn at redhat.com (Jeffrey Fearn) Date: Fri, 06 Aug 2010 08:52:02 +1000 Subject: [publican-list] odd publican package error In-Reply-To: <4C5B0C81.1060600@redhat.com> References: <4C5AD913.1000201@redhat.com> <4C5B0C81.1060600@redhat.com> Message-ID: <4C5B4092.5050308@redhat.com> Ruediger Landmann wrote: > On 08/06/2010 01:30 AM, Douglas Silas wrote: >> Hi, >> >> Trying to package the latest RHEL5 DG (after bumping the pubsnumber) >> on brew with this command: >> >> publican package --brew --lang=es-ES > > > >> >> The relevant error message there seems to be: >> >> Invalid format for release. Value (ARRAY(0xd12e2f0)) does not >> conform to constraint ([^0-9.]) at /usr/bin/publican line 514 > > I'm note sure whether it's the cause of the error you're seeing, but > note that the pubsnumber only governs the release number for packages in > the language in which the XML is authored (in this case, en-US). The > release number for packages in translated packages is governed by the > "Project-Id-Version" parameter in the Book_Info.po file for that > language. For example, if this is release 42 of the Spanish translation > of the book, set: > > "Project-Id-Version: 42\n" > > in the es-ES/Book_Info.po file. > > I wonder whether you're seeing that error because you have something > other than numerals or a dot in the "Project-Id-Version" parameter for > the Spanish version of the DG? Indeed, the Book_Info.po files in the 5.5 SVN repo have either: "Project-Id-Version: PACKAGE VERSION\n" or "Project-Id-Version: Deployment_Guide\n" > A few weeks ago, I realized this information was missing from the > Publican User Guide; it's in there for the next release (2.2, out soon). The translators have known about this for ages. I'll see if I can re-jig the code so this gets picked up earlier in the process, like package creation instead of building. I opened https://bugzilla.redhat.com/show_bug.cgi?id=621721 Cheers, Jeff. -- Jeff Fearn Software Engineer Engineering Operations Red Hat, Inc Freedom ... courage ... Commitment ... ACCOUNTABILITY From jfearn at redhat.com Fri Aug 6 00:33:24 2010 From: jfearn at redhat.com (Jeffrey Fearn) Date: Fri, 06 Aug 2010 10:33:24 +1000 Subject: [publican-list] odd publican package error In-Reply-To: <4C5B4092.5050308@redhat.com> References: <4C5AD913.1000201@redhat.com> <4C5B0C81.1060600@redhat.com> <4C5B4092.5050308@redhat.com> Message-ID: <4C5B5854.2080705@redhat.com> Jeffrey Fearn wrote: > I'll see if I can re-jig the code so this gets picked up earlier in the > process, like package creation instead of building. > > I opened https://bugzilla.redhat.com/show_bug.cgi?id=621721 Fix checked in to SVN, check bug for details. Cheers, Jeff. -- Jeff Fearn Software Engineer Engineering Operations Red Hat, Inc Freedom ... courage ... Commitment ... ACCOUNTABILITY From bugzilla at redhat.com Fri Aug 6 04:26:53 2010 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 6 Aug 2010 00:26:53 -0400 Subject: [publican-list] [Bug 616112] IDs not set on admonitions or varlistentry In-Reply-To: References: Message-ID: <201008060426.o764QrTX024909@bzweb01.app.bz.hst.phx2.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=616112 Ruediger Landmann changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |r.landmann at redhat.com Fixed In Version| |2.2 --- Comment #4 from Ruediger Landmann 2010-08-06 00:26:53 EDT --- Verified in 2.1.t20 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From strider at gnome.org Fri Aug 6 09:00:23 2010 From: strider at gnome.org (=?ISO-8859-1?Q?Ga=EBl_Chamoulaud?=) Date: Fri, 6 Aug 2010 11:00:23 +0200 Subject: [publican-list] Fwd: Publican create_site and default langs In-Reply-To: References: Message-ID: Hi there, I want to create a site with publican, which rocks ! FYI, This site has to be in french with all the french documentation we did in french too. So, when I am creating the site, I'm getting this message "No langs Found, using default langs" And, there is no --lang(s) parameters for publican create_site :/ $ publican create_site --site_config homepage.cfg --db_file ntw.db --toc_path ntw_html No langs found, using default langs No langs found, using default langs No langs found, using default langs What I have to do to create my documentation site in french ? I glanced through the mailing list but without success. Thanks for you response ++-------------------------------------------------------------+ ++ Ga?l Chamoulaud (Strider) ++ Work Phone: +33 (0)6 45 17 75 29 ++ Website: http://www.gnome.org/~strider ++ Gnome: ++ Gmail: ++ Work: ++ ++ "La bi?re est la preuve que Dieu nous aime et veut ++ que nous soyons heureux." [Benjamin Franklin] ++ ++ () ascii ribbon campaign - against html e-mail ++ /\ www.asciiribbon.org - against proprietary attachments ++-------------------------------------------------------------+ -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.landmann at redhat.com Fri Aug 6 20:49:09 2010 From: r.landmann at redhat.com (Ruediger Landmann) Date: Sat, 07 Aug 2010 06:49:09 +1000 Subject: [publican-list] Fwd: Publican create_site and default langs In-Reply-To: References: Message-ID: <4C5C7545.1020809@redhat.com> On 08/06/2010 07:00 PM, Ga?l Chamoulaud wrote: > Hi there, > > I want to create a site with publican, which rocks ! > > FYI, This site has to be in french with all the french documentation we did > in french too. > > So, when I am creating the site, I'm getting this message "No langs Found, > using default langs" > And, there is no --lang(s) parameters for publican create_site :/ > > $ publican create_site --site_config homepage.cfg --db_file ntw.db > --toc_path ntw_html > No langs found, using default langs > No langs found, using default langs > No langs found, using default langs > > What I have to do to create my documentation site in french ? Hi Ga?l and thanks for your kind words Unfortunately, internationalization and localization for the website component are not fully implemented yet. The following notes describe the situation as it currently exists: -------------------------------- 1. create_site -------------------------------- All Publican websites are multi-lingual; the site attempts to present content based on the locale reported by the visitor's web browser. Therefore, there is nothing special that you must do to build the site framework in French during the "create_site" stage. Please ignore the "No langs found" warning; it does not affect your site creation. However, at the moment, if the site JavaScript cannot match the user's locale with content on the site, it redirects them to American English. You can manually fix this -- edit the index.html file (for example, ntw_html/html.index) and look for the lines that say: var locales = ["en-US"]; and if(match == 0) { lang = 'en-US'; } In both cases, change "en-US" to "fr-FR". Note that if you ever run publican update_site to refresh the site, you will need to make these changes again because this file is overwritten each time. I've opened an RFE to avoid having to do this manually in future versions of Publican [0] -------------------------------- 2. Creating the homepage -------------------------------- When you create the site homepage (as described in section 6.2 of the Publican Users' Guide), you should: 1. set the --lang parameter to French when you create this "book", for example: publican create --type Article --name Bienvenue --lang fr-FR 2. edit the publican.cfg file for this "book" to include the line: def_lang: fr-FR -------------------------------- Untranslated content -------------------------------- Some features of the website will still appear in English, because nobody has translated them into French yet in Publican :) For example, the contents of the "Statistics" and "Site Tech" pages are generated in English, and all the navigation elements such as "collapse all", "Search", "Untranslated" If you would like to add French support for these elements in Publican and are already a member of the Fedora localization project, you can translate them through Fedora's Transifex interface.[1][2] If you would like to help us but are not a member of the Fedora localization project, please contact me off-list. Cheers Rudi [0] https://bugzilla.redhat.com/show_bug.cgi?id=622030 [1] https://translate.fedoraproject.org/projects/p/publican/c/trunk/ [2] https://translate.fedoraproject.org/projects/p/publican/c/site_tech/ From bugzilla at redhat.com Sat Aug 7 12:50:13 2010 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 7 Aug 2010 08:50:13 -0400 Subject: [publican-list] [Bug 604255] Problem with callouts In-Reply-To: References: Message-ID: <201008071250.o77CoDZF016674@bzweb02.app.bz.hst.phx2.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=604255 Ruediger Landmann changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |ON_DEV Fixed In Version| |2.2 --- Comment #8 from Ruediger Landmann 2010-08-07 08:50:12 EDT --- Expanded the previous FAQ entry on adding code samples into a new section: "3.3. Adding code samples" and discussed recommended callout usage per comment #4. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla at redhat.com Sun Aug 8 23:08:22 2010 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 8 Aug 2010 19:08:22 -0400 Subject: [publican-list] [Bug 592823] should not break a paragraph for translation In-Reply-To: References: Message-ID: <201008082308.o78N8MJ6022601@bzweb01.app.bz.hst.phx2.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=592823 Andrew Ross changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ON_QA |VERIFIED --- Comment #20 from Andrew Ross 2010-08-08 19:08:21 EDT --- 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 paragraph paragraph in a section" msgstr "" -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From jfearn at redhat.com Mon Aug 9 04:24:55 2010 From: jfearn at redhat.com (Jeffrey Fearn) Date: Mon, 09 Aug 2010 14:24:55 +1000 Subject: [publican-list] Fwd: Publican create_site and default langs In-Reply-To: <4C5C7545.1020809@redhat.com> References: <4C5C7545.1020809@redhat.com> Message-ID: <4C5F8317.3060905@redhat.com> Ruediger Landmann wrote: > On 08/06/2010 07:00 PM, Ga?l Chamoulaud wrote: >> Hi there, >> >> I want to create a site with publican, which rocks ! >> >> FYI, This site has to be in french with all the french documentation >> we did >> in french too. >> >> So, when I am creating the site, I'm getting this message "No langs >> Found, >> using default langs" >> And, there is no --lang(s) parameters for publican create_site :/ >> >> $ publican create_site --site_config homepage.cfg --db_file ntw.db >> --toc_path ntw_html >> No langs found, using default langs >> No langs found, using default langs >> No langs found, using default langs >> >> What I have to do to create my documentation site in french ? > > Hi Ga?l and thanks for your kind words Yeah, welcome to the mailing list :) > [0] https://bugzilla.redhat.com/show_bug.cgi?id=622030 This bug is fixed in truck, waiting for Rudi to get back from holidays for validation. Cheers, Jeff. -- Jeff Fearn Software Engineer Engineering Operations Red Hat, Inc Freedom ... courage ... Commitment ... ACCOUNTABILITY From jfearn at redhat.com Mon Aug 9 04:26:39 2010 From: jfearn at redhat.com (Jeffrey Fearn) Date: Mon, 09 Aug 2010 14:26:39 +1000 Subject: [publican-list] Fwd: Publican create_site and default langs In-Reply-To: <4C5F8317.3060905@redhat.com> References: <4C5C7545.1020809@redhat.com> <4C5F8317.3060905@redhat.com> Message-ID: <4C5F837F.2040708@redhat.com> Jeffrey Fearn wrote: > This bug is fixed in truck, errr trunk ... hehehe Cheers, Jeff. -- Jeff Fearn Software Engineer Engineering Operations Red Hat, Inc Freedom ... courage ... Commitment ... ACCOUNTABILITY From bugzilla at redhat.com Mon Aug 9 19:34:52 2010 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 9 Aug 2010 15:34:52 -0400 Subject: [publican-list] [Bug 475684] Find solution for using Glossaries with publican In-Reply-To: References: Message-ID: <201008091934.o79JYqna004643@bzweb01.app.bz.hst.phx2.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=475684 --- Comment #21 from RHEL Product and Program Management 2010-08-09 15:34:50 EDT --- This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unfortunately unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From dhensley at redhat.com Mon Aug 9 20:38:21 2010 From: dhensley at redhat.com (Douglas Silas) Date: Mon, 09 Aug 2010 22:38:21 +0200 Subject: [publican-list] odd publican package error In-Reply-To: <4C5B4092.5050308@redhat.com> References: <4C5AD913.1000201@redhat.com> <4C5B0C81.1060600@redhat.com> <4C5B4092.5050308@redhat.com> Message-ID: <4C60673D.7020609@redhat.com> Thanks for the quick response to this error! Cheers for the docs improvement Rudi, and Jeff for the bug fix. I'm giving building the other langs another shot. -- Silas On 08/06/2010 12:52 AM, Jeffrey Fearn wrote: > Ruediger Landmann wrote: >> On 08/06/2010 01:30 AM, Douglas Silas wrote: >>> Hi, >>> >>> Trying to package the latest RHEL5 DG (after bumping the >>> pubsnumber) on brew with this command: >>> >>> publican package --brew --lang=es-ES >> >> >> >>> >>> The relevant error message there seems to be: >>> >>> Invalid format for release. Value (ARRAY(0xd12e2f0)) does not >>> conform to constraint ([^0-9.]) at /usr/bin/publican line 514 >> >> I'm note sure whether it's the cause of the error you're seeing, >> but note that the pubsnumber only governs the release number for >> packages in the language in which the XML is authored (in this >> case, en-US). The release number for packages in translated >> packages is governed by the "Project-Id-Version" parameter in the >> Book_Info.po file for that language. For example, if this is >> release 42 of the Spanish translation of the book, set: >> >> "Project-Id-Version: 42\n" >> >> in the es-ES/Book_Info.po file. >> >> I wonder whether you're seeing that error because you have >> something other than numerals or a dot in the "Project-Id-Version" >> parameter for the Spanish version of the DG? > > Indeed, the Book_Info.po files in the 5.5 SVN repo have either: > > "Project-Id-Version: PACKAGE VERSION\n" > or > "Project-Id-Version: Deployment_Guide\n" > >> A few weeks ago, I realized this information was missing from the >> Publican User Guide; it's in there for the next release (2.2, out >> soon). > > The translators have known about this for ages. > > I'll see if I can re-jig the code so this gets picked up earlier in > the process, like package creation instead of building. > > I opened https://bugzilla.redhat.com/show_bug.cgi?id=621721 > > Cheers, Jeff. > From bugzilla at redhat.com Wed Aug 11 05:12:05 2010 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 11 Aug 2010 01:12:05 -0400 Subject: [publican-list] [Bug 616112] IDs not set on admonitions or varlistentry In-Reply-To: References: Message-ID: <201008110512.o7B5C5nB019807@bzweb02.app.bz.hst.phx2.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=616112 BOBAE LEE changed: What |Removed |Added ---------------------------------------------------------------------------- CC|dngnpdl at naver.com | -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla at redhat.com Wed Aug 11 05:10:52 2010 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 11 Aug 2010 01:10:52 -0400 Subject: [publican-list] [Bug 616112] IDs not set on admonitions or varlistentry In-Reply-To: References: Message-ID: <201008110510.o7B5AqDr019612@bzweb02.app.bz.hst.phx2.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=616112 BOBAE LEE changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dngnpdl at naver.com -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From jfearn at redhat.com Mon Aug 16 22:28:10 2010 From: jfearn at redhat.com (Jeffrey Fearn) Date: Tue, 17 Aug 2010 08:28:10 +1000 Subject: [publican-list] [Bug 616142] New: RFC: building only part of a book by altering xrefs In-Reply-To: <4C58EAFA.7050608@redhat.com> References: <4C4E243C.9090106@redhat.com> <1280706497.23395.7.camel@dhcp-1-137.bne.redhat.com> <4C560B4A.5060403@redhat.com> <4C57B95E.3080507@redhat.com> <4C58EAFA.7050608@redhat.com> Message-ID: <4C69BB7A.7060800@redhat.com> I had a chat with Darren yesterday and it turns out the DocBook XSL has a trick for doing this, it replaces the text with '???', but it requires that validation be disabled. I'll probably be adding a --novalid option or something to the command line to make Publican skip the validation step to allow l building of invalid content ... probably lead to weird errors ... we call that "fun" people! Cheers, Jeff. -- Jeff Fearn Software Engineer Engineering Operations Red Hat, Inc Freedom ... courage ... Commitment ... ACCOUNTABILITY From bugzilla at redhat.com Thu Aug 19 04:22:03 2010 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 19 Aug 2010 00:22:03 -0400 Subject: [publican-list] [Bug 625316] New: publican break tags into separate paragraphs in .po files. Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: publican break tags into separate paragraphs in .po files. https://bugzilla.redhat.com/show_bug.cgi?id=625316 Summary: publican break tags into separate paragraphs in .po files. Product: Red Hat Enterprise Linux 5 Version: 5.5 Platform: All OS/Version: Linux Status: NEW Severity: medium Priority: low Component: publican AssignedTo: mhideo at redhat.com ReportedBy: ccheng at redhat.com QAContact: ecs-bugs at redhat.com CC: publican-list at redhat.com Classification: Red Hat Target Release: --- Description of problem: When interpreting tags in the English .xml files, publican will split this tag pair into an individual string in .po files. Version-Release number of selected component (if applicable): publican-2.1-0.el5 How reproducible: Check out RHEL 6 Release Notes from our internal repository. An revision earlier than 12:00 today. Steps to Reproduce: 1. publican update_pot 2. publican update_po --lang 3. See 's documentation.po and clustering.po Actual results: were split from a paragraph. Expected results: They should stay in the same paragraph. Additional info: N/A -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From jwulf at redhat.com Tue Aug 24 22:52:19 2010 From: jwulf at redhat.com (Joshua Wulf) Date: Wed, 25 Aug 2010 08:52:19 +1000 Subject: [publican-list] xi:include over https Message-ID: <4C744D23.2020900@redhat.com> G'day, I've managed to do xi:include via http, ala the following: This builds fine with Publican. However, when I try to do the same thing via https, ala the following: I get the following output from publican: FATAL ERROR: XInclude:1604 in DITA_Topics_in_Docbook.xml on line 9: could not load https://svn.server.com/TopicRepository/Concepts/Task.xml, and no fallback was found at /usr/bin/publican line 622 A possibly relevant issue is that the svn server uses a self-signed certificate. After much wrangling, I installed that certificate in the openssl framework on my machine, and I can now download the Task.xml file using wget with no security warning, so it's not the self-signed certificate (if libxml is using openssl). Is there any way I can get more detailed error message reporting from the libXML Perl module in publican to help figure out where the roadblock is? I tried looking through the libxml source code, but I can't get my head around the c. Alternatively, has anyone else tried this? - Josh From jfearn at redhat.com Tue Aug 24 23:37:40 2010 From: jfearn at redhat.com (Jeffrey Fearn) Date: Wed, 25 Aug 2010 09:37:40 +1000 Subject: [publican-list] xi:include over https In-Reply-To: <4C744D23.2020900@redhat.com> References: <4C744D23.2020900@redhat.com> Message-ID: <4C7457C4.8020007@redhat.com> Joshua Wulf wrote: > G'day, > > I've managed to do xi:include via http, ala the following: > > xmlns:xi="http://www.w3.org/2001/XInclude" /> > > This builds fine with Publican. > > However, when I try to do the same thing via https, ala the following: > > href="https://svn.server.com/TopicRepository/Concepts/Task.xml" > xmlns:xi="http://www.w3.org/2001/XInclude" /> > > I get the following output from publican: > > FATAL ERROR: XInclude:1604 in DITA_Topics_in_Docbook.xml on line 9: > could not load https://svn.server.com/TopicRepository/Concepts/Task.xml, > and no fallback was found > at /usr/bin/publican line 622 > > A possibly relevant issue is that the svn server uses a self-signed > certificate. After much wrangling, I installed that certificate in the > openssl framework on my machine, and I can now download the Task.xml > file using wget with no security warning, so it's not the self-signed > certificate (if libxml is using openssl). > > Is there any way I can get more detailed error message reporting from > the libXML Perl module in publican to help figure out where the > roadblock is? I tried looking through the libxml source code, but I > can't get my head around the c. This would require code changes, please open a bug along the lines of "all file parsing should have verbose output unless --quite is on". > Alternatively, has anyone else tried this? I did a google search and it doesn't appear libXML2 includes SSL support. From http://www.xmlsoft.org/intro.html: Here are some key points about libxml: ... Basic support for HTTP and FTP client allowing applications to fetch remote resources. Cheers, Jeff. -- Jeff Fearn Software Engineer Engineering Operations Red Hat, Inc Freedom ... courage ... Commitment ... ACCOUNTABILITY From jwulf at redhat.com Tue Aug 24 23:38:34 2010 From: jwulf at redhat.com (Joshua Wulf) Date: Wed, 25 Aug 2010 09:38:34 +1000 Subject: [publican-list] Machine-readable meta-data in docbook Message-ID: <4C7457FA.5070504@redhat.com> Is there a good way to include machine readable meta-data in a docbook file for use with publican? I'm thinking things like Author, Created Date, Modified Date, Validated, QE Flag, etc... Information that is useful to have, but should not be displayed in the document output. I looked at including using RDFa to do it [1], but it looks like that relies on Docbook 5. Any suggestions for Docbook 4? - Josh [1] http://norman.walsh.name/2009/09/22/RDFaForDocBook -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfearn at redhat.com Wed Aug 25 01:46:07 2010 From: jfearn at redhat.com (Jeffrey Fearn) Date: Wed, 25 Aug 2010 11:46:07 +1000 Subject: [publican-list] Machine-readable meta-data in docbook In-Reply-To: <4C7457FA.5070504@redhat.com> References: <4C7457FA.5070504@redhat.com> Message-ID: <4C7475DF.3050005@redhat.com> Joshua Wulf wrote: > Is there a good way to include machine readable meta-data in a docbook > file for use with publican? > > I'm thinking things like Author, Created Date, Modified Date, These examples exist in revhistory, which can be contained in the various *info tags and at some other block levels. e.g chapterinfo, sectioninfo, appendixinfo, para, etc. I'm pretty sure they don't get rendered if they are in these tags, but if they are we could switch that off easily enough. You could have a single revision to track current status if you didn't want the entire history. > Validated, > QE Flag, etc... IMHO these are examples of information best kept in a work flow system not in the XML. When I d/l and modify an XML it's no longer Validated and the QE flag is incorrect. It's trivial to get out of sync and have an incorrect perception of where you are at in the whole write/review/publish process. Even if you are going to keep it in the XML, since it's not being displayed and only being accessed for machine processing you could easily use existing attributes to cover this. e.g. you could add Verified or QE'd in to the revision remark. e.g. you could set the condition attribute in the revision to condition="Verified". > Information that is useful to have, but should not be > displayed in the document output. > I looked at including using RDFa to do it [1], but it looks like that > relies on Docbook 5. AIUI RDFa won't work in DocBook 4, it injects attributes from foreign name spaces in to existing tags, this requires support in the DTD to be able to run validation. Also that article ends with "So I'm not sure." so you'd need to confirm that it will actually be in DocBook 5. > Any suggestions for Docbook 4? Try the revhistory, it should cover your needs. Cheers, jeff. -- Jeff Fearn Software Engineer Engineering Operations Red Hat, Inc Freedom ... courage ... Commitment ... ACCOUNTABILITY From jwulf at redhat.com Wed Aug 25 01:54:15 2010 From: jwulf at redhat.com (Joshua Wulf) Date: Wed, 25 Aug 2010 11:54:15 +1000 Subject: [publican-list] Machine-readable meta-data in docbook In-Reply-To: <4C7475DF.3050005@redhat.com> References: <4C7457FA.5070504@redhat.com> <4C7475DF.3050005@redhat.com> Message-ID: <4C7477C7.4000507@redhat.com> On 08/25/2010 11:46 AM, Jeffrey Fearn wrote: > Joshua Wulf wrote: >> Is there a good way to include machine readable meta-data in a >> docbook file for use with publican? >> >> I'm thinking things like Author, Created Date, Modified Date, > > These examples exist in revhistory, which can be contained in the > various *info tags and at some other block levels. e.g chapterinfo, > sectioninfo, appendixinfo, para, etc. > > I'm pretty sure they don't get rendered if they are in these tags, but > if they are we could switch that off easily enough. > > You could have a single revision to track current status if you didn't > want the entire history. > >> Validated, QE Flag, etc... > > IMHO these are examples of information best kept in a work flow system > not in the XML. When I d/l and modify an XML it's no longer Validated > and the QE flag is incorrect. It's trivial to get out of sync and have > an incorrect perception of where you are at in the whole > write/review/publish process. > I agree. If we did this longer term we'd migrate the meta-data out to a dedicated container. Just looking for something to get a prototype up and running at this point. > Even if you are going to keep it in the XML, since it's not being > displayed and only being accessed for machine processing you could > easily use existing attributes to cover this. > > e.g. you could add Verified or QE'd in to the revision remark. > > e.g. you could set the condition attribute in the revision to > condition="Verified". > >> Information that is useful to have, but should not be displayed in >> the document output. > > >> I looked at including using RDFa to do it [1], but it looks like that >> relies on Docbook 5. > > AIUI RDFa won't work in DocBook 4, it injects attributes from foreign > name spaces in to existing tags, this requires support in the DTD to > be able to run validation. > > Also that article ends with "So I'm not sure." so you'd need to > confirm that it will actually be in DocBook 5. > >> Any suggestions for Docbook 4? > > Try the revhistory, it should cover your needs. > The root element of the docbook files I need to annotate are , , and possibly some other at a similar level. Anything down there that might be useable? > Cheers, jeff. > From jfearn at redhat.com Wed Aug 25 02:53:38 2010 From: jfearn at redhat.com (Jeffrey Fearn) Date: Wed, 25 Aug 2010 12:53:38 +1000 Subject: [publican-list] Machine-readable meta-data in docbook In-Reply-To: <4C7477C7.4000507@redhat.com> References: <4C7457FA.5070504@redhat.com> <4C7475DF.3050005@redhat.com> <4C7477C7.4000507@redhat.com> Message-ID: <4C7485B2.6030905@redhat.com> Joshua Wulf wrote: > On 08/25/2010 11:46 AM, Jeffrey Fearn wrote: >> Joshua Wulf wrote: >>> Is there a good way to include machine readable meta-data in a >>> docbook file for use with publican? >>> >>> I'm thinking things like Author, Created Date, Modified Date, >> >> These examples exist in revhistory, which can be contained in the >> various *info tags and at some other block levels. e.g chapterinfo, >> sectioninfo, appendixinfo, para, etc. >> >> I'm pretty sure they don't get rendered if they are in these tags, but >> if they are we could switch that off easily enough. >> >> You could have a single revision to track current status if you didn't >> want the entire history. >> >>> Validated, QE Flag, etc... >> >> IMHO these are examples of information best kept in a work flow system >> not in the XML. When I d/l and modify an XML it's no longer Validated >> and the QE flag is incorrect. It's trivial to get out of sync and have >> an incorrect perception of where you are at in the whole >> write/review/publish process. >> > I agree. If we did this longer term we'd migrate the meta-data out to a > dedicated container. Just looking for something to get a prototype up > and running at this point. > >> Even if you are going to keep it in the XML, since it's not being >> displayed and only being accessed for machine processing you could >> easily use existing attributes to cover this. >> >> e.g. you could add Verified or QE'd in to the revision remark. >> >> e.g. you could set the condition attribute in the revision to >> condition="Verified". > > >> >>> Information that is useful to have, but should not be displayed in >>> the document output. >> >> >>> I looked at including using RDFa to do it [1], but it looks like that >>> relies on Docbook 5. >> >> AIUI RDFa won't work in DocBook 4, it injects attributes from foreign >> name spaces in to existing tags, this requires support in the DTD to >> be able to run validation. >> >> Also that article ends with "So I'm not sure." so you'd need to >> confirm that it will actually be in DocBook 5. >> >>> Any suggestions for Docbook 4? >> >> Try the revhistory, it should cover your needs. >> > The root element of the docbook files I need to annotate are > , ,
and possibly some other at a > similar level. Anything down there that might be useable? If it's just to check automated access to metadata at semi-random places, why not use a remark that contains a key=value formatted string and role to identify it's use? Remark has a pretty wide range of places it can appear. e.g. author="Dave Dude" verified=false created=20100127 This way in debug mode you'd get to see where these things are set and what their values are. If you need even wider usage an alternative would be to use a similar key=value system, but use a common attribute that isn't currently used, Security, UserLevel and Vendor stand out. These can be used in any tag, but you lose the ability to easily see the values in the output and you are more constrained in what content you can put in an attribute. e.g.
It's not as tidy as using tags, but string manipulation is not a great barrier and it works around a few harder problems that you probably don't need to solve atm. If you are using machine generation to set and get the content you can just use string serialization to pack and unpack the content. Cheers, Jeff. -- Jeff Fearn Software Engineer Engineering Operations Red Hat, Inc Freedom ... courage ... Commitment ... ACCOUNTABILITY From jwulf at redhat.com Wed Aug 25 02:58:32 2010 From: jwulf at redhat.com (Joshua Wulf) Date: Wed, 25 Aug 2010 12:58:32 +1000 Subject: [publican-list] Machine-readable meta-data in docbook In-Reply-To: <4C7485B2.6030905@redhat.com> References: <4C7457FA.5070504@redhat.com> <4C7475DF.3050005@redhat.com> <4C7477C7.4000507@redhat.com> <4C7485B2.6030905@redhat.com> Message-ID: <4C7486D8.2080809@redhat.com> On 08/25/2010 12:53 PM, Jeffrey Fearn wrote: > Joshua Wulf wrote: >> On 08/25/2010 11:46 AM, Jeffrey Fearn wrote: >>> Joshua Wulf wrote: >>>> Is there a good way to include machine readable meta-data in a >>>> docbook file for use with publican? >>>> >>>> I'm thinking things like Author, Created Date, Modified Date, >>> >>> These examples exist in revhistory, which can be contained in the >>> various *info tags and at some other block levels. e.g chapterinfo, >>> sectioninfo, appendixinfo, para, etc. >>> >>> I'm pretty sure they don't get rendered if they are in these tags, >>> but if they are we could switch that off easily enough. >>> >>> You could have a single revision to track current status if you >>> didn't want the entire history. >>> >>>> Validated, QE Flag, etc... >>> >>> IMHO these are examples of information best kept in a work flow >>> system not in the XML. When I d/l and modify an XML it's no longer >>> Validated and the QE flag is incorrect. It's trivial to get out of >>> sync and have an incorrect perception of where you are at in the >>> whole write/review/publish process. >>> >> I agree. If we did this longer term we'd migrate the meta-data out to >> a dedicated container. Just looking for something to get a prototype >> up and running at this point. >> >>> Even if you are going to keep it in the XML, since it's not being >>> displayed and only being accessed for machine processing you could >>> easily use existing attributes to cover this. >>> >>> e.g. you could add Verified or QE'd in to the revision remark. >>> >>> e.g. you could set the condition attribute in the revision to >>> condition="Verified". >> >> >>> >>>> Information that is useful to have, but should not be displayed in >>>> the document output. >>> >>> >>>> I looked at including using RDFa to do it [1], but it looks like >>>> that relies on Docbook 5. >>> >>> AIUI RDFa won't work in DocBook 4, it injects attributes from >>> foreign name spaces in to existing tags, this requires support in >>> the DTD to be able to run validation. >>> >>> Also that article ends with "So I'm not sure." so you'd need to >>> confirm that it will actually be in DocBook 5. >>> >>>> Any suggestions for Docbook 4? >>> >>> Try the revhistory, it should cover your needs. >>> >> The root element of the docbook files I need to annotate are >> , ,
and possibly some other at a >> similar level. Anything down there that might be useable? > > If it's just to check automated access to metadata at semi-random > places, why not use a remark that contains a key=value formatted > string and role to identify it's use? Remark has a pretty wide range > of places it can appear. > > e.g. author="Dave Dude" verified=false > created=20100127 > > This way in debug mode you'd get to see where these things are set and > what their values are. > > If you need even wider usage an alternative would be to use a similar > key=value system, but use a common attribute that isn't currently > used, Security, UserLevel and Vendor stand out. These can be used in > any tag, but you lose the ability to easily see the values in the > output and you are more constrained in what content you can put in an > attribute. > > e.g.
> > It's not as tidy as using tags, but string manipulation is not a great > barrier and it works around a few harder problems that you probably > don't need to solve atm. If you are using machine generation to set > and get the content you can just use string serialization to pack and > unpack the content. > > Cheers, Jeff. > Sounds good. Atm we have SHOW_REMARKS as an option. Could we filter that on role for remarks, to allow metadata to be or not to be shown when remarks are enabled? At the moment remarks are used for communicating with QE. From jfearn at redhat.com Wed Aug 25 03:11:48 2010 From: jfearn at redhat.com (Jeffrey Fearn) Date: Wed, 25 Aug 2010 13:11:48 +1000 Subject: [publican-list] Machine-readable meta-data in docbook In-Reply-To: <4C7486D8.2080809@redhat.com> References: <4C7457FA.5070504@redhat.com> <4C7475DF.3050005@redhat.com> <4C7477C7.4000507@redhat.com> <4C7485B2.6030905@redhat.com> <4C7486D8.2080809@redhat.com> Message-ID: <4C7489F4.6010603@redhat.com> Joshua Wulf wrote: >>> The root element of the docbook files I need to annotate are >>> , ,
and possibly some other at a >>> similar level. Anything down there that might be useable? >> >> If it's just to check automated access to metadata at semi-random >> places, why not use a remark that contains a key=value formatted >> string and role to identify it's use? Remark has a pretty wide range >> of places it can appear. >> >> e.g. author="Dave Dude" verified=false >> created=20100127 >> >> This way in debug mode you'd get to see where these things are set and >> what their values are. >> >> If you need even wider usage an alternative would be to use a similar >> key=value system, but use a common attribute that isn't currently >> used, Security, UserLevel and Vendor stand out. These can be used in >> any tag, but you lose the ability to easily see the values in the >> output and you are more constrained in what content you can put in an >> attribute. >> >> e.g.
>> >> It's not as tidy as using tags, but string manipulation is not a great >> barrier and it works around a few harder problems that you probably >> don't need to solve atm. If you are using machine generation to set >> and get the content you can just use string serialization to pack and >> unpack the content. >> >> Cheers, Jeff. >> > > Sounds good. > > Atm we have SHOW_REMARKS as an option. Could we filter that on role for > remarks, to allow metadata to be or not to be shown when remarks are > enabled? At the moment remarks are used for communicating with QE. If it turned out that this was the way things were definitely going to be used we'd do that. Once you have a demo of what you want someone might come up with a much better way of doing it than using remarks though. In the mean time you could use the condition attribute in the remark so it gets ignored when sending content to QE. A more generic RFE would be for SHOW_REMARKS to be tied to UserLevel, with only remarks with UserLevel <= SHOW_REMARKS being displayed. Then you can set SHOW_REMARKS=1 but set UserLevel=2 in the metadata remarks, and other people could use it with other work flows. Cheers, Jeff. -- Jeff Fearn Software Engineer Engineering Operations Red Hat, Inc Freedom ... courage ... Commitment ... ACCOUNTABILITY From marco.peterseil at gmail.com Wed Aug 25 09:24:06 2010 From: marco.peterseil at gmail.com (Marco Peterseil) Date: Wed, 25 Aug 2010 11:24:06 +0200 Subject: [publican-list] problem with xref linkend - mismatched tag Message-ID: hi maybe someone can help me. building with publican always shows "mismatched tag" at the xref line. i think the syntax is correct 'cause i can make it without any problems with docbook2html. ----
To check the status of the ndmod broker module read .
---- fedora 13 64bit publican version=2.1 regards marco From jwulf at redhat.com Wed Aug 25 10:53:59 2010 From: jwulf at redhat.com (Joshua Wulf) Date: Wed, 25 Aug 2010 20:53:59 +1000 Subject: [publican-list] problem with xref linkend - mismatched tag In-Reply-To: References: Message-ID: <4C74F647.80309@redhat.com> On 08/25/2010 07:24 PM, Marco Peterseil wrote: > hi > maybe someone can help me. > building with publican always shows "mismatched tag" at the xref line. > i think the syntax is correct 'cause i can make it without any > problems with docbook2html. > > ---- > >
> To check the status of the ndmod broker module read linkend="sect-nagios-nagvis-overview">. >
> > ---- > > fedora 13 64bit > publican version=2.1 > > regards > marco > > _______________________________________________ > publican-list mailing list > publican-list at redhat.com > https://www.redhat.com/mailman/listinfo/publican-list > Wiki: https://fedorahosted.org/publican > > try: From marco.peterseil at gmail.com Wed Aug 25 10:58:38 2010 From: marco.peterseil at gmail.com (Marco Peterseil) Date: Wed, 25 Aug 2010 12:58:38 +0200 Subject: [publican-list] problem with xref linkend - mismatched tag In-Reply-To: <4C74F647.80309@redhat.com> References: <4C74F647.80309@redhat.com> Message-ID: oh man. what a tiny problem ;) thanks. 2010/8/25 Joshua Wulf : > ?On 08/25/2010 07:24 PM, Marco Peterseil wrote: >> >> hi >> maybe someone can help me. >> building with publican always shows "mismatched tag" at the xref line. >> i think the syntax is correct 'cause i can make it without any >> problems with docbook2html. >> >> ---- >> >>
>> To check the status of the ndmod broker module read> linkend="sect-nagios-nagvis-overview">. >>
>> >> ---- >> >> fedora 13 64bit >> publican version=2.1 >> >> regards >> marco >> >> _______________________________________________ >> publican-list mailing list >> publican-list at redhat.com >> https://www.redhat.com/mailman/listinfo/publican-list >> Wiki: https://fedorahosted.org/publican >> >> > try: > > linkend="sect-nagios-nagvis-overview" /> > > _______________________________________________ > publican-list mailing list > publican-list at redhat.com > https://www.redhat.com/mailman/listinfo/publican-list > Wiki: https://fedorahosted.org/publican > From strider at gnome.org Thu Aug 26 07:56:17 2010 From: strider at gnome.org (=?ISO-8859-1?Q?Ga=EBl_Chamoulaud?=) Date: Thu, 26 Aug 2010 09:56:17 +0200 Subject: [publican-list] Fwd: Publican create_site and default langs In-Reply-To: <4C5C7545.1020809@redhat.com> References: <4C5C7545.1020809@redhat.com> Message-ID: Hi Everybody, I did exactly what you described and it sounds good about the localization. $ publican create_site --site_config foomaster.cfg --db_file foomaster.db --toc_path html/docs I created two Publican Article, one in fr-FR and another one in en-US: $ publican create --type Article --name Home_Page --lang en-US $ publican create --type Article --name Home_Page1 --lang fr-FR Edited the publican.cfg and added the lines below. web_home: 1 web_host: http://localhost def_lang: fr-FR (so the french Article) I built These two articles and published them on the my publican site. So when I am going to view my publican website, I am getting these issues: ++-------------------------------------------------------------+ ++ Ga?l Chamoulaud (Strider) ++ Work Phone: +33 (0)6 45 17 75 29 ++ Website: http://www.gnome.org/~strider ++ Gnome: ++ Gmail: ++ Work: ++ ++ "La bi?re est la preuve que Dieu nous aime et veut ++ que nous soyons heureux." [Benjamin Franklin] ++ ++ () ascii ribbon campaign - against html e-mail ++ /\ www.asciiribbon.org - against proprietary attachments ++-------------------------------------------------------------+ On Fri, Aug 6, 2010 at 10:49 PM, Ruediger Landmann wrote: > On 08/06/2010 07:00 PM, Ga?l Chamoulaud wrote: > >> Hi there, >> >> I want to create a site with publican, which rocks ! >> >> FYI, This site has to be in french with all the french documentation we >> did >> in french too. >> >> So, when I am creating the site, I'm getting this message "No langs Found, >> using default langs" >> And, there is no --lang(s) parameters for publican create_site :/ >> >> $ publican create_site --site_config homepage.cfg --db_file ntw.db >> --toc_path ntw_html >> No langs found, using default langs >> No langs found, using default langs >> No langs found, using default langs >> >> What I have to do to create my documentation site in french ? >> > > Hi Ga?l and thanks for your kind words > > Unfortunately, internationalization and localization for the website > component are not fully implemented yet. The following notes describe the > situation as it currently exists: > > -------------------------------- > 1. create_site > -------------------------------- > All Publican websites are multi-lingual; the site attempts to present > content based on the locale reported by the visitor's web browser. > Therefore, there is nothing special that you must do to build the site > framework in French during the "create_site" stage. Please ignore the "No > langs found" warning; it does not affect your site creation. > > However, at the moment, if the site JavaScript cannot match the user's > locale with content on the site, it redirects them to American English. You > can manually fix this -- edit the index.html file (for example, > ntw_html/html.index) and look for the lines that say: > > var locales = ["en-US"]; > > and > > if(match == 0) { > lang = 'en-US'; > } > > In both cases, change "en-US" to "fr-FR". Note that if you ever run > publican update_site to refresh the site, you will need to make these > changes again because this file is overwritten each time. > > I've opened an RFE to avoid having to do this manually in future versions > of Publican [0] > > -------------------------------- > 2. Creating the homepage > -------------------------------- > When you create the site homepage (as described in section 6.2 of the > Publican Users' Guide), you should: > > 1. set the --lang parameter to French when you create this "book", for > example: > > publican create --type Article --name Bienvenue --lang fr-FR > > 2. edit the publican.cfg file for this "book" to include the line: > > def_lang: fr-FR > > -------------------------------- > Untranslated content > -------------------------------- > Some features of the website will still appear in English, because nobody > has translated them into French yet in Publican :) > > For example, the contents of the "Statistics" and "Site Tech" pages are > generated in English, and all the navigation elements such as "collapse > all", "Search", "Untranslated" > > If you would like to add French support for these elements in Publican and > are already a member of the Fedora localization project, you can translate > them through Fedora's Transifex interface.[1][2] If you would like to help > us but are not a member of the Fedora localization project, please contact > me off-list. > > Cheers > Rudi > > > > > [0] https://bugzilla.redhat.com/show_bug.cgi?id=622030 > > [1] https://translate.fedoraproject.org/projects/p/publican/c/trunk/ > > [2] https://translate.fedoraproject.org/projects/p/publican/c/site_tech/ > > _______________________________________________ > publican-list mailing list > publican-list at redhat.com > https://www.redhat.com/mailman/listinfo/publican-list > Wiki: https://fedorahosted.org/publican > -------------- next part -------------- An HTML attachment was scrubbed... URL: From strider at gnome.org Thu Aug 26 08:01:22 2010 From: strider at gnome.org (=?ISO-8859-1?Q?Ga=EBl_Chamoulaud?=) Date: Thu, 26 Aug 2010 10:01:22 +0200 Subject: [publican-list] Fwd: Publican create_site and default langs In-Reply-To: References: <4C5C7545.1020809@redhat.com> Message-ID: Sorry I pressed the wrong button and sent my unfinished email ! Here is my issues ! So when I am going to view my publican website, I am getting these issues: By default I am guided to the first Article in English. I can view the Iframe but no one of my Articles are present in the navigation menu! and When I am going to the french article, I have no navigation menu and this message: File not found. Firefox can't find the file at /home/m011640/DEV/ARAMICE/GIT/linux-docs/web/html/docs/fr-FR/toc.html. Thanks for your help ! Cheers =GC On Thu, Aug 26, 2010 at 9:56 AM, Ga?l Chamoulaud wrote: > Hi Everybody, > > I did exactly what you described and it sounds good about the localization. > > $ publican create_site --site_config foomaster.cfg --db_file foomaster.db > --toc_path html/docs > > I created two Publican Article, one in fr-FR and another one in en-US: > > $ publican create --type Article --name Home_Page --lang en-US > $ publican create --type Article --name Home_Page1 --lang fr-FR > > Edited the publican.cfg and added the lines below. > web_home: 1 > web_host: http://localhost > def_lang: fr-FR (so the french Article) > > I built These two articles and published them on the my publican site. > > So when I am going to view my publican website, I am getting these issues: > > > ++-------------------------------------------------------------+ > ++ Ga?l Chamoulaud (Strider) > ++ Work Phone: +33 (0)6 45 17 75 29 > ++ Website: http://www.gnome.org/~strider > > ++ Gnome: > ++ Gmail: > ++ Work: > ++ > ++ "La bi?re est la preuve que Dieu nous aime et veut > ++ que nous soyons heureux." [Benjamin Franklin] > ++ > ++ () ascii ribbon campaign - against html e-mail > ++ /\ www.asciiribbon.org - against proprietary attachments > ++-------------------------------------------------------------+ > > > > On Fri, Aug 6, 2010 at 10:49 PM, Ruediger Landmann wrote: > >> On 08/06/2010 07:00 PM, Ga?l Chamoulaud wrote: >> >>> Hi there, >>> >>> I want to create a site with publican, which rocks ! >>> >>> FYI, This site has to be in french with all the french documentation we >>> did >>> in french too. >>> >>> So, when I am creating the site, I'm getting this message "No langs >>> Found, >>> using default langs" >>> And, there is no --lang(s) parameters for publican create_site :/ >>> >>> $ publican create_site --site_config homepage.cfg --db_file ntw.db >>> --toc_path ntw_html >>> No langs found, using default langs >>> No langs found, using default langs >>> No langs found, using default langs >>> >>> What I have to do to create my documentation site in french ? >>> >> >> Hi Ga?l and thanks for your kind words >> >> Unfortunately, internationalization and localization for the website >> component are not fully implemented yet. The following notes describe the >> situation as it currently exists: >> >> -------------------------------- >> 1. create_site >> -------------------------------- >> All Publican websites are multi-lingual; the site attempts to present >> content based on the locale reported by the visitor's web browser. >> Therefore, there is nothing special that you must do to build the site >> framework in French during the "create_site" stage. Please ignore the "No >> langs found" warning; it does not affect your site creation. >> >> However, at the moment, if the site JavaScript cannot match the user's >> locale with content on the site, it redirects them to American English. You >> can manually fix this -- edit the index.html file (for example, >> ntw_html/html.index) and look for the lines that say: >> >> var locales = ["en-US"]; >> >> and >> >> if(match == 0) { >> lang = 'en-US'; >> } >> >> In both cases, change "en-US" to "fr-FR". Note that if you ever run >> publican update_site to refresh the site, you will need to make these >> changes again because this file is overwritten each time. >> >> I've opened an RFE to avoid having to do this manually in future versions >> of Publican [0] >> >> -------------------------------- >> 2. Creating the homepage >> -------------------------------- >> When you create the site homepage (as described in section 6.2 of the >> Publican Users' Guide), you should: >> >> 1. set the --lang parameter to French when you create this "book", for >> example: >> >> publican create --type Article --name Bienvenue --lang fr-FR >> >> 2. edit the publican.cfg file for this "book" to include the line: >> >> def_lang: fr-FR >> >> -------------------------------- >> Untranslated content >> -------------------------------- >> Some features of the website will still appear in English, because nobody >> has translated them into French yet in Publican :) >> >> For example, the contents of the "Statistics" and "Site Tech" pages are >> generated in English, and all the navigation elements such as "collapse >> all", "Search", "Untranslated" >> >> If you would like to add French support for these elements in Publican and >> are already a member of the Fedora localization project, you can translate >> them through Fedora's Transifex interface.[1][2] If you would like to help >> us but are not a member of the Fedora localization project, please contact >> me off-list. >> >> Cheers >> Rudi >> >> >> >> >> [0] https://bugzilla.redhat.com/show_bug.cgi?id=622030 >> >> [1] https://translate.fedoraproject.org/projects/p/publican/c/trunk/ >> >> [2] https://translate.fedoraproject.org/projects/p/publican/c/site_tech/ >> >> _______________________________________________ >> publican-list mailing list >> publican-list at redhat.com >> https://www.redhat.com/mailman/listinfo/publican-list >> Wiki: https://fedorahosted.org/publican >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.landmann at redhat.com Thu Aug 26 23:05:10 2010 From: r.landmann at redhat.com (Ruediger Landmann) Date: Fri, 27 Aug 2010 09:05:10 +1000 Subject: [publican-list] Fwd: Publican create_site and default langs In-Reply-To: References: <4C5C7545.1020809@redhat.com> Message-ID: <4C76F326.1060604@redhat.com> On 08/26/2010 05:56 PM, Ga?l Chamoulaud wrote: > Hi Everybody, > > I did exactly what you described and it sounds good about the localization. > > $ publican create_site --site_config foomaster.cfg --db_file foomaster.db > --toc_path html/docs > > I created two Publican Article, one in fr-FR and another one in en-US: > > $ publican create --type Article --name Home_Page --lang en-US > $ publican create --type Article --name Home_Page1 --lang fr-FR You can only have one Home Page, which you can translate into as many languages as you need. To illustrate: ================ 1. Create the home page in your default language: publican create --type Article --name Home_Page --lang fr-FR 2. Change into the the directory that holds the article you just created: cd Home_Page 3. Write the content of your home page by editing the XML files in Home_Page/fr-FR/ 4. Generate translation templates for the article: publican update_pot 5. Generate an English translation for the article: publican update_po --langs en-US 6. Translate the content of your home page into English by editing the PO files in Home_Page/en-US 7. Build the home page in both French and English: publican build --publish --formats html-single --embedtoc --langs all 8. Publish both the French and English home pages on your site: publican install_book --site_config /path/to/config/file/foomaster.cfg --lang fr-FR publican install_book --site_config /path/to/config/file/foomaster.cfg --lang en-US Where /path/to/config/file/foomaster.cfg is the path to the site config file, here named "foomaster.cfg". ================ The structure is now ready for you to publish books and articles to it. The tables of contents will be empty in both languages until you publish at least one book or article to the site. For example: ================ 1. Change into the directory that holds the book: cd Guide_de_configuration_Foomaster 2. Build the book: publican build --formats html-single,html,pdf,epub --langs fr-FR --publish --embedtoc 3. Install the book on the site: publican install_book --site_config /path/to/config/file/foomaster.cfg --lang fr-FR Where /path/to/config/file/foomaster.cfg is the path to the site config file, here named "foomaster.cfg". ================ You should now see "Guide de configuration Foomaster" available on the French version of the menu, and available on the English version of the menu under an "untranslated" heading. Hope this helps! Cheers Rudi From jwulf at redhat.com Mon Aug 30 00:41:49 2010 From: jwulf at redhat.com (Joshua Wulf) Date: Mon, 30 Aug 2010 10:41:49 +1000 Subject: [publican-list] Per-product landing page Message-ID: <4C7AFE4D.8080600@redhat.com> With Publican website, is it possible to land on product page, where all the versions of a single product are linked? Previously we would direct readers to a product landing page as a way of making the link version-independent. At the moment I can't see a way to refer them to another guide without linking them to a page in to a specific version. - Josh From jfearn at redhat.com Mon Aug 30 01:04:54 2010 From: jfearn at redhat.com (Jeff Fearn) Date: Mon, 30 Aug 2010 11:04:54 +1000 Subject: [publican-list] Per-product landing page In-Reply-To: <4C7AFE4D.8080600@redhat.com> References: <4C7AFE4D.8080600@redhat.com> Message-ID: <1283130294.2536.13.camel@captcha> On Mon, 2010-08-30 at 10:41 +1000, Joshua Wulf wrote: > With Publican website, is it possible to land on product page, where > all the versions of a single product are linked? No. There is a BZ for this, discussions on how to handle it are ongoing. ATM we are leaning towards: * having a page with a blurb about the product [1] * automating the nav menu to open the product * automate the nav menu to open to books you land on [2] * stop hiding the formats in the menu [3] [1] This would work similar to home pages. [2] This is so if you send a link to a particulate page you get the product and version revealed in he menu. existing books would need to be rebuilt to add this functionality. [3] So you can click on the format you want without going to html-chunked first. Cheers, Jeff. -- Jeff Fearn Software Engineer Engineering Operations Red Hat, Inc Freedom ... courage ... Commitment ... ACCOUNTABILITY Sure our competitors can rebuild the source but can they engage the customer the same way? -wmealing