scrollkeeper-devel — Developer discussion list for ScrollKeeper

Re: [Scrollkeeper-devel] Scrollkeeper translations and translation projects

[Christian R. <me...@gn...>]

s=F6n 2003-02-02 klockan 22.42 skrev Dan Mueth:
> It sounds like we should move translations to the Translation Project. =20

Ok.


> (Does anybody else want to weigh in with an opinion, one way or the=20
> other?)
>=20
> I'd like to wait a few more days since I recently sent out the POT file t=
o
> previous translators for updates.  Then I can make a new release with the
> updated po files and move over to the Translation Project.

Sounds excellent.


Christian

Re: [Scrollkeeper-devel] Scrollkeeper translations and translation projects

[Dan M. <mu...@al...>]

Hi Christian,

It sounds like we should move translations to the Translation Project.  
(Does anybody else want to weigh in with an opinion, one way or the 
other?)

I'd like to wait a few more days since I recently sent out the POT file to
previous translators for updates.  Then I can make a new release with the
updated po files and move over to the Translation Project.

Thanks,

Dan




On 2 Feb 2003, Christian Rose wrote:

> Hi!
> 
> As you probably all know scrollkeeper has had translations available in
> GNOME cvs, so that GNOME translators inside the GNOME Translation
> Project (GTP) could more easily translate scrollkeeper, as GNOME uses
> scrollkeeper in it's core help system.
> 
> However, as there have been clashes in the past with the Translation
> Project (TP; http://www.iro.umontreal.ca/contrib/po/HTML/) where there
> unfortunately were translators from both projects working on the same
> translations independantly of each other, and as a result much wasted
> work and confusion, we've had to finally decide on and agree on what
> kind of software should be taken care of what translation project.
> 
> As a result, we've agreed on:
> 
> 1) Translations of software present in GNOME cvs should be handled by
> the GNOME Translation Project (GTP). Important GNOME software or
> software that wants in other ways to be considered a part of GNOME
> should use (or move to) the GNOME cvs anyway; there are many other
> development benefits of using the same cvs for software under the same
> project umbrella.
> 
> 2) Translations of all other (independant) software should be handled by
> the Translation Project (TP). The TP has a much better infrastructure
> for handling of translations of software from many sources anyway.
> 
> This among other things means that we are phasing out the "extra-po"
> directory in GNOME cvs where scrollkeeper and other "out-of-gnome-cvs"
> translations has been located until now.
> 
> So, we need to know how to proceed. The decision is up to you -- are you
> moving to work more closely with GNOME and want to use the GNOME cvs, or
> are you more comfortable with scrollkeeper being independantly developed
> as it is now? From previous communication I understand that scrollkeper
> maintainers prefer to have it as an independant project, so I guess the
> answer above is the second one. In that case we should help you set up
> scrollkeeper in the TP and import existing translations there
> (instructions for adding modules to the TP are at
> http://www.iro.umontreal.ca/contrib/po/HTML/maintainers.html).
> 
> Opinions/comments/decisions?
> 
> 
> Christian
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Scrollkeeper-devel mailing list
> Scr...@li...
> https://lists.sourceforge.net/lists/listinfo/scrollkeeper-devel
> 

[Scrollkeeper-devel] Scrollkeeper translations and translation projects

[Christian R. <me...@gn...>]

Hi!

As you probably all know scrollkeeper has had translations available in
GNOME cvs, so that GNOME translators inside the GNOME Translation
Project (GTP) could more easily translate scrollkeeper, as GNOME uses
scrollkeeper in it's core help system.

However, as there have been clashes in the past with the Translation
Project (TP; http://www.iro.umontreal.ca/contrib/po/HTML/) where there
unfortunately were translators from both projects working on the same
translations independantly of each other, and as a result much wasted
work and confusion, we've had to finally decide on and agree on what
kind of software should be taken care of what translation project.

As a result, we've agreed on:

1) Translations of software present in GNOME cvs should be handled by
the GNOME Translation Project (GTP). Important GNOME software or
software that wants in other ways to be considered a part of GNOME
should use (or move to) the GNOME cvs anyway; there are many other
development benefits of using the same cvs for software under the same
project umbrella.

2) Translations of all other (independant) software should be handled by
the Translation Project (TP). The TP has a much better infrastructure
for handling of translations of software from many sources anyway.

This among other things means that we are phasing out the "extra-po"
directory in GNOME cvs where scrollkeeper and other "out-of-gnome-cvs"
translations has been located until now.

