Re: [lazarus] Lazarus Help System Requirements
That is an excellent tip! We should mention it somewhere on the Wiki. Graeme. On 5/17/06, L505 [EMAIL PROTECTED] wrote: On 5/17/06, L505 [EMAIL PROTECTED] wrote: The reason I currently use Google to search for freepascal documentation on the RTL instead of using my local copy of my help documents, is because Google itself is my database that powers the search of the freepascal documentation. Some of you just Just for interest sake, how do you use Google? Using the site: command in the search box...? eg: site:freepascal.org GetPropValue Exactly: site:freepascal.org docs The keyword docs helps filter out mailing list stuff and other pages.. if you just want to target in on the Documentatoin just type in Docs keyword in addition to the site. So: site:freepascal.org docs getpropvalue instead of just site:freepascal.org getpropvalue And don't always use this: site:www.freepascal.org Skip the www prefix, incase you find something in community.freepascal, etc. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives -- There's no place like 127.0.0.1 _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus Help System Requirements
On 5/17/06, L505 [EMAIL PROTECTED] wrote:
So:
site:freepascal.org docs getpropvalue
instead of just
site:freepascal.org getpropvalue
Okay, to extent on your example and make it even easier to do
searching I have created two dynamic bookmarks. I have tested them in
Mozilla Firefox, but should also work in Netscape. Not sure about IE
(please let me know).
You create a new bookmark on your Bookmark Toolbar. When you click
the bookmark, it prompts you for your keyword(s) to search and
launches Google .
There should be no wrapping of text so please fix this when you create
you bookmarks.
Bookmark #1
Name: Search FPC docs (includes mailing lists)
URL Location:
javascript:Qr=document.getSelection();if(!Qr){void(Qr=prompt('Enter
your
Keywords...',''))};if(Qr)location.href='http://www.google.com/search?hl=enq=site:freepascal.org+'+escape(Qr)
Bookmark #2
Name: Search FPC docs only
URL Location:
javascript:Qr=document.getSelection();if(!Qr){void(Qr=prompt('Enter
your
Keywords...',''))};if(Qr)location.href='http://www.google.com/search?hl=enq=site:freepascal.org+docs+'+escape(Qr)
Have fun!!
Regards,
Graeme.
--
There's no place like 127.0.0.1
_
To unsubscribe: mail [EMAIL PROTECTED] with
unsubscribe as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus Help System Requirements
Graeme Geldenhuys wrote: That is an excellent tip! We should mention it somewhere on the Wiki. Graeme. On 5/17/06, L505 [EMAIL PROTECTED] wrote: On 5/17/06, L505 [EMAIL PROTECTED] wrote: The reason I currently use Google to search for freepascal documentation on the RTL instead of using my local copy of my help documents, is because Google itself is my database that powers the search of the freepascal documentation. Some of you just Just for interest sake, how do you use Google? Using the site: command in the search box...? eg: site:freepascal.org GetPropValue Exactly: site:freepascal.org docs The keyword docs helps filter out mailing list stuff and other pages.. if you just want to target in on the Documentatoin just type in Docs keyword in addition to the site. So: site:freepascal.org docs getpropvalue instead of just site:freepascal.org getpropvalue And don't always use this: site:www.freepascal.org Skip the www prefix, incase you find something in community.freepascal, etc. Can anybody explain, why googling with: site:lazarus-ccr.sourceforge.net dynamicarray only gives two hits, but not http://lazarus-ccr.sourceforge.net/docs/lcl/dynamicarray/index.html It is a pity, that the most up to date docs are not completely indexed. Vincent. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus Help System Requirements
On 5/18/06, Vincent Snijders [EMAIL PROTECTED] wrote: Can anybody explain, why googling with: site:lazarus-ccr.sourceforge.net dynamicarray only gives two hits, but not http://lazarus-ccr.sourceforge.net/docs/lcl/dynamicarray/index.html It is a pity, that the most up to date docs are not completely indexed. I was just thinking along the same lines. Google is so busy, it takes a long while to keep indexes up-to-date against constant changing sites. This is going to be the only drawback of using Google to search docs. Graeme. -- There's no place like 127.0.0.1 _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus Help System Requirements
Graeme Geldenhuys wrote: On 5/18/06, Vincent Snijders [EMAIL PROTECTED] wrote: Can anybody explain, why googling with: site:lazarus-ccr.sourceforge.net dynamicarray only gives two hits, but not http://lazarus-ccr.sourceforge.net/docs/lcl/dynamicarray/index.html It is a pity, that the most up to date docs are not completely indexed. I was just thinking along the same lines. Google is so busy, it takes a long while to keep indexes up-to-date against constant changing sites. I think this particular page has been there for months now. Other pages for over a year. So that is not a good explanation. Vincent _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus Help System Requirements
Can anybody explain, why googling with: site:lazarus-ccr.sourceforge.net dynamicarray only gives two hits, but not http://lazarus-ccr.sourceforge.net/docs/lcl/dynamicarray/index.html It is a pity, that the most up to date docs are not completely indexed. I was just thinking along the same lines. Google is so busy, it takes a long while to keep indexes up-to-date against constant changing sites. This is going to be the only drawback of using Google to search docs. That's the catch22 - I deal with this problem every month with websites. Google indexes 200,000-500,000 pages one month and then next month it drops down to 1,000 or even 200. It's a roller coaster just like the stock market. This would be where having your own help doc indexing system would help. But to put less load on the freepascal/lazarus servers it is obviously wise to have a client side program indexing system like chm/local db/whatever. Still, more important than indexing the docs is writing them - if they weren't written, there wouldn't be anything to index - and Michael and others have done excellent job there. How about google desktop search? LOL I haven't tried that one.. place google desktop search on the FPC docs directory and see what happens? _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus Help System Requirements
On 5/18/06, L505 [EMAIL PROTECTED] wrote: excellent job there. How about google desktop search? LOL I haven't tried that one.. place google desktop search on the FPC docs directory and see what happens? Excellent, never though of that either. That should work brilliantly. Now the only snag, is Google Desktop Search available for Linux yet? Regards, Graeme. -- There's no place like 127.0.0.1 _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus Help System Requirements
On 5/18/06, Vincent Snijders [EMAIL PROTECTED] wrote: Can anybody explain, why googling with: site:lazarus-ccr.sourceforge.net dynamicarray only gives two hits, but not http://lazarus-ccr.sourceforge.net/docs/lcl/dynamicarray/index.html I think this particular page has been there for months now. Other pages for over a year. So that is not a good explanation. Do those pages not maybe contain some metatags (I think that is what they are called) or tags that Google doesn't like, so doesn't index them fully. I know you get metatags to tell search engines more about your site and what not to index. Just a guess. Regards, Graeme. -- There's no place like 127.0.0.1 _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus Help System Requirements
On Thu, 18 May 2006 09:43:27 +0200 Vincent Snijders [EMAIL PROTECTED] wrote: Graeme Geldenhuys wrote: That is an excellent tip! We should mention it somewhere on the Wiki. Graeme. On 5/17/06, L505 [EMAIL PROTECTED] wrote: On 5/17/06, L505 [EMAIL PROTECTED] wrote: The reason I currently use Google to search for freepascal documentation on the RTL instead of using my local copy of my help documents, is because Google itself is my database that powers the search of the freepascal documentation. Some of you just Just for interest sake, how do you use Google? Using the site: command in the search box...? eg: site:freepascal.org GetPropValue Exactly: site:freepascal.org docs The keyword docs helps filter out mailing list stuff and other pages.. if you just want to target in on the Documentatoin just type in Docs keyword in addition to the site. So: site:freepascal.org docs getpropvalue instead of just site:freepascal.org getpropvalue And don't always use this: site:www.freepascal.org Skip the www prefix, incase you find something in community.freepascal, etc. Can anybody explain, why googling with: site:lazarus-ccr.sourceforge.net dynamicarray only gives two hits, but not http://lazarus-ccr.sourceforge.net/docs/lcl/dynamicarray/index.html It is a pity, that the most up to date docs are not completely indexed. The google cache date of the LCL page is 26 Jul 2005 13:42:36 GMT. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus Help System Requirements
2006/5/17, L505 [EMAIL PROTECTED]: Our psp devel mailing list has grown more in 2006 already than expected. But be warned that PSP is not a perfect copy of Websnap/intraweb. PSP is definitely not copying Borland because we found that Websnap architecture was too complex. Although, many HTML helpers and visual tools are being worked on, and we are working on more plug-ins for lazarus and MSEGUI/MSEIDE and other text editors to make web development more organized and easier. I must say I had a lot of fun reading your 'PWU For Corporate Idiots'. As for the Websnap thing, I did not tought about it; but I once imagined that as we have support for gtk / qt / win32... we could have a layer for 'psp' so as to generate forms in web format. (And push it a little bit more and you can have a full AJAX application compiled with lazarus. But this kind of stuff is no more freepascal.) So a CGI that generate a perfect replresentation of a screen designed in lazarus could be done all from lazarus itself. Add the same features for reports,etc. That would be awesome. You switch from gtk destination to psp destination and the same project that was a stand-alone app becomes a cgi that can generate itself its visual representation and call back itself to process the commands. (That would require some javascrip... ajax crap). Any-way this might not be the good place to talk about that. And this 'vision' is only mine. As far as I can see it, psp is actually a nice technology kit to build cgi apps for the web. Best regards. -- Alexandre Leclerc _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus Help System Requirements
As for the Websnap thing, I did not tought about it; but I once imagined that as we have support for gtk / qt / win32... we could have a layer for 'psp' so as to generate forms in web format. (And push it a little bit more and you can have a full AJAX application compiled with lazarus. But this kind of stuff is no more freepascal.) So a CGI that generate a perfect replresentation of a screen designed in lazarus could be done all from lazarus itself. Add the same features for reports,etc. That would be awesome. You switch from gtk destination to psp destination and the same project that was a stand-alone app becomes a cgi that can generate itself its visual representation and call back itself to process the commands. (That would require some javascrip... ajax crap). With CSS absolute pixel positioning (rather than relative positioning) to have things land on the screen at your desired destination using X/Y coordinates.. But as soon as you get into x/y coordinate positioning it means your app might be better off as a real thin client application anyway. But Ajax means no shipping of the application. At least it means that right now - in the future ajax might be able to read special config files in the form of cookies, or something - to me it seems sort of like reinventing thin clients.. but are there other advantages I'm missing of ajax, other than you don't have to ship it like you do a thin client (and you don't have to compile it). A good example of a thin client that works well, but is not ajax - AVG antivirus for windows. It is a real software application that connects to the internet every day to upgrade your virus definition. And it works perfectly. There was no need for AVG to become an ajax app because being a real app worked too - AVG could be an ajax app - you could log on to the AVG website and have it check your PC for viruses - but if it works well as a non-ajax app why not just ship it as a non-web program. Well I guess it means that AVG is stuck shipping their app, and that they could have used ajax if they didn't want to ship it - or they could have used VBScript based website. But is shipping really that hard of an effort? Shipping an app is a hard effort, but is it worth the effort? I think in many cases it's worth shipping an app - maybe in the cases where it is not worth shipping an app ajax is the solution? Well one advantage of AJAX is that no shipping or installing of the program is needed - but eventually if Ajax becomes complex enough that it can store data on your PC, such as config files, skins, etc, then I think it is essentially reinventing the thin client.. I mean let's say it uses cookies to store your skin or your configuration for the ajax app - well isn't this just a config file? So it really is just shipping a config file onto your computer in the form of a cookie - but if it gets complex enough that the cookie is to simplified and it needs to store other Lots of the work I do on the web actually requires my web pages to have tons of text on the pages so that my sites become popular on the search engines - so the whole AJAX thing is kind of wishy washy to me for those things.. but it is not always just about getting your thousands of text pages on the engines.. But I mean it also begs the question - if you are going to make an AJAX app why not just compile a lazarus application and send it to your users - have TCP/IP in the program connect to your web server, compile your lazarus app on all platforms and ship the EXE/ELF/BSDexe. I guess AJAX requires no shipping of the application, and no installation of the application. Right now my main focus with web development is building websites with 200,000-500,000 pages of content - or at least thousands of pages of content - so ajax doesn't help there much, but it could be useful for things like banking websites where people need to see a proper graph of their investments, and proper sessions on the website without sending an HTTP request for each little thing they do on the site (the whole point of ajax) Any-way this might not be the good place to talk about that. And this 'vision' is only mine. As far as I can see it, psp is actually a nice technology kit to build cgi apps for the web. You can join the mailing list if you like.. http://psp.furtopia.org/cgi-bin/psp/maillist.psp We have done some work with CSS/HTML to get direct positioning available on the screen - we try to use CSS whereever possibel and only use Javascript where absolutely needed Actually, Tony on our team has made a web application that is sort of like Ajax - it uses javascript and CSS/HTMl and is an mp3 player that works right inside the web browser, like a real software application works. In this case, Tony may have invented Ajax himself, but he just really wasn't calling it Ajax. I'm sort of a mix myself - I can see Ajax advantages but I also like building huge 200,000 page websites with
Re: [lazarus] Lazarus Help System Requirements
one. For the moment I'm sticking on my SQLite+html idea. The html format Ça va. What about a SQLLite database that stores the help info, and a php script that calls that database... Just my 2 cents. - Marco Aurelio Ramirez Carrillo lazarus dot mramirez at star-dev dot com [dot mx] _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus Help System Requirements
one. For the moment I'm sticking on my SQLite+html idea. The html format Ça va. What about a SQLLite database that stores the help info, and a php script that calls that database... No PHP required really. A CGI program written in Pascal that calls some sort of database, and a desktop application that can call that database too. This keeps only one codebase needed for the entire help system - the same database is used for both the web docs and the desktop docs - just that the desktop doc is using an embedded database while the web application may use a real full fledged version of the database. But most websites will only need to use an embedded database because 99 percent of all Pascal applications are not going to have high traffic websites that require a database that can do complex queries fast. Especially on help documents which people will rarely be checking on the website, since they have a local copy - the online docs are mainly for promotional purposes to get a bunch of keyword heavy pages out on the net promoting your software. The reason I currently use Google to search for freepascal documentation on the RTL instead of using my local copy of my help documents, is because Google itself is my database that powers the search of the freepascal documentation. Some of you just use grep maybe - I laugh at those people. But if I had a proper local database there would be no need to search google. Whether the database is a CHM database or an embedded DBF or SQL database doesn't matter - the disadvantage of CHM is simply that I can't port CHM to the web database in one shot - since a CHM database won't work on a website. And for those special cases where you have a Windows CE computer, that can't run an embedded database? Think again, most likely someone has already ported the database to Windows CE. CHM format was never intended to work on Windows CE so CHM be an external dependency, as you'd have to have the user download an external CHM reader for Windows CE. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus Help System Requirements
2006/5/17, L505 [EMAIL PROTECTED]: one. For the moment I'm sticking on my SQLite+html idea. The html format Ça va. What about a SQLLite database that stores the help info, and a php script that calls that database... No PHP required really. A CGI program written in Pascal that calls some sort of We should od it in PSP (http://www.psp.furtopia.org/cgi-bin/psp/index.psp) :) I think it would ba a shame for us not to do a pascal cgi for such a job. ;) -- Alexandre Leclerc _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus Help System Requirements
2006/5/17, Alexandre Leclerc [EMAIL PROTECTED]: 2006/5/17, L505 [EMAIL PROTECTED]: one. For the moment I'm sticking on my SQLite+html idea. The html format Ça va. What about a SQLLite database that stores the help info, and a php script that calls that database... No PHP required really. A CGI program written in Pascal that calls some sort of We should od it in PSP (http://www.psp.furtopia.org/cgi-bin/psp/index.psp) :) I think it would ba a shame for us not to do a pascal cgi for such a job. ;) :D I just saw that you are the guy with the PasWiki :) LOL! -- Alexandre Leclerc _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus Help System Requirements
On 5/17/06, L505 [EMAIL PROTECTED] wrote: The reason I currently use Google to search for freepascal documentation on the RTL instead of using my local copy of my help documents, is because Google itself is my database that powers the search of the freepascal documentation. Some of you just Just for interest sake, how do you use Google? Using the site: command in the search box...? eg: site:freepascal.org GetPropValue Regards, Graeme. -- There's no place like 127.0.0.1 _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus Help System Requirements
On 5/17/06, L505 [EMAIL PROTECTED] wrote: The reason I currently use Google to search for freepascal documentation on the RTL instead of using my local copy of my help documents, is because Google itself is my database that powers the search of the freepascal documentation. Some of you just Just for interest sake, how do you use Google? Using the site: command in the search box...? eg: site:freepascal.org GetPropValue Exactly: site:freepascal.org docs The keyword docs helps filter out mailing list stuff and other pages.. if you just want to target in on the Documentatoin just type in Docs keyword in addition to the site. So: site:freepascal.org docs getpropvalue instead of just site:freepascal.org getpropvalue And don't always use this: site:www.freepascal.org Skip the www prefix, incase you find something in community.freepascal, etc. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus Help System Requirements
2006/5/17, L505 [EMAIL PROTECTED]: one. For the moment I'm sticking on my SQLite+html idea. The html format Ça va. What about a SQLLite database that stores the help info, and a php script that calls that database... No PHP required really. A CGI program written in Pascal that calls some sort of We should od it in PSP (http://www.psp.furtopia.org/cgi-bin/psp/index.psp) :) I think it would ba a shame for us not to do a pascal cgi for such a job. ;) Thanks for recommending the site. I actually recently upgraded the site to have a new look. Micha once told me off for table designed websites because they Sux0r. Trustmaster originally threw up the PSP website many years ago which used Tables. I'm converting the PSP website to pure Div based site soon. It uses Div's now but still old table code exists :-) If Micha is listening I wanted to thank him now for getting me out of my stubborn table design thinking I used to be stuck in, because all sites I've created with Div's are working out nicely. Our psp devel mailing list has grown more in 2006 already than expected. But be warned that PSP is not a perfect copy of Websnap/intraweb. PSP is definitely not copying Borland because we found that Websnap architecture was too complex. Although, many HTML helpers and visual tools are being worked on, and we are working on more plug-ins for lazarus and MSEGUI/MSEIDE and other text editors to make web development more organized and easier. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus Help System Requirements
Le vendredi 12 mai 2006 à 09:40 +0200, Bogusław Brandys a écrit : Huh! So Berkeley DB is good but using sqlite (public domain) is forbidden ? Anyway it's still external tool. Having to quickly choose a help system for my apps, with index, search system and so on, cross platform (at least for linux and win32), I thought using SQLite with html formating was the solution. My problem is the lack of time to program an editor (integrator!) + viewer. * CHM and HLP windows formats, definitely not. * My first idea was to program an Info viewer with Lazarus. Problem was... my lack of experiences in producing info files. * I'm happy I discovered this thread, I think it can help me to choose a system for my apps, and it's time for a project like Lazarus to choose one. For the moment I'm sticking on my SQLite+html idea. The html format offers some advantages, for example you can use an editor of your choice. The help viewer have to implement some sql stuffs and to use a very simple html viewer, that's it. -- Thierry Andriamirado http://thierry.andriamirado.free.fr _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus Help System Requirements
Le samedi 13 mai 2006 à 09:57 +0200, Michael Van Canneyt a écrit : Same goes for docs... I agree that we should make some modifications for tranlations, but I don't think that .po files are the way to go... But that is my personal opinion. But 'many' (all!) translators use .po editors. If apps produced by fpc/lazarus doesn't support .po and .mo formats, they'll never be translated. -- Thierry Andriamirado http://thierry.andriamirado.free.fr _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus Help System Requirements
Le vendredi 12 mai 2006 à 11:28 +0200, A.J. Venter a écrit : I wouldn't depend on OOo for reading at all - I think depending on it for editing help files is a minor, if anything it is a feature rather than a bug as the writer is a very lovely interface for the task. Just think a moment about what this could do - the IDE can generate the class description as an OOo template - the programmer fires up OOo, opens the template and writes the complete doc, saves the odt and done. Ok, but don't forget that: 1/ the programmer is not the only one who can (have to) write docs. Docs can be writen by even a simple user of the app. 2/ We have to let the docs and help files be writen with 'any' editor. With a simple text editor, or with any html editor for example. Another tool 'll have to compile them to the help format. The hyper-Text format has to be simple, if one like to write docs with a PDA in his spare times, let him do it, and with his prefered editor... He works for our apps, but doesn't care about why we force our doc writers to use OOo or fpc/lazarus formats. -- Thierry Andriamirado http://thierry.andriamirado.free.fr _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus Help System Requirements
On Sat, 13 May 2006 13:50:54 +0300 Thierry Andriamirado [EMAIL PROTECTED] wrote: Le samedi 13 mai 2006 à 09:57 +0200, Michael Van Canneyt a écrit : Same goes for docs... I agree that we should make some modifications for tranlations, but I don't think that .po files are the way to go... But that is my personal opinion. But 'many' (all!) translators use .po editors. If apps produced by fpc/lazarus doesn't support .po and .mo formats, they'll never be translated. - docs will be translated, if the docs are easy to translate. See for example the lazarus-ccr wiki. - .po files are supported and most editors work with them. .mo files are less important, but they can be used too. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus Help System Requirements
On Sat, 13 May 2006, Thierry Andriamirado wrote: Le samedi 13 mai 2006 à 09:57 +0200, Michael Van Canneyt a écrit : Same goes for docs... I agree that we should make some modifications for tranlations, but I don't think that .po files are the way to go... But that is my personal opinion. But 'many' (all!) translators use .po editors. If apps produced by fpc/lazarus doesn't support .po and .mo formats, they'll never be translated. FPC itself has support for .po files (see gettext unit) but the documentation currently not. And forgive me: The translator should under no circumstance know what the underlying format is, just as the end user of a database application should not have to bother with what kind of database his application uses. If we provide good tools for easy translation, things will be translated. Whatever the format. Michael.
Re: [lazarus] Lazarus Help System Requirements
On 5/13/06, Thierry Andriamirado [EMAIL PROTECTED] wrote: But 'many' (all!) translators use .po editors. If apps produced by fpc/lazarus doesn't support .po and .mo formats, they'll never be translated. My current experience is that never a translator asked me: Where are the .po files to be translated? And I already have translators doing work for the Virtual Magnifying Glass for spanish, french, german and polish. If there is a easy interface to translate, they will use it, whatever that is. And I don´t see .po files as a good solution for documentation. I think the ideal would be something similar to a Wiki, or even be able to export parts of the Wiki into whatever documentation format is utilized. -- Felipe Monteiro de Carvalho _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus Help System Requirements
Felipe Monteiro de Carvalho wrote: On 5/13/06, Thierry Andriamirado [EMAIL PROTECTED] wrote: But 'many' (all!) translators use .po editors. If apps produced by fpc/lazarus doesn't support .po and .mo formats, they'll never be translated. My current experience is that never a translator asked me: Where are the .po files to be translated? And I already have translators doing work for the Virtual Magnifying Glass for spanish, french, german and polish. If there is a easy interface to translate, they will use it, whatever that is. And I don´t see .po files as a good solution for documentation. I think the ideal would be something similar to a Wiki, or even be able to export parts of the Wiki into whatever documentation format is utilized. I think this is the best solution. Use some special name space in the wiki and the wiki xml export function. This xml can be converted then. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus Help System Requirements
On Sat, 13 May 2006, Florian Klaempfl wrote: Felipe Monteiro de Carvalho wrote: On 5/13/06, Thierry Andriamirado [EMAIL PROTECTED] wrote: But 'many' (all!) translators use .po editors. If apps produced by fpc/lazarus doesn't support .po and .mo formats, they'll never be translated. My current experience is that never a translator asked me: Where are the .po files to be translated? And I already have translators doing work for the Virtual Magnifying Glass for spanish, french, german and polish. If there is a easy interface to translate, they will use it, whatever that is. And I don´t see .po files as a good solution for documentation. I think the ideal would be something similar to a Wiki, or even be able to export parts of the Wiki into whatever documentation format is utilized. I think this is the best solution. Use some special name space in the wiki and the wiki xml export function. This xml can be converted then. This is maybe OK for some web-enabled project, but not for simple desktop apps. I don't want to install a wiki to be able to edit documentation. It's a feature we can offer for Lazarus or FPC, but not for end-users of Lazarus or FPC. Michael.
Re: [lazarus] Lazarus Help System Requirements
Am Samstag, den 13.05.2006, 16:20 +0200 schrieb Michael Van Canneyt: On Sat, 13 May 2006, Thierry Andriamirado wrote: Le samedi 13 mai 2006 à 09:57 +0200, Michael Van Canneyt a écrit : Same goes for docs... I agree that we should make some modifications for tranlations, but I don't think that .po files are the way to go... But that is my personal opinion. But 'many' (all!) translators use .po editors. If apps produced by fpc/lazarus doesn't support .po and .mo formats, they'll never be translated. FPC itself has support for .po files (see gettext unit) but the documentation currently not. And forgive me: The translator should under no circumstance know what the underlying format is, just as the end user of a database application should not have to bother with what kind of database his application uses. If we provide good tools for easy translation, things will be translated. Whatever the format. I do not know, how professional translators would react if one suggests them using a .po editor for something else than short message strings, but I *do* now abtracting from format issues and having good tools is essential. One thing frequently asked for is having a side-by-side editor with syncing and bookmark option. Regards, Marc _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus Help System Requirements
Michael Van Canneyt wrote: On Sat, 13 May 2006, Florian Klaempfl wrote: Felipe Monteiro de Carvalho wrote: On 5/13/06, Thierry Andriamirado [EMAIL PROTECTED] wrote: But 'many' (all!) translators use .po editors. If apps produced by fpc/lazarus doesn't support .po and .mo formats, they'll never be translated. My current experience is that never a translator asked me: Where are the .po files to be translated? And I already have translators doing work for the Virtual Magnifying Glass for spanish, french, german and polish. If there is a easy interface to translate, they will use it, whatever that is. And I don´t see .po files as a good solution for documentation. I think the ideal would be something similar to a Wiki, or even be able to export parts of the Wiki into whatever documentation format is utilized. I think this is the best solution. Use some special name space in the wiki and the wiki xml export function. This xml can be converted then. This is maybe OK for some web-enabled project, but not for simple desktop apps. I don't want to install a wiki to be able to edit documentation. It's a feature we can offer for Lazarus or FPC, but not for end-users of Lazarus or FPC. Oh, the discussion was about how users can write docs :) Michael. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus Help System Requirements
On Sat, 13 May 2006, Marc Santhoff wrote: Am Samstag, den 13.05.2006, 16:20 +0200 schrieb Michael Van Canneyt: On Sat, 13 May 2006, Thierry Andriamirado wrote: Le samedi 13 mai 2006 à 09:57 +0200, Michael Van Canneyt a écrit : Same goes for docs... I agree that we should make some modifications for tranlations, but I don't think that .po files are the way to go... But that is my personal opinion. But 'many' (all!) translators use .po editors. If apps produced by fpc/lazarus doesn't support .po and .mo formats, they'll never be translated. FPC itself has support for .po files (see gettext unit) but the documentation currently not. And forgive me: The translator should under no circumstance know what the underlying format is, just as the end user of a database application should not have to bother with what kind of database his application uses. If we provide good tools for easy translation, things will be translated. Whatever the format. I do not know, how professional translators would react if one suggests them using a .po editor for something else than short message strings, but I *do* now abtracting from format issues and having good tools is essential. One thing frequently asked for is having a side-by-side editor with syncing and bookmark option. Indeed. This kind of thing I think should be added to the lazarus doc editor... Michael.
Re: [lazarus] Lazarus Help System Requirements
On 13/05/06, Michael Van Canneyt [EMAIL PROTECTED] wrote: I think this is the best solution. Use some special name space in the wiki and the wiki xml export function. This xml can be converted then. This is maybe OK for some web-enabled project, but not for simple desktop apps. I don't want to install a wiki to be able to edit documentation. It's a feature we can offer for Lazarus or FPC, but not for end-users of Lazarus or FPC. You took the words out of my mouth. A wiki is not going to work for a desktop app. Regards, Graeme -- There's no place like 127.0.0.1 _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus Help System Requirements
On 12/05/06, Felipe Monteiro de Carvalho [EMAIL PROTECTED] wrote: Hello, On 5/11/06, Alexandre Leclerc [EMAIL PROTECTED] wrote: Yes, odt files al. are open format. And as of 1 may 2006 it is now an official ISO 26300 approved format (as other format like PDF and HTML who are also ISO approved). Ok, Open Document is good, but it has some problems: 1 - We cannot just get dependent on Open Office. It´s a huge dependency, and won´t work on wince for example. 2 - Whatever the format is, I would like to be able to write my own viewer for it. It may be very hard to write a viewer for odt. For viewing HTML (or HTML extracted from a CHM or CHM-Like file) there is a lot of stuff ready. thanks, -- Felipe Monteiro de Carvalho I think OpenOffice 2.x has some excellent ideas in there help system. I found a 110 page pdf document explaining the internal workings of the help system. [ http://documentation.openoffice.org/online_help/index.html ] There is even a Import/Export filter for OpenOffice to generate the help file format, so you can author your help in OpenOffice (and get spellcheck and formatting for free). I'm still busy reading the document, so ain't sure what exact format they use inside the *.jar files (html, straight xml or odt ...) and what viewer they use for the help. They do use the Berkeley Database for indexes, keywork search and extended tooltips. I would suggest some of you read that PDF as well so we can extract all good ideas. Regards, - Graeme - -- There's no place like 127.0.0.1 _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus Help System Requirements
Graeme Geldenhuys wrote: they use inside the *.jar files (html, straight xml or odt ...) and what viewer they use for the help. They do use the Berkeley Database for indexes, keywork search and extended tooltips. Berkeley DB ? Sorry, but that rings alarm bells over here ... all projects I've heard using it have corruption from time to time :-(. Micha _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus Help System Requirements
Micha Nelissen wrote: Graeme Geldenhuys wrote: they use inside the *.jar files (html, straight xml or odt ...) and what viewer they use for the help. They do use the Berkeley Database for indexes, keywork search and extended tooltips. Berkeley DB ? Sorry, but that rings alarm bells over here ... all projects I've heard using it have corruption from time to time :-(. Micha Huh! So Berkeley DB is good but using sqlite (public domain) is forbidden ? Anyway it's still external tool. Regards Boguslaw _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus Help System Requirements
On 12/05/06, Micha Nelissen [EMAIL PROTECTED] wrote: Graeme Geldenhuys wrote: they use inside the *.jar files (html, straight xml or odt ...) and what viewer they use for the help. They do use the Berkeley Database for indexes, keywork search and extended tooltips. Berkeley DB ? Sorry, but that rings alarm bells over here ... all projects I've heard using it have corruption from time to time :-(. I do not know much of the Berkeley DB, except that GNU/Linux uses it a lot, so it can't be that bad. Also, I just stated what OOo uses. It is up to us to decide what is best for our help system. Regards, - Graeme - -- There's no place like 127.0.0.1 _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus Help System Requirements
On Fri, 12 May 2006, Bogusaw Brandys wrote: Micha Nelissen wrote: Graeme Geldenhuys wrote: they use inside the *.jar files (html, straight xml or odt ...) and what viewer they use for the help. They do use the Berkeley Database for indexes, keywork search and extended tooltips. Berkeley DB ? Sorry, but that rings alarm bells over here ... all projects I've heard using it have corruption from time to time :-(. Micha Huh! So Berkeley DB is good but using sqlite (public domain) is forbidden ? Anyway it's still external tool. No-one is suggesting to use Berkeley DB yet. Graeme is studying the format openoffice uses, that's all. It may wel be that Graeme decides it's too difficult to use... In the worst case, Berkeley DB is a documented file format, So you can write pascal code to read/write it, and other people can use the native API. The point is that we'd like a 100% OOP solution. Michael. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus Help System Requirements
On Thu, May 11, 2006 at 03:33:02PM +0200, Michael Van Canneyt wrote: I think the po2xml is just used to translate the program strings which appear in the docs (used to refer to button captions etc), not for the actual documentation text. Wrong. It is used for documentation writing too as you can see here, for the LinuxFromScratch manual: http://www.mail-archive.com/lfs-dev@linuxfromscratch.org/msg06863.html --- Hello, ok, this is my third try to get a mail sent to this list...: i got good news for all LFS translators. Today i commited the patch below to the KDE repository. This means for LFS translators: With upcoming versions of KDE (= 3.5.3) you can use the KDE i18n tools po2xml and xml2pot (from package kdesdk) again for translating the book. This was nearly impossible in the past because those tools extracted complete chapters and appendixes into a single, huge msgid. I hope this brings some translations back to the LFS community :) Bye, Thomas --- Changing 1 letter in the documentation text would completely kill your po2xml output, since it is based on textual search. That is easily managed by the gettext update utility like msgmerge. bye -- Marco Ciampa ++ | Linux User #78271 | | FSFE fellow #364 | ++ _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus Help System Requirements
On Fri, 12 May 2006, Marco Ciampa wrote: On Thu, May 11, 2006 at 03:33:02PM +0200, Michael Van Canneyt wrote: I think the po2xml is just used to translate the program strings which appear in the docs (used to refer to button captions etc), not for the actual documentation text. Wrong. It is used for documentation writing too as you can see here, for the LinuxFromScratch manual: http://www.mail-archive.com/lfs-dev@linuxfromscratch.org/msg06863.html In that case, I understand even less why they use it. In my opinion, the .po format is totally unsuitable for this kind of thing. Michael. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus Help System Requirements
Indeed, I think the idea would be a by-product just as a pdf in that case. A viewer would not be simple to do, but the format is simple. The file is actually a zip file with xml stuff files in it. Indeed, OOo's file are quite easy to hack. It's zipped up xml - the reason it was chosen by the ODF as their standard is exactly that, not only is it fully publicly document - it is a non-binary format, and it will always be possible to write another unzip+xml-parsing routine. I wouldn't depend on OOo for reading at all - I think depending on it for editing help files is a minor, if anything it is a feature rather than a bug as the writer is a very lovely interface for the task. Just think a moment about what this could do - the IDE can generate the class description as an OOo template - the programmer fires up OOo, opens the template and writes the complete doc, saves the odt and done. A bigger factor IMHO is that OOo has way too many features, if we don't use writer as our viewer then we need to code a viewer to display writer files and it will almost by default lose formatting because nobody here feels like cloning the entire OOo codebase (sorry - I don't contribute to java projects as a matter of principle :p ) A.J. -- 80% Of a hardware engineer's job is application of the uncertainty principle. 80% of a software engineer's job is pretending this isn't so. A.J. Venter Chief Software Architect OpenLab International http://www.getopenlab.com | +27 82 726 5103 (South Africa) http://www.silentcoder.co.za| +55 118 162 2079 (Brazil) _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus Help System Requirements
On 12/05/06, Micha Nelissen [EMAIL PROTECTED] wrote: Graeme Geldenhuys wrote: I think this is quite a elegant solution for application help and can even be applied to the LCL and FCL documentation which is currently stored in XML. Sure there are a lot of elegant solutions, but who is going to write it ? Let's be realistic here. For CHM we already have a decoder and viewer, I started with a prototype already... well more like putting some ideas to code. A good help framework in the LCL is also important. Felipe mentioned some ideas, and Mattias has implemented something already for Lazarus, so I need to look at that as well, so see how flexible it is. Can you used that for applications written with Lazarus, or was that for Lazarus alone. for the .jar way we need multiple decoders and translators AFAICS (jar, xhp, css, xslt, more?) still to be implemented. Again, if anyone wants * xhp is just XML and as for an example, LCL and FPC help already comes in xml format. * css can be added at a later stage, or a very basic style sheet could be added for a start. All of 5 minutes work. * xslt might take a bit longer, but looking at what fpdoc does to convert the XML to HTML (as it currently does) should give a good starting point. Also, I will be taking a look at what OOo did, and maybe just massage their Translation Style Sheet to fit our needs. * As for the HTML viewer component? Any suggestions? Do any support basic CSS? to write all this, nothing is stopping you, but CHM seems like a faster more productive route ATM, if the coder doesn't care anyway. Brings me back to the same old question everybody seems to avoid answering. May we use the CHM format - is it proprietary/patented by Microsoft? Regards, - Graeme - -- There's no place like 127.0.0.1 _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus Help System Requirements
Graeme Geldenhuys wrote: to write all this, nothing is stopping you, but CHM seems like a faster more productive route ATM, if the coder doesn't care anyway. Brings me back to the same old question everybody seems to avoid answering. May we use the CHM format - is it proprietary/patented by Microsoft? Depends on where you are obviously :-). AFAIK, it can't be here in Europe. Besides, a file format is just a file format, there is no invention in a format, it's just a choice. Micha _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus Help System Requirements
On Fri, May 12, 2006 at 11:23:23AM +0200, Michael Van Canneyt wrote: On Fri, 12 May 2006, Marco Ciampa wrote: On Thu, May 11, 2006 at 03:33:02PM +0200, Michael Van Canneyt wrote: I think the po2xml is just used to translate the program strings which appear in the docs (used to refer to button captions etc), not for the actual documentation text. Wrong. It is used for documentation writing too as you can see here, for the LinuxFromScratch manual: http://www.mail-archive.com/lfs-dev@linuxfromscratch.org/msg06863.html In that case, I understand even less why they use it. In my opinion, the .po format is totally unsuitable for this kind of thing. Sorry, I do not understand and I really want to see your point. Could you please tell me why you consider .po files not suitable for the job? I do not know of some other tool able to manage the update problem of a multilingual translation as the gettext tool. May be I'm wrong but I think that such a tool simply does not exist! -- Marco Ciampa ++ | Linux User #78271 | | FSFE fellow #364 | ++ _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus Help System Requirements
On Fri, 12 May 2006, Marco Ciampa wrote: On Fri, May 12, 2006 at 11:23:23AM +0200, Michael Van Canneyt wrote: On Fri, 12 May 2006, Marco Ciampa wrote: On Thu, May 11, 2006 at 03:33:02PM +0200, Michael Van Canneyt wrote: I think the po2xml is just used to translate the program strings which appear in the docs (used to refer to button captions etc), not for the actual documentation text. Wrong. It is used for documentation writing too as you can see here, for the LinuxFromScratch manual: http://www.mail-archive.com/lfs-dev@linuxfromscratch.org/msg06863.html In that case, I understand even less why they use it. In my opinion, the .po format is totally unsuitable for this kind of thing. Sorry, I do not understand and I really want to see your point. Could you please tell me why you consider .po files not suitable for the job? I do not know of some other tool able to manage the update problem of a multilingual translation as the gettext tool. May be I'm wrong but I think that such a tool simply does not exist! .po files are designed/meant for captions, short one-line descriptions to be displayed in a program, produced by gettext from sources. Gettext uses a very inefficient algorithm for translation: it searches in the .po (or .mo) file for the original text, and then returns the translated text. You can't get more inefficient than that. Conclusion: The .po format is not designed/meant for large pieces of continuous text. I agree with you that a good tool for translations does not exist. The question is whether such a tool should exist. A simple diff (with nice gui) in any text editor can help you in keeping your translation up to date just as much... There is no need to use a .po file format for this. How would you translate a document written in Latex, or Ms-Word or OpenOffice Writer? There are no good tools for this, and I don't believe it's possible to write such a tool other than some visual aid for detecting differences... For example: The fpdoc format is much more suitable for translation, because all pieces of text are identified with unique names. It would be much more easy to write a translator program for that. Michael. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus Help System Requirements
On Fri, May 12, 2006 at 12:01:39PM +0200, Micha Nelissen wrote: Graeme Geldenhuys wrote: to write all this, nothing is stopping you, but CHM seems like a faster more productive route ATM, if the coder doesn't care anyway. Brings me back to the same old question everybody seems to avoid answering. May we use the CHM format - is it proprietary/patented by Microsoft? Depends on where you are obviously :-). AFAIK, it can't be here in Europe. Now. Perhaps not forever. Besides, a file format is just a file format, there is no invention in a format, it's just a choice. Yes but M$ patented his xml file formats...ok again not in Europe but ...better prevent than cure! -- Marco Ciampa ++ | Linux User #78271 | | FSFE fellow #364 | ++ _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus Help System Requirements
2006/5/12, A.J. Venter [EMAIL PROTECTED]: Indeed, I think the idea would be a by-product just as a pdf in that case. A viewer would not be simple to do, but the format is simple. The file is actually a zip file with xml stuff files in it. Indeed, OOo's file are quite easy to hack. It's zipped up xml - the reason it was chosen by the ODF as their standard is exactly that, not only is it fully publicly document - it is a non-binary format, and it will always be possible to write another unzip+xml-parsing routine. I wouldn't depend on OOo for reading at all - I think depending on it for editing help files is a minor, if anything it is a feature rather than a bug as the writer is a very lovely interface for the task. Just think a moment about what this could do - the IDE can generate the class description as an OOo template - the programmer fires up OOo, opens the template and writes the complete doc, saves the odt and done. Indeed; in another project we are planning to work with OOo document to produce reports. It is just too simple. I know there is a 'python' project for a odt file viewer. (http://visioo-writer.tuxfamily.org/EN/index.html) Maybe there are simple tricks to convert a document with xslt magic. I dont know. We could indeed write the doc in a odt compatible editor (like Writer) then we could use xslt stuff to export to other format if we want (like HTML). All these features are included in OOo 2. A bigger factor IMHO is that OOo has way too many features, if we don't use writer as our viewer then we need to code a viewer to display writer files and it will almost by default lose formatting because nobody here feels like cloning the entire OOo codebase (sorry - I don't contribute to java projects as a matter of principle :p ) A.J. -- Alexandre Leclerc _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus Help System Requirements
Micha Nelissen wrote: Graeme Geldenhuys wrote: they use inside the *.jar files (html, straight xml or odt ...) and what viewer they use for the help. They do use the Berkeley Database for indexes, keywork search and extended tooltips. Berkeley DB ? Sorry, but that rings alarm bells over here ... all projects I've heard using it have corruption from time to time :-(. Perhaps, but those projects by and large aren't READ ONLY, like a help file would be. Jeff. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus Help System Requirements
On Fri, May 12, 2006 at 12:23:57PM +0200, Michael Van Canneyt wrote: On Fri, 12 May 2006, Marco Ciampa wrote: On Fri, May 12, 2006 at 11:23:23AM +0200, Michael Van Canneyt wrote: On Fri, 12 May 2006, Marco Ciampa wrote: On Thu, May 11, 2006 at 03:33:02PM +0200, Michael Van Canneyt wrote: I think the po2xml is just used to translate the program strings which appear in the docs (used to refer to button captions etc), not for the actual documentation text. Wrong. It is used for documentation writing too as you can see here, for the LinuxFromScratch manual: http://www.mail-archive.com/lfs-dev@linuxfromscratch.org/msg06863.html In that case, I understand even less why they use it. In my opinion, the .po format is totally unsuitable for this kind of thing. Sorry, I do not understand and I really want to see your point. Could you please tell me why you consider .po files not suitable for the job? I do not know of some other tool able to manage the update problem of a multilingual translation as the gettext tool. May be I'm wrong but I think that such a tool simply does not exist! po files are designed/meant for captions, short one-line descriptions to be displayed in a program, produced by gettext from sources. Right. It is the kind of use I intended for gettext. We both agree about po files scope but I think you missed the point. Gettext uses a very inefficient algorithm for translation: it searches in the .po (or .mo) file for the original text, and then returns the translated text. You can't get more inefficient than that. No. It is really quick and it doesn't search the .po file but its compiled form, the .mo and anyway, I never intended to use it as a final product, so I do not really care if it's fast or not. Conclusion: The .po format is not designed/meant for large pieces of continuous text. Yes, I agree again and the use I have in mind ([EMAIL PROTECTED] in this ml grasped the concept quickly, see: Maybe a source format file combination of *.po files and a XML file: xml title path= title.po / contents path= contents.po / /xml yes, sort of... ) is to use the interesting propriety of the .po files with the gettext utility suite only for source code, not for the final result. Infact I never inteded it to. A paragraph is always a short text, in general a fiew lines, so it's ideal for gettext .po strings. I agree with you that a good tool for translations does not exist. The question is whether such a tool should exist. The right tool do not exist but gettext is the most andvanced tool in this direction thought. A simple diff (with nice gui) in any text editor can help you in keeping your translation up to date just as much... No, really not, it's a nightmare, believe me! My main occupation (as a volunteer) is to translate free software programs and manuals (like GIMP) and I can assure you: without gettext revision control it's really difficult to keep track of the modifications inserted at random (in time and location) by contributors even using a language (the english) as a reference and with cvs (and cvs web interface). There is no need to use a .po file format for this. For the final product, no. I really intended to obtain html _AND_ any other suitable for browse/search format like chm or pdf or info or whatever you like. How would you translate a document written in Latex, or Ms-Word or OpenOffice Writer? Cut it in paragraps and paste it in many .po strings and the work is easier than that with any other source format. There are no good tools for this, and I don't believe it's possible to write such a tool other than some visual aid for detecting differences... Have you used tools like intltool-update from the gnome project lately? It works like a sharm! Is it possible to obtain the same result with any other tool? Do you know of any similar tools? Without gettext utilities like msgmerge? For example: The fpdoc format is much more suitable for translation, because all pieces of text are identified with unique names. The text is really a unique identifier, or not? It would be much more easy to write a translator program for that. Yes its simple in a one-shot effort. Pray to be not the manual mantainer...and why should you reinvent the wheel when there are so many instruments like poedit, kbabel, emacs po-mode, even rosetta web interface from the ubuntu project!?! Remember: the problem is _not_ the easyness to translate the manual _but_ the maintainability of it! -- Marco Ciampa ++ | Linux User #78271 | | FSFE fellow #364 | ++ _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus Help System Requirements
1 - We cannot just get dependent on Open Office. It´s a huge dependency, and won´t work on wince for example. Open Office format it's too complicated for a help file. a lot of stuff ready. - Marco Aurelio Ramirez Carrillo [EMAIL PROTECTED] [.mx] _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus Help System Requirements
more productive route ATM, if the coder doesn't care anyway. Micha It seems that the one that implements it's proposal wins... - Marco Aurelio Ramirez Carrillo [EMAIL PROTECTED] [.mx] _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus Help System Requirements
Micha Nelissen wrote: Graeme Geldenhuys wrote: they use inside the *.jar files (html, straight xml or odt ...) and what viewer they use for the help. They do use the Berkeley Database for indexes, keywork search and extended tooltips. Berkeley DB ? Sorry, but that rings alarm bells over here ... all projects I've heard using it have corruption from time to time :-(. Perhaps, but those projects by and large aren't READ ONLY, like a help file would be. So what about SVN? _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus Help System Requirements
On 12/05/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Open Office format it's too complicated for a help file. I can't see why? If you are referring to the tags while authoring help, when last have you seen all the tags for Windows Help. Also the Help Authoring Plugin of OOo makes authoring help much easier. Plus you get the benefit of what OOo Writer has to offer. Regarding generating the HTML from the XML. That would be a once off design of XSLT rules. Not difficult, just time consuming. I am sure we can peak at the OOo XSLT to help us along. The only thing to I can think of that might be a pain, is finding a decent HTML Viewer component for Lazarus and something that supports basic CSS would be a big bonus. This isn't really a issue against the OOo format as the consensus is that HTML as one of the final output formats is the preferred choice. In that case, no matter what help format we use, we still need to be able to viewer the HTML in some viewer component. Regards, Graeme. -- There's no place like 127.0.0.1 _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus Help System Requirements
Conclusion: The .po format is not designed/meant for large pieces of continuous text. The cool thing about *.po files are One text file for a set of messages, each message with a string ID. What about a BINARY replacement of text files such as: - Binary Help Index table (*.hidx): - Identifier|Offset - 1.|0 2.|5 - -- Binary Help Message table (*.hmsg): -- RecordNumber|Message -- 0...|Hello 5...|World -- -- Pascal file that uses resources (*.pas): -- const resHello = 1; // for Binary Index file resWorld = 2; // for Binary Index file ... function _(const Identifier: Integer): string; // function that loads a resourcestring, guven its identifier var S: string; ... S := _(resHello) + ' ' + _(resWorld); -- And use it to make a help system. My 2 cents... - Marco Aurelio Ramirez Carrillo [EMAIL PROTECTED] [.mx] _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus Help System Requirements
On Fri, May 12, 2006 at 05:07:28PM +0200, Michael Van Canneyt wrote: Not for the initial format either: You have to insert the tag: element name=TMyClass.MyMethod descr lang=en rdate=200613050135 pblah-blah/p pblah2-blah2/p /descr descr lang=de rdate=20061305 pblah-blah/p pblah2-blah2/p /descr 1) you have to make the tool that parses the source in search of a ReleaseDATE mismatch to signal the change and 'jumps' to it 2) you have to create the macros to update the rdate tag 3) you have to check for the validation of the code and so on... to be short, you find yourself reinventing the wheel of the gettext platform... Will do just fine. Any changes to portions of the first descr node can be made visible in a decent fpdoc editing program, and the relevant portion of the second node can be displayed in parallel... reinventing poedit... No _need_ for .po files. You could use them, but I doubt they are needed. Ofter the advandages of using a standard tool are not apparent at first but when you have already done much of the work... :-( since fpdoc is a structured format, showing differences is just a matter of having the correct tools in your editor. yes but why to recode something that is already there? New Murphy law: for every new RAD there will be a new (and buggy) help format tool :-/ -- Marco Ciampa ++ | Linux User #78271 | | FSFE fellow #364 | ++ _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus Help System Requirements
On 10/05/06, Vincent Snijders [EMAIL PROTECTED] wrote: Not a new format, but a portable format: CHM, with a viewer built with fpc/lazarus. Just to clear things up... When you say CHM, do you mean something like what CHM does, or the exact CHM format? Isn't CHM a proprietary / patented format from Microsoft and we would get into trouble using the exact CHM format? Regards, - Graeme - -- There's no place like 127.0.0.1 _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus Help System Requirements
On Thu, 11 May 2006, Graeme Geldenhuys wrote: On 10/05/06, Vincent Snijders [EMAIL PROTECTED] wrote: Not a new format, but a portable format: CHM, with a viewer built with fpc/lazarus. Just to clear things up... When you say CHM, do you mean something like what CHM does, or the exact CHM format? Isn't CHM a proprietary / patented format from Microsoft and we would get into trouble using the exact CHM format? Whatever the answer, I'd rather go for the OpenOffice format: it's an open standard. Michael. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus Help System Requirements
Michael Van Canneyt wrote: Whatever the answer, I'd rather go for the OpenOffice format: it's an open standard. Open Standard or 'de facto' Standard ? Micha _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus Help System Requirements
On 5/10/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Overview Windowze has 2 help system versions (*.hlp files and *.chm files). Un*x based systems have man (doesn't have links, discarted, sorry). I heard that *Linux (GNU/Linux, and others) doesn't have one. The man pages are not the only help format in Unix. In Linux/Unix there are also the info pages , which do support links. Some info pages also have an index ( i'm not sure when this index is generated) . The program is called 'info' . Info can be used to acces the regular man pages, too. (plus you can go to the related items in SEE ALSO by simply going on the item and pressing enter). By googling for more info about info, i've found that Info is in fact the official documentation format of the GNU project : http://www.gnu.org/software/texinfo/ Info might be really interesting : it is possible to generate several help formats from a single source : html, pdf, info, dvi, xml . Adrian Maier _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus Help System Requirements
On Wed, May 10, 2006 at 10:41:22AM -0500, [EMAIL PROTECTED] wrote: So, the file format must be an Open Standard. Definitely! Comments Please feel free to add any missing requirement. Source file must be thought to be easy for nationalization (i. e. use .po files in the source). So IMHO: source file: several .po chapters merged into an xml/docbook file output file: HTML primary then PDF, txt, CHM, hlp, etc. -- Marco Ciampa ++ | Linux User #78271 | | FSFE fellow #364 | ++ _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus Help System Requirements
On Thu, 11 May 2006, Adrian Maier wrote: On 5/10/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Overview Windowze has 2 help system versions (*.hlp files and *.chm files). Un*x based systems have man (doesn't have links, discarted, sorry). I heard that *Linux (GNU/Linux, and others) doesn't have one. The man pages are not the only help format in Unix. In Linux/Unix there are also the info pages , which do support links. Some info pages also have an index ( i'm not sure when this index is generated) . The program is called 'info' . Info can be used to acces the regular man pages, too. (plus you can go to the related items in SEE ALSO by simply going on the item and pressing enter). By googling for more info about info, i've found that Info is in fact the official documentation format of the GNU project : http://www.gnu.org/software/texinfo/ Info might be really interesting : it is possible to generate several help formats from a single source : html, pdf, info, dvi, xml . This info is generated from texinfo, a variant of TeX/LaTeX. Michael. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus Help System Requirements
On Thu, 11 May 2006, Marco Ciampa wrote: On Wed, May 10, 2006 at 10:41:22AM -0500, [EMAIL PROTECTED] wrote: So, the file format must be an Open Standard. Definitely! Comments Please feel free to add any missing requirement. Source file must be thought to be easy for nationalization (i. e. use .po files in the source). .po is not suitable for translation of documentation. translations should be done completely separate. Michael. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus Help System Requirements
Michael Van Canneyt wrote: On Thu, 11 May 2006, Marco Ciampa wrote: On Wed, May 10, 2006 at 10:41:22AM -0500, [EMAIL PROTECTED] wrote: So, the file format must be an Open Standard. Definitely! Comments Please feel free to add any missing requirement. Source file must be thought to be easy for nationalization (i. e. use .po files in the source). .po is not suitable for translation of documentation. translations should be done completely separate. Michael. Good point. It seems that we are closer to consent. XML is fine , we only need : 1. a tool to export to various formats (HTML,PDF,CHM - all with index if possible) 2. a tool to index XML (full text search-help index) - for IDE usage (context help and others) Regards Boguslaw _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus Help System Requirements
On Thu, May 11, 2006 at 11:08:15AM +0200, Michael Van Canneyt wrote: On Thu, 11 May 2006, Marco Ciampa wrote: On Wed, May 10, 2006 at 10:41:22AM -0500, [EMAIL PROTECTED] wrote: So, the file format must be an Open Standard. Definitely! Comments Please feel free to add any missing requirement. Source file must be thought to be easy for nationalization (i. e. use .po files in the source). po is not suitable for translation of documentation. translations should be done completely separate. Seems that both kde gnome folks do not know that what they are doing is not possible :-) http://l10n.kde.org/docs/translation-howto//doc-translation.html#doc-conversion so po2xml tool what is for about? -- Marco Ciampa ++ | Linux User #78271 | | FSFE fellow #364 | ++ _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus Help System Requirements
2006/5/11, Michael Van Canneyt [EMAIL PROTECTED]: On Thu, 11 May 2006, Micha Nelissen wrote: Michael Van Canneyt wrote: Whatever the answer, I'd rather go for the OpenOffice format: it's an open standard. Open Standard or 'de facto' Standard ? Open, I would say ? Yes, odt files al. are open format. And as of 1 may 2006 it is now an official ISO 26300 approved format (as other format like PDF and HTML who are also ISO approved). OASIS / ISO http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=office http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=43485scopelist=PROGRAMME More info: http://en.wikipedia.org/wiki/OpenDocument (In all url, change 'en' for 'fr' to get the french version. Might work for other languages as well.) I'm very much for the open document format, but I don't know if it can serve a help file very easely. But I suggested that format in another thread :) Regards. -- Alexandre Leclerc _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus Help System Requirements
On Thu, 11 May 2006, Marco Ciampa wrote: On Thu, May 11, 2006 at 11:08:15AM +0200, Michael Van Canneyt wrote: On Thu, 11 May 2006, Marco Ciampa wrote: On Wed, May 10, 2006 at 10:41:22AM -0500, [EMAIL PROTECTED] wrote: So, the file format must be an Open Standard. Definitely! Comments Please feel free to add any missing requirement. Source file must be thought to be easy for nationalization (i. e. use .po files in the source). po is not suitable for translation of documentation. translations should be done completely separate. Seems that both kde gnome folks do not know that what they are doing is not possible :-) http://l10n.kde.org/docs/translation-howto//doc-translation.html#doc-conversion so po2xml tool what is for about? I didn't say 'possible', I said 'suitable'. Looking at the website: I think the po2xml is just used to translate the program strings which appear in the docs (used to refer to button captions etc), not for the actual documentation text. Changing 1 letter in the documentation text would completely kill your po2xml output, since it is based on textual search. Michael. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus Help System Requirements
Source file must be thought to be easy for nationalization (i. e. use .po files in the source). Maybe a source format file combination of *.po files and a XML file: xml title path= title.po / contents path= contents.po / /xml So IMHO: source file: several .po chapters merged into an xml/docbook file output file: HTML primary then PDF, txt, CHM, hlp, etc. Sounds fine. -- Marco Ciampa - Marco Aurelio Ramirez Carrillo [EMAIL PROTECTED] [.mx] _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus Help System Requirements
XML is fine , we only need : 1. a tool to export to various formats (HTML,PDF,CHM - all with index if possible) 2. a tool to index XML (full text search-help index) - for IDE usage (context help and others) It's seems we're getting to something similar to a html source file format and an open source chm destination file format that supports indexes... - Marco Aurelio Ramirez Carrillo [EMAIL PROTECTED] [.mx] _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus Help System Requirements
On 5/11/06, Vincent Snijders [EMAIL PROTECTED] wrote: I mean exact CHM format, for which a freely available help compiler (HTML workshop) exists on windows. The compiler is non-portable. There are no open tools to create CHM files and the free tools I saw that can read it state on their web pages that using them is illegal because it´s considered a circunvention tool by the DRM or something like that. CHM-like is nice, but there is no help compiler for that, so it is useless. There already other CHM-like formats with already working compilers and viewers. One example is the wxWidgets format. Apparently there are others, like for Gimp, Qt, etc. We could just choose one of the open formats and go with it. -- Felipe Monteiro de Carvalho _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus Help System Requirements
Hello, On 5/11/06, Alexandre Leclerc [EMAIL PROTECTED] wrote: Yes, odt files al. are open format. And as of 1 may 2006 it is now an official ISO 26300 approved format (as other format like PDF and HTML who are also ISO approved). Ok, Open Document is good, but it has some problems: 1 - We cannot just get dependent on Open Office. It´s a huge dependency, and won´t work on wince for example. 2 - Whatever the format is, I would like to be able to write my own viewer for it. It may be very hard to write a viewer for odt. For viewing HTML (or HTML extracted from a CHM or CHM-Like file) there is a lot of stuff ready. thanks, -- Felipe Monteiro de Carvalho _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus Help System Requirements
2006/5/11, Felipe Monteiro de Carvalho [EMAIL PROTECTED]: Hello, On 5/11/06, Alexandre Leclerc [EMAIL PROTECTED] wrote: Yes, odt files al. are open format. And as of 1 may 2006 it is now an official ISO 26300 approved format (as other format like PDF and HTML who are also ISO approved). Ok, Open Document is good, but it has some problems: 1 - We cannot just get dependent on Open Office. It´s a huge dependency, and won´t work on wince for example. 2 - Whatever the format is, I would like to be able to write my own viewer for it. It may be very hard to write a viewer for odt. For viewing HTML (or HTML extracted from a CHM or CHM-Like file) there is a lot of stuff ready. Indeed, I think the idea would be a by-product just as a pdf in that case. A viewer would not be simple to do, but the format is simple. The file is actually a zip file with xml stuff files in it. -- Alexandre Leclerc _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus Help System Requirements
On Thu, May 11, 2006 at 03:33:02PM +0200, Michael Van Canneyt wrote: I didn't say 'possible', I said 'suitable'. Looking at the website: I think the po2xml is just used to translate the program strings which appear in the docs (used to refer to button captions etc), not for the actual documentation text. Changing 1 letter in the documentation text would completely kill your po2xml output, since it is based on textual search. Ok, I see. But for my experience in translation, having a revision control like that offered by the gettext/po file, for multilingual translation is really paramount. And .po strings are not limited in size so they can easily fit in the paragraph size for documentation source. During the translation of some big GPL programs I found that all pages of the manual are divided in paragraph size chunks, suiteable for .po strings substitution/upgrade. The update/upgrade process and the inherently interesting features needed are the most important factor here. The use of .po files is IMHO a really A VERY COOL thing for a multilanguage manual, especially if you plan to translate it and in the meantime it grows up... Then the gettext utility programs comes really useful and I cannot see any other intrument able to manage such things as good as the gettext suite (and the so many .po files editors are really something). For example I use emacs in po-mode but I know of many vi (gosh) users too. -- Marco Ciampa ++ | Linux User #78271 | | FSFE fellow #364 | ++ _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus Help System Requirements
On Thu, May 11, 2006 at 08:15:32AM -0500, [EMAIL PROTECTED] wrote: Source file must be thought to be easy for nationalization (i. e. use .po files in the source). Maybe a source format file combination of *.po files and a XML file: xml title path= title.po / contents path= contents.po / /xml yes, sort of... So IMHO: source file: several .po chapters merged into an xml/docbook file output file: HTML primary then PDF, txt, CHM, hlp, etc. Sounds fine. It would be great for mantainers of a multilingual manual suitable of changing every now and then... -- Marco Ciampa ++ | Linux User #78271 | | FSFE fellow #364 | ++ _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
[lazarus] Lazarus Help System Requirements
Overview Hi, I started a new thread in order to summarize the comments about a Help System or Help File Format for Lazarus, or even FPC. Sorry, but I think the Re: [lazarus] New help doc format? thread was getting to big, and focused in how to implement a help system, and forgot the what does a help system has to do. I already have the same problems with Delphi or Kylix, AS WELL AS MANY OF YOU and have to deal with the same topics: Lazarus Help System Requirements 1. Cross Platform - Windowze has 2 help system versions (*.hlp files and *.chm files). Un*x based systems have man (doesn't have links, discarted, sorry). I heard that *Linux (GNU/Linux, and others) doesn't have one. It seems to me that many of you use Lazarus as a Delphi Just for Linux, instead of Alternative to Delphi available in several platforms. But the point is that there are several ports (Mac, mobile, *BSD), amd also, several of us HAVE TO WORK WITH Windowze and Linux, at the same time, and that ALSO APPLIES to the help system. A true Cross-Platform Help System must be available in SEVERAL PLATFORMS AT THE SAME TIME. A fast and dirty solution could be to use a source file format, (HTML, XML, perhaps ?) and compile it into an existing destination native file format (*.hlp or database file) that it's displayed in existing, maybe propertary, help viewers. The other (slow and clean) solution, create a whole new file format (Small Database/XML based ?) and built new help viewers. 2. Offline -- Many of us doesn't have or can't have Internet on the work or school. Wiki pages and HMTL files on the web are great, but we still need to have a help system that can be used on our home PC. Yes, I know we can have local HTML files. In case we use HTML or XML files for the help system, we need to take this on consideration. 3. Localization --- Some of us doesn't use English as our every day work language or even have to work with several languages at the same time... So the help system have to be localizated. Quick and fast solution, use a source help file and traslated to other languages. 4. Open Standard and Open Source I found, once, a help system that worked on Linux, (http://www.helpblocks.com/), but was proprietary, and doesn't solve the other requirements problems. Third-Party modules (librarys, units) may be necessary, even if they're difficult to use, but they must be open source also. So, the file format must be an Open Standard. Comments Please feel free to add any missing requirement. Just my 2 cents. - Marco Aurelio Ramirez Carrillo [EMAIL PROTECTED] [.mx] _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus Help System Requirements
[EMAIL PROTECTED] wrote: Overview Hi, I started a new thread in order to summarize the comments about a Help System or Help File Format for Lazarus, or even FPC. Sorry, but I think the Re: [lazarus] New help doc format? thread was getting to big, and focused in how to implement a help system, and forgot the what does a help system has to do. I already have the same problems with Delphi or Kylix, AS WELL AS MANY OF YOU and have to deal with the same topics: Lazarus Help System Requirements 1. Cross Platform - Windowze has 2 help system versions (*.hlp files and *.chm files). Un*x based systems have man (doesn't have links, discarted, sorry). I heard that *Linux (GNU/Linux, and others) doesn't have one. It seems to me that many of you use Lazarus as a Delphi Just for Linux, instead of Alternative to Delphi available in several platforms. But the point is that there are several ports (Mac, mobile, *BSD), amd also, several of us HAVE TO WORK WITH Windowze and Linux, at the same time, and that ALSO APPLIES to the help system. A true Cross-Platform Help System must be available in SEVERAL PLATFORMS AT THE SAME TIME. A fast and dirty solution could be to use a source file format, (HTML, XML, perhaps ?) and compile it into an existing destination native file format (*.hlp or database file) that it's displayed in existing, maybe propertary, help viewers. The other (slow and clean) solution, create a whole new file format (Small Database/XML based ?) and built new help viewers. Not a new format, but a portable format: CHM, with a viewer built with fpc/lazarus. 2. Offline -- Many of us doesn't have or can't have Internet on the work or school. Wiki pages and HMTL files on the web are great, but we still need to have a help system that can be used on our home PC. Yes, I know we can have local HTML files. In case we use HTML or XML files for the help system, we need to take this on consideration. CHM fits the picture. 3. Localization --- Some of us doesn't use English as our every day work language or even have to work with several languages at the same time... So the help system have to be localizated. Quick and fast solution, use a source help file and traslated to other languages. 4. Open Standard and Open Source I found, once, a help system that worked on Linux, (http://www.helpblocks.com/), but was proprietary, and doesn't solve the other requirements problems. Third-Party modules (librarys, units) may be necessary, even if they're difficult to use, but they must be open source also. So, the file format must be an Open Standard. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