So, we need to know how to proceed. The decision is up to you -- are you
moving to work more closely with GNOME and want to use the GNOME cvs, or
are you more comfortable with scrollkeeper being independantly developed
as it is now? From previous communication I understand that scrollkeper
maintainers prefer to have it as an independant project, so I guess the
answer above is the second one. In that case we should help you set up
scrollkeeper in the TP and import existing translations there
(instructions for adding modules to the TP are at
http://www.iro.umontreal.ca/contrib/po/HTML/maintainers.html).

Opinions/comments/decisions?


Christian

[Scrollkeeper-devel] ScrollKeeper translations

[Dan M. <mu...@al...>]

ScrollKeeper translators,

Thanks for all your hard work localizing ScrollKeeper.  Many of you have
submitted updated po files recently.  I just released version 0.3.12 with
all the new translations.  Unfortunately, shortly before the release I
discovered that a patch that was in 0.3.11 was not committed to CVS and so
I wound up committing it just before 0.3.12.  It has about 8 new strings
in it.  Most (but not all) po files are affected.  (See below for the
status of each locale.)

I attached the pot file.  If you have a GNOME cvs account, please put any 
updated po files in the gnome-i18n/extra-po/scrollkeeper directory.  
Otherwise, please email updated po files to me or the scrollkeeper-devel 
mailing list.

I plan to put out 0.3.13 in a week or two with any updated po files.

Thanks,

Dan

----------------------------------------------
az:
.............................. done.
7 translated messages, 6 fuzzy translations, 226 untranslated messages.

be:
............................... done.
224 translated messages, 7 fuzzy translations, 8 untranslated messages.

ca:
............................. done.
229 translated messages, 5 fuzzy translations, 5 untranslated messages.

cs:
............................... done.
224 translated messages, 7 fuzzy translations, 8 untranslated messages.

da:
......................... done.
238 translated messages, 1 fuzzy translation.

de:
........................ done.
239 translated messages.

el:
.................................. done.
184 translated messages, 11 fuzzy translations, 44 untranslated messages.

es:
........................ done.
239 translated messages.

fr:
........................... done.
192 translated messages, 7 fuzzy translations, 40 untranslated messages.

hu:
.................................. done.
180 translated messages, 10 fuzzy translations, 49 untranslated messages.

it:
................................. done.
126 translated messages, 61 fuzzy translations, 52 untranslated messages.

ja:
....................................... done.
185 translated messages, 15 fuzzy translations, 39 untranslated messages.

ko:
.................................. done.
184 translated messages, 11 fuzzy translations, 44 untranslated messages.

nl:
............................. done.
229 translated messages, 5 fuzzy translations, 5 untranslated messages.

no:
.............................. done.
227 translated messages, 6 fuzzy translations, 6 untranslated messages.

pl:
..................................... done.
213 translated messages, 13 fuzzy translations, 13 untranslated messages.

pt_BR:
.................................. done.
184 translated messages, 11 fuzzy translations, 44 untranslated messages.

ro:
............................... done.
224 translated messages, 7 fuzzy translations, 8 untranslated messages.

ru:
................................ done.
224 translated messages, 8 fuzzy translations, 7 untranslated messages.

sk:
............................... done.
224 translated messages, 7 fuzzy translations, 8 untranslated messages.

sl:
...................................... done.
187 translated messages, 14 fuzzy translations, 38 untranslated messages.

sv:
................................ done.
224 translated messages, 8 fuzzy translations, 7 untranslated messages.

tr:
...................................... done.
185 translated messages, 14 fuzzy translations, 40 untranslated messages.

uk:
............................. done.
7 translated messages, 6 fuzzy translations, 226 untranslated messages.

vi:
.................................... done.
165 translated messages, 12 fuzzy translations, 62 untranslated messages.

zh_CN:
..................................... done.
175 translated messages, 13 fuzzy translations, 51 untranslated messages.

zh_TW:
...................................... done.
187 translated messages, 14 fuzzy translations, 38 untranslated messages.
-------------------------------------------------


---------- Forwarded message ----------
Date: Thu, 23 Jan 2003 00:33:11 -0600 (CST)
From: Dan Mueth <mu...@al...>
To: ScrollKeeper Devel <scr...@li...>
Subject: [Scrollkeeper-devel] ScrollKeeper 0.3.12 Released


ScrollKeeper 0.3.12 is now available.

New in this release:
   * Many updated and new translations.
   * Security fix relating to temporary files.
   * i18n fallback
   * Support for <refentry> sections
   * A couple i18n fixes
   * Fixes to RPM .spec file
   * Quieter output in non-verbose mode.
   * A number of other bug fixes.

Thanks to everybody who has been testing, writing bug reports, and
submitting patches.

You can get ScrollKeeper 0.3.12 at:
	http://sourceforge.net/projects/scrollkeeper

If you find any bugs, please submit them to the bug tracker at:
	http://sourceforge.net/tracker/?group_id=11543&atid=111543
Please be sure to include your name and email address in any bugs you
enter so we can contact you if necessary.

If you would like to contribute to ScrollKeeper:
There are instructions for getting the latest source from CVS at:
	http://scrollkeeper.sourceforge.net/cvs.shtml
Look over the TODO list in the tarball or CVS and the bug list on the web, 
find something you're interested in working on, and email
scr...@li... with your choice so that others 
don't duplicate your work.

- The ScrollKeeper Team





-------------------------------------------------------
This SF.net email is sponsored by: Scholarships for Techies!
Can't afford IT training? All 2003 ictp students receive scholarships.
Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more.
www.ictp.com/training/sourceforge.asp
_______________________________________________
Scrollkeeper-devel mailing list
Scr...@li...
https://lists.sourceforge.net/lists/listinfo/scrollkeeper-devel

[Scrollkeeper-devel] ScrollKeeper 0.3.12 Released

[Dan M. <mu...@al...>]

ScrollKeeper 0.3.12 is now available.

New in this release:
   * Many updated and new translations.
   * Security fix relating to temporary files.
   * i18n fallback
   * Support for <refentry> sections
   * A couple i18n fixes
   * Fixes to RPM .spec file
   * Quieter output in non-verbose mode.
   * A number of other bug fixes.

Thanks to everybody who has been testing, writing bug reports, and
submitting patches.

You can get ScrollKeeper 0.3.12 at:
	http://sourceforge.net/projects/scrollkeeper

If you find any bugs, please submit them to the bug tracker at:
	http://sourceforge.net/tracker/?group_id=11543&atid=111543
Please be sure to include your name and email address in any bugs you
enter so we can contact you if necessary.

If you would like to contribute to ScrollKeeper:
There are instructions for getting the latest source from CVS at:
	http://scrollkeeper.sourceforge.net/cvs.shtml
Look over the TODO list in the tarball or CVS and the bug list on the web, 
find something you're interested in working on, and email
scr...@li... with your choice so that others 
don't duplicate your work.

- The ScrollKeeper Team

Re: [Scrollkeeper-devel] too much probs :-(

[Dan M. <mu...@al...>]

On Mon, 20 Jan 2003, [ISO-8859-15] Camille B=E9gnis wrote:

> Hello,
>=20
> I am experimenting too much stability problems with=20
> scrollkeeper/yelp/khelpcenter
>=20
> I have problems registering my OMF files, which do not appear on help=20
> browsers even if the OMF file is valid and teh category OK. :-(

Do any of the documents from the ScrollKeeper system appear?  Is it just =
a=20
problem with recently added documents, or with all of them?

> As the scrollkeeper-{install,update,uninstall} messages are always the=20
> same, I have no clue on what's going wrong.

Try using verbose mode on these commands if you want more information on=20
what is working and what isn't working.  Also, ScrollKeeper keeps a log=20
(typically /var/log/scrollkeeper.log) so you can always look in there to=20
see what is happening and any errors.

> After playing a little with those scripts, scrollkeeper is all screwed=20
> up. When I try to launch khelpcenter for example:
>=20
> [...]
> khelpcenter (kdebase): Requested plugin documents for ID konqueror
> khelpcenter (kdebase): Eeek, our group pointer is NULL!
> khelpcenter (kdebase): Scrollkeeper contents file '' does not exist.
> [...]
>=20
> And yelp looks empty. If I reinstall yelp, it works again...

When you reinstall yelp, do the documents for the new OMF files appear? =20
If so, it would seem that the problem is not with=20
scrollkeeper-{install,update,uninstall}.

If you find it helpful to poke around in ScrollKeeper a bit, keep an eye
on /var/lib/scrollkeeper/scrollkeeper_docs to see if new documents get
added to the bottom of the file (or removed).  To see what is in a given
contents list, look in /var/lib/scrollkeeper/<locale>/*.  Overall, it
should be pretty simple to identify whether ScrollKeeper is generally
working or not.

If you need to find out what paths ScrollKeeper is using, use=20
scrollkeeper-config.  And don't forget that the OMF file path is stored i=
n=20
/etc/scrollkeeper.conf.

At any rate, the fact that reinstalling Yelp influences whether things
works suggests that this particular problem is probably not with
ScrollKeeper.  It may have something to do with how paths are set up when=
=20
packages (perhaps Yelp) are built.

-Dan

[Scrollkeeper-devel] too much probs :-(

[<ca...@ma...>]

Hello,

I am experimenting too much stability problems with 
scrollkeeper/yelp/khelpcenter

I have problems registering my OMF files, which do not appear on help 
browsers even if the OMF file is valid and teh category OK. :-(

As the scrollkeeper-{install,update,uninstall} messages are always the 
same, I have no clue on what's going wrong.

After playing a little with those scripts, scrollkeeper is all screwed 
up. When I try to launch khelpcenter for example:

[...]
khelpcenter (kdebase): Requested plugin documents for ID konqueror
khelpcenter (kdebase): Eeek, our group pointer is NULL!
khelpcenter (kdebase): Scrollkeeper contents file '' does not exist.
[...]

And yelp looks empty. If I reinstall yelp, it works again...

Camille.

[Scrollkeeper-devel] docbook 4.2.0

[Robin C. <rc...@wy...>]

Is scrollkeeper going to be updated to use docbook 4.2.0

Robin Cook

[Scrollkeeper-devel] Subject element epty?

[<ca...@ma...>]

Hello,

I have found what I consider an error in the scrollkeeper-omf.dtd with 
respect to the OMF. The "subject" is defined as EMPTY:
<!ELEMENT  subject      EMPTY                                        >

While at ibiblio:

" 7.  subject: The topic of the resource. Typically, this element 
employs keywords that summarize the subject or content of the resource."
<!ELEMENT  subject      (#PCDATA)                                    >


This is a problem because then there is no place to put keywords in.

Camille.

Re: [Scrollkeeper-devel] Varii

[Dan M. <mu...@al...>]

On Mon, 20 Jan 2003, Camille B=E9gnis wrote:

> > One option would be to hack the ScrollKeeper category list shipped by
> > Mandrake and add a new category at the top called "Mandrake".  That w=
ould=20
> > vanish though if the user installs a non-Mandrake version of ScrollKe=
eper,=20
> > so I don't see that as a very nice solution.  It may be a stopgap sol=
ution=20
> > though.
>=20
> The document do not vanish if the OMF file contains for instance:
>=20
> <subject category=3D"Mandrake">
> <subject category=3D"General|Linux|Distributions|Mandrake">
>
> So that even if the "Mandrake" category do not exist in a non-Mandrake=20
> version of ScrollKeeper, the manual can be found under the standard=20
> category.

Right.  If ScrollKeeper is updated such that the "Mandrake" category=20
dissappeared, the document would still appear in the second category.

> How can I modify the categories list? Is it enough to add it in=20
> scrollkeeper_cl.xml? SHould scrollkeeper be recompiled?

Modify cl/templates/scrollkeeper_cl.xml.in and then rebuild.  Note that
you will then need to update the po files so the category is translated
for each locale.  I guess it will just have one new entry ("Mandrake") if=
=20
that is the only new category you add.

-Dan

Re: [Scrollkeeper-devel] Varii

[<ca...@ma...>]

Dan Mueth wrote:
> On Fri, 17 Jan 2003, Camille Bégnis wrote:
> 
> 
>>Well, this is my point. I find legitimate that a Mandrake fresh user can 
>>find a "Mandrake" top level category in his help browser; moreover when 
>>the books found under it cover a large spectrum of topics from 
>>installation to system admin, through KDE, gnome, etc.
>>What approach do you recommend in this case?
> 
> 
> ScrollKeeper doesn't currently provide a nice mechanism to do what you 
> want.  I'm not sure whether it should or not.  
> 
> When GNOME used Nautilus as the help browser, we had what we called
> "toplevel documents" which were listed in an XML file installed by
> Nautilus.  These documents would appear at the top of the document index.  
> This made it easy for a given distributor (such as Mandrake) to just
> customize one data file to get documents to appear in a prominent
> location.  Having it done in the help browser instead of ScrollKeeper 
> meant that only the help browser could control which are the toplevel 
> documents, instead of allowing each package to tell ScrollKeeper which 
> documents it thinks should be in the toplevel.
> 
> One option would be to hack the ScrollKeeper category list shipped by
> Mandrake and add a new category at the top called "Mandrake".  That would 
> vanish though if the user installs a non-Mandrake version of ScrollKeeper, 
> so I don't see that as a very nice solution.  It may be a stopgap solution 
> though.

The document do not vanish if the OMF file contains for instance:

<subject category="Mandrake">
<subject category="General|Linux|Distributions|Mandrake">

So that even if the "Mandrake" category do not exist in a non-Mandrake 
version of ScrollKeeper, the manual can be found under the standard 
category.
How can I modify the categories list? Is it enough to add it in 
scrollkeeper_cl.xml? SHould scrollkeeper be recompiled?

Camille.

> I prefer having a single data file installed on the system which indicates 
> which documents belong at the top.  This could be an optional 
> configuration file for the help browser or ScrollKeeper which would not 
> get written over by upgrading either package.  That would maintain the 
> top documents if the user does an upgrade.
> 
> Dan
> 
> 
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
> are you planning your Web Server Security? Click here to get a FREE
> Thawte SSL guide and find the answers to all your  SSL security issues.
> http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
> _______________________________________________
> Scrollkeeper-devel mailing list
> Scr...@li...
> https://lists.sourceforge.net/lists/listinfo/scrollkeeper-devel
> 

[Scrollkeeper-devel] ScrollKeeper-0.3.12beta

[Dan M. <mu...@al...>]

I just put a tarball taken directly from CVS on SourceForge:
https://sourceforge.net/project/showfiles.php?group_id=11543&release_id=134781

I haven't had a chance to do much testing with it yet.  There have been
quite a few patches since 0.3.11, but they have all been pretty small.  
Many updated translations have gone in. If you get a chance to test it,
please email with your results.

If there aren't any problems, we'll put out 0.3.12 shortly.

-Dan

Re: [Scrollkeeper-devel] Varii

[Dan M. <mu...@al...>]

On Fri, 17 Jan 2003, Camille B=E9gnis wrote:

> Well, this is my point. I find legitimate that a Mandrake fresh user ca=
n=20
> find a "Mandrake" top level category in his help browser; moreover when=
=20
> the books found under it cover a large spectrum of topics from=20
> installation to system admin, through KDE, gnome, etc.
> What approach do you recommend in this case?

ScrollKeeper doesn't currently provide a nice mechanism to do what you=20
want.  I'm not sure whether it should or not. =20

When GNOME used Nautilus as the help browser, we had what we called
"toplevel documents" which were listed in an XML file installed by
Nautilus.  These documents would appear at the top of the document index.=
 =20
This made it easy for a given distributor (such as Mandrake) to just
customize one data file to get documents to appear in a prominent
location.  Having it done in the help browser instead of ScrollKeeper=20
meant that only the help browser could control which are the toplevel=20
documents, instead of allowing each package to tell ScrollKeeper which=20
documents it thinks should be in the toplevel.

One option would be to hack the ScrollKeeper category list shipped by
Mandrake and add a new category at the top called "Mandrake".  That would=
=20
vanish though if the user installs a non-Mandrake version of ScrollKeeper=
,=20
so I don't see that as a very nice solution.  It may be a stopgap solutio=
n=20
though.

I prefer having a single data file installed on the system which indicate=
s=20
which documents belong at the top.  This could be an optional=20
configuration file for the help browser or ScrollKeeper which would not=20
get written over by upgrading either package.  That would maintain the=20
top documents if the user does an upgrade.

Dan

Re: [Scrollkeeper-devel] Varii

[<ca...@ma...>]

Hi,

thanks all for your quick replies, it proves me there's still someone 
behind scrollkeeper ;-)

Malcolm Tredinnick wrote:
> On Thu, Jan 16, 2003 at 07:58:04PM +0100, Camille Bégnis wrote:
> 
>>And I have some practical quesions:
>>
>>- Is it possible to use other categories than the ones in categories.xsl?

[...]

> One case where you may wish to just have a distro-specific
> customisation, I guess, is if you wanted to have, say, "Mandrake
> documentation" as a top-level category. My personal preference would be
> to rethink your categorisation at that point, but even within my own
> company I am hardly known as somebody sensitive to company marketing
> goals and public image, so my personal preference is worth little here.

Well, this is my point. I find legitimate that a Mandrake fresh user can 
find a "Mandrake" top level category in his help browser; moreover when 
the books found under it cover a large spectrum of topics from 
installation to system admin, through KDE, gnome, etc.
What approach do you recommend in this case?

>>- Which stylesheets are used for performing docbook transformations? Is 
>>it possible to use a custom stylesheet layer?
> 
> 
> Scrollkeeper does not do any document transformation. It is purely a
> meta-information system used to locate the document on your system and
> quickly retrieve certain bits of information about it (the stuff in the
> .omf files). Once an application has retrieved a document (or, really,
> just the meta-data), it can do whatever transformations it wishes.

OK, I just got the information that you cannot change the stylesheets 
used by either yelp or khelpcenter :-(
This is a major annoyance IMHO.
So I guess we'll stick to HTML instead of XML, and discard tree navigation.

Thanks again,

Camille.

Re: [Scrollkeeper-devel] Varii

[Dan M. <mu...@al...>]

Thanks for the reply Malcolm.  I don't have a lot to add to it. =20
Development has slowed dramatically, although at this time most of the=20
work which needs to be done is really just fixing a decent sized list of=20
known bugs and issues.  We desperately need to get out a release with the=
=20
latest translations and bug fixes.

-Dan


On Fri, 17 Jan 2003, Malcolm Tredinnick wrote:

> On Thu, Jan 16, 2003 at 07:58:04PM +0100, Camille B=E9gnis wrote:
> > Hello,
>=20
> Hi. :-)
>=20
> > I'm finally getting to scrollkeeper after one year hesitating, I hope=
=20
> > this is the right place to ask my questions.
>=20
> Yes, it certainly is. It is a fairly low-traffic list, but it does get
> read.
>=20
> > First of all, what's the status of developments? I see the last news =
on=20
> > website are dated March 18, 2002: is the project alive?
>=20
> The project is alive, but temporarily sleeping. Dan Mueth, the
> maintainer, has been a bit busy of late. I have been trying to fix up a
> few things here and there and polish the rough corners, but my day job
> has interfered for the past couple of months (why is it always over
> Christmas?? Grrr!).
>=20
> Dan and I keep muttering to each other that we should get out a new
> release, since there have been a number of fixes in CVS since the last
> release. The "big picture" is that not too much has changed since the
> last release. However, there have been a number of small things
> (including a security fix).
>=20
> > Then I plan to begin using scrollkeeper for Mandrake documentation.
>=20
> Yay!
>=20
> > And I have some practical quesions:
> >=20
> > - Is it possible to use other categories than the ones in categories.=
xsl?
>=20
> I would prefer that if you wanted extra categories, raise them on this
> list and we can add them to the distributed list. The problem with usin=
g
> your own categories is that your documentation install scripts will not
> work without your particular customised version of categories.xsl. Now,
> from a distributor's point of view, you may be willing to make that
> decision and argue that your users should only upgrade via Mandrake
> packages. However, if there are legitimate general categories that are
> missing, let's put them into general circulation.
>=20
> I don't really know what is behind the above question, so I may have
> missed your point. If so, can you provide more context or an example of
> what you might wish to customise?
>=20
> One case where you may wish to just have a distro-specific
> customisation, I guess, is if you wanted to have, say, "Mandrake
> documentation" as a top-level category. My personal preference would be
> to rethink your categorisation at that point, but even within my own
> company I am hardly known as somebody sensitive to company marketing
> goals and public image, so my personal preference is worth little here.
>=20
> > - Which stylesheets are used for performing docbook transformations? =
Is=20
> > it possible to use a custom stylesheet layer?
>=20
> Scrollkeeper does not do any document transformation. It is purely a
> meta-information system used to locate the document on your system and
> quickly retrieve certain bits of information about it (the stuff in the
> .omf files). Once an application has retrieved a document (or, really,
> just the meta-data), it can do whatever transformations it wishes.
>=20
> Note, that although scrollkeeper currently is used to mostly index XML
> files (in DocBook format), this is not compulsory. It can (and should)
> be used to store information about PDF files, HTML, etc. The MIME type
> for the files is stored as part of the OMF field (in the <format> field=
),
> so a retrieving application can behave appropriately.
>=20
> If there is anything unclear about the above, please sing out and I (or
> somebody else) will try to explain.
>=20
> Serious request: Please feel quite free to flame me on this list or
> privately and beat me (metaphorically) over the head if you feel like
> genuine requests for improvement or help are being ignored (this goes
> for everybody else, too). I would like to see scrollkeeper get better,
> but it's too easy for me to just push it aside and do other, potentiall=
y
> more interesting, stuff most of the time, so I tend to be very slack.
>=20
> Cheers,
> Malcolm
>=20
>=20

Re: [Scrollkeeper-devel] Varii

[Malcolm T. <ma...@co...>]

On Thu, Jan 16, 2003 at 07:58:04PM +0100, Camille B=E9gnis wrote:
> Hello,

Hi. :-)

> I'm finally getting to scrollkeeper after one year hesitating, I hope=20
> this is the right place to ask my questions.

Yes, it certainly is. It is a fairly low-traffic list, but it does get
read.

> First of all, what's the status of developments? I see the last news on=
=20
> website are dated March 18, 2002: is the project alive?

The project is alive, but temporarily sleeping. Dan Mueth, the
maintainer, has been a bit busy of late. I have been trying to fix up a
few things here and there and polish the rough corners, but my day job
has interfered for the past couple of months (why is it always over
Christmas?? Grrr!).

Dan and I keep muttering to each other that we should get out a new
release, since there have been a number of fixes in CVS since the last
release. The "big picture" is that not too much has changed since the
last release. However, there have been a number of small things
(including a security fix).

> Then I plan to begin using scrollkeeper for Mandrake documentation.

Yay!

> And I have some practical quesions:
>=20
> - Is it possible to use other categories than the ones in categories.xs=
l?

I would prefer that if you wanted extra categories, raise them on this
list and we can add them to the distributed list. The problem with using
your own categories is that your documentation install scripts will not
work without your particular customised version of categories.xsl. Now,
from a distributor's point of view, you may be willing to make that
decision and argue that your users should only upgrade via Mandrake
packages. However, if there are legitimate general categories that are
missing, let's put them into general circulation.

I don't really know what is behind the above question, so I may have
missed your point. If so, can you provide more context or an example of
what you might wish to customise?

One case where you may wish to just have a distro-specific
customisation, I guess, is if you wanted to have, say, "Mandrake
documentation" as a top-level category. My personal preference would be
to rethink your categorisation at that point, but even within my own
company I am hardly known as somebody sensitive to company marketing
goals and public image, so my personal preference is worth little here.

> - Which stylesheets are used for performing docbook transformations? Is=
=20
> it possible to use a custom stylesheet layer?

Scrollkeeper does not do any document transformation. It is purely a
meta-information system used to locate the document on your system and
quickly retrieve certain bits of information about it (the stuff in the
.omf files). Once an application has retrieved a document (or, really,
just the meta-data), it can do whatever transformations it wishes.

Note, that although scrollkeeper currently is used to mostly index XML
files (in DocBook format), this is not compulsory. It can (and should)
be used to store information about PDF files, HTML, etc. The MIME type
for the files is stored as part of the OMF field (in the <format> field),
so a retrieving application can behave appropriately.

If there is anything unclear about the above, please sing out and I (or
somebody else) will try to explain.

Serious request: Please feel quite free to flame me on this list or
privately and beat me (metaphorically) over the head if you feel like
genuine requests for improvement or help are being ignored (this goes
for everybody else, too). I would like to see scrollkeeper get better,
but it's too easy for me to just push it aside and do other, potentially
more interesting, stuff most of the time, so I tend to be very slack.

Cheers,
Malcolm

--=20
The hardness of butter is directly proportional to the softness of
the bread.

[Scrollkeeper-devel] Varii

[<ca...@ma...>]

Hello,

I'm finally getting to scrollkeeper after one year hesitating, I hope 
this is the right place to ask my questions.

First of all, what's the status of developments? I see the last news on 
website are dated March 18, 2002: is the project alive?

Then I plan to begin using scrollkeeper for Mandrake documentation. And 
I have some practical quesions:

- Is it possible to use other categories than the ones in categories.xsl?

- Which stylesheets are used for performing docbook transformations? Is 
it possible to use a custom stylesheet layer?

Thanks,

--
Camille Bégnis
MandrakeSoft Documentation Manager

[Scrollkeeper-devel] Re: Czech translation of scrollkeeper

[Karl E. <ke...@gm...>]

Dan Mueth <mu...@al...> writes:

> Or is there a simpler way?

Using the Free TP (Translation Project), of course ;)  We handle all
file exchanges by mail; for more info ask tra...@IR...
or just visit

    http://www.iro.umontreal.ca/contrib/po/HTML/maintainers.html

-- 
ke...@su... (work) / ke...@gm... (home):              |
http://www.gnu.franken.de/ke/                            |      ,__o
Free Translation Project:                                |    _-\_<,
http://www.iro.umontreal.ca/contrib/po/HTML/             |   (*)/'(*)

[Scrollkeeper-devel] re: i18n issues

[Marius A. <man...@rd...>]

Regarding my previous mail, the incorrect entries in
/var/lib/scrollkeeper were because of incorrect omf files.

How could I get the same page as shown in yelp startup in a similar way
to scrollkeeper-get-toc-from-docpath document.xml? Is it possible to get
the toc for a category too, like "GNOME|Applications" ?

gedit, which belongs to "GNOME|Applications|Accessories", it's not
listed in yelp. It doesn't list Accesories at all. file-roller, which
belongs to "GNOME|Applications", it's listed.
Is this a problem with yelp stylesheets?

--=20
Solu=C5=A3ii informatice bazate pe Linux / Linux-based IT solutions
www.galuna.ro

[Scrollkeeper-devel] i18n issues

[Marius A. <man...@rd...>]

Hi

There are several problems with scrollkeeper, yelp and i18n. The most
important is that localized versions of documentation don't appear in
TOC pages when starting yelp and browsing through categories.
For example, before translating gnome2 user guide, in the yelp start up
page there was an entry, Core Desktop, which had Desktop Sessions in it.
After installing a translated user guide and running
scrollkeeper-dbupdate, the entry dissapeared.
I'm investigating this, but so far I found only one weird thing ( which
may be right? ). In the generated
/var/lib/scrollkeeper/scrollkeeper_docs
the entries for localized omf files contain only name_of_document.xml,
not all the path. e.g.

/usr/share/omf/gnome-media/grecord-C.omf        5     =20
file:/usr/share/gnome/help/grecord/C/grecord.xml
/usr/share/omf/gnome-media/grecord-ro.omf        5       grecord.xml

Is this right?

I'm using cvs version from jan 3.
thanks
--=20
Solu=C5=A3ii informatice bazate pe Linux / Linux-based IT solutions
www.galuna.ro

[Scrollkeeper-devel] docbook/refentry support for toc generation

[Guido D. <gui...@gm...>]

I am registering a docbook file in /oaf which has actually a type
of <!doctype reference .... > listing a series of <refentry> parts.
It's actually the docbook master for manpages - the support for
this filetype is far from acceptable. The following patch will
atleast read a "toc" list for it.

Using "yelp" it shows a toc list thereabout but sadly non of listed
items seems to be able link anywhere but that's probably due to
inferior conversion of a docbook-refentrylist into the view format
for the widget. (xsl stylesheets for conversion of dbk-refentries
to html is neither best of all, so I was not quite astonished).

cheers, guido                                  http://zziplib.sf.net

Re: [Scrollkeeper-devel] Czech translation of scrollkeeper

[Malcolm T. <ma...@co...>]

On Tue, Dec 17, 2002 at 06:39:52PM -0600, Dan Mueth wrote:
> Good point.  I think this is the first ScrollKeeper CVS account for a 
> translater, but then we also get translations emailed to us.  So, there is 
> still a possibility of a collision.  Plus, even with a single CVS system, 
> two people could still check out and translate at the same time.

With a single CVS system, you usually have translation "teams" to avoid
the collision problem. Within any given language team, the members work
out who translates which packages. But if we are going to allow mailed
in translations as well, then it is just going to require care on our
part. Committing any new translations as soon as they arrive will help
ease the liklihood of collisions and we can deal with the corner cases
as they arrive.

> How about we let people use either GNOME or SourceForge CVS as they like
> (perhaps encouraging people to use GNOME CVS), or even just email the
> translations.  However, they should always make sure they start with the
> .po file out of one of the two CVS systems (ie. not from a release).  
> Then, anybody who commits a .po file to CVS make sure they add the same
> .po file to both CVS accounts.

This sounds messy and it won't work like you think. Imagine that
somebody from the Swedish team commits a translated (po) file to
extra-po. This person will not have a sourceforge account. So somebody
(me?) has to watch for that commit and then commit the same file to
sourceforge.

Similarly, if somebody is committing directly to sourceforge, there is
almost certainly going to be a collision with GNOME CVS, since the GNOME
guys are way too keen about translating stuff. It won't do any good to
put a README in the extra-po module at GNOME CVS saying something like
"don't translate for fr_CA locale", because it won't get read. The
translators just tend to go on autopilot (which, given the number of
strings and modules they translate, is not unreasonable).

> This makes more work for people who work with CVS, but makes things
> simpler for translators and allows people to still use gnome-extra, which
> means we get a lot more translations done than if we just used
> SourceForge.
> 
> Or is there a simpler way?

I cannot think of a solution at the moment. I'll think about it a bit,
but I think anything involving two CVS repositories is going to involve
a bit of hackiness. I don't think this is entirely bad, since I agree
that getting as many translations as possible is good and I don't want
to alienate those who are translating and mailing in their contributions
to you. But we need to work out something that we can use consistently
to avoid annoying people.


Will cogitate a bit,
Malcolm

-- 
Tolkien is hobbit-forming.

Re: [Scrollkeeper-devel] Czech translation of scrollkeeper

[Dan M. <mu...@al...>]

Malcolm,

Good point.  I think this is the first ScrollKeeper CVS account for a 
translater, but then we also get translations emailed to us.  So, there is 
still a possibility of a collision.  Plus, even with a single CVS system, 
two people could still check out and translate at the same time.

How about we let people use either GNOME or SourceForge CVS as they like
(perhaps encouraging people to use GNOME CVS), or even just email the
translations.  However, they should always make sure they start with the
.po file out of one of the two CVS systems (ie. not from a release).  
Then, anybody who commits a .po file to CVS make sure they add the same
.po file to both CVS accounts.  

This makes more work for people who work with CVS, but makes things
simpler for translators and allows people to still use gnome-extra, which
means we get a lot more translations done than if we just used
SourceForge.

Or is there a simpler way?

Dan

On Wed, 18 Dec 2002, Malcolm Tredinnick wrote:

> On Tue, Dec 17, 2002 at 10:32:37AM -0600, Dan Mueth wrote:
> > I just added you to the SourceForge project, so you should be able to 
> > comit translations directly to SourceForge CVS if you are comfortable 
> > doing so.
> > 
> > There is also a scrollkeeper directory in the extra-po portion of GNOME 
> > CVS.  We periodically drop of the .pot file there and pick up any updated 
> > .po files when we notice them or when translators email us to notify us 
> > updates are there.
> 
> We should make up our minds and just use one method or the other,
> really. Either translators get commit privileges to sourceforge _or_ we
> use the GNOME extra-po module. Otherwise we will end up with duplicated
> work and hurt feelings (it's happened before).
> 
> My preference would be to use the extra-po module, since the GNOME
> translators are pretty keen dudes and translate everything in sight, but
> since I'm not a translator, I'd want to hear other views as well.
> 
> Malcolm
> 
> 

Re: [Scrollkeeper-devel] Czech translation of scrollkeeper

[Malcolm T. <ma...@co...>]

On Tue, Dec 17, 2002 at 10:32:37AM -0600, Dan Mueth wrote:
> I just added you to the SourceForge project, so you should be able to 
> comit translations directly to SourceForge CVS if you are comfortable 
> doing so.
> 
> There is also a scrollkeeper directory in the extra-po portion of GNOME 
> CVS.  We periodically drop of the .pot file there and pick up any updated 
> .po files when we notice them or when translators email us to notify us 
> updates are there.

We should make up our minds and just use one method or the other,
really. Either translators get commit privileges to sourceforge _or_ we
use the GNOME extra-po module. Otherwise we will end up with duplicated
work and hurt feelings (it's happened before).

My preference would be to use the extra-po module, since the GNOME
translators are pretty keen dudes and translate everything in sight, but
since I'm not a translator, I'd want to hear other views as well.

Malcolm

-- 
I intend to live forever - so far so good.

Re: [Scrollkeeper-devel] Czech translation of scrollkeeper

[Dan M. <mu...@al...>]

Hi,

I just added you to the SourceForge project, so you should be able to 
comit translations directly to SourceForge CVS if you are comfortable 
doing so.

There is also a scrollkeeper directory in the extra-po portion of GNOME 
CVS.  We periodically drop of the .pot file there and pick up any updated 
.po files when we notice them or when translators email us to notify us 
updates are there.

A number of people have emailed recently that new translations are done.  
I will merge them into CVS and cut a new release soon.  There hasn't been 
a release since we put in the nice security patch from Red Hat, so it is 
definitely time.

-Dan


On Tue, 17 Dec 2002, Miloslav Trmac wrote:

> Hello,
> [sent here, the address at uchicago.edu doesn't work]
> I have just finished Czech translation of scrollkeeper .pot file
> from developer.gnome.org/projects/gtp/status, but scrollkeeper
> seems to be using CVS at SourceForge. Is there a way to commit
> the .po file at gnome, or should I use cvs.ScrollKeeper.sf.net?
> If the latter, my SF user name is 'trmac'.
> Thanks
> Please CC: me on replies
> 	Mirek Trmac
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:
> With Great Power, Comes Great Responsibility 
> Learn to use your power at OSDN's High Performance Computing Channel
> http://hpc.devchannel.org/
> _______________________________________________
> Scrollkeeper-devel mailing list
> Scr...@li...
> https://lists.sourceforge.net/lists/listinfo/scrollkeeper-devel
>