crystaldoc-main Mailing List for Translated docs for Crystal Space 3D SDK
Status: Alpha
Brought to you by:
vknecht
You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(3) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
|
Feb
(8) |
Mar
|
Apr
|
May
(1) |
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Vincent K. <vi...@ie...> - 2005-07-07 18:22:35
|
Hello ! As you may have noticed, CS documentation is being heavily restructured these days. Also, recent updates related to documentation build process are interesting, like: - an updated texi2html - the move of nodefix logic from a CS Jamfile to mk/docs.jam - removal of runtexi2*.sh and cleaning/enhancement of build rules I've quickly tested updating texi2html and docs.jam in crystaldoc and nothing seems to be broken ;-) It even looks like issues with building other doc formats (like dvi) are fixed. I'm gonna tag the CVS repo some way (suggestions ?) then commit that in the next few days. Speaking of commits, I also set up a mailing list for them a few months ago, and I'll activate the syncmail script soon, so we can see what's going on. The ML page: https://lists.sourceforge.net/lists/listinfo/crystaldoc-cvs So please use english for future commit comments ;-) A new translation started a few months ago: German. Welcome Jan ! There was a volunteer for chinese too (hence the cn/ (which was a mistake of mine) and zh/ directories), but it's delayed since Andy moved to USA. It also looks like TexInfo format can't support such charsets... Still, there are issues to resolve to get a clean build process: - we lack a configure script so that tools are detected - the pictures need to be copied somehow in the build directory before doc build, especially for DVI output (they can be manually added afterward for HTML) - building on other OS than GNU/Linux - any other I forgot ? I'll try stripping CS autoconf stuff and add it to crystaldoc. For the pictures, we probably just need a few tweaks in some jam file. For other OS build, perhaps just adding macosx.jam and win32.jam will do... The web site also need care, I guess I'll put SPIP (http://www.spip.net/) so we can create articles in any language then translate them. That is roughly sorted by priority order, please comment/make suggestions. -- VK |
From: Vincent K. <vi...@ie...> - 2004-06-30 18:04:30
|
Hi it looks like i sent the presently forwarded message to myself... sorry for this. I updated building instructions on crystaldoc site, and wrote french page (just a translation of building instruction for now). -----Message transf=E9r=E9----- From: Vincent Knecht <vi...@ie...> To: Vincent Knecht <vi...@ie...> Subject: Re: [Crystaldoc-main] Jam files added in crystaldoc CVS Date: Sun, 27 Jun 2004 15:45:37 +0200 Hello Le ven 25/06/2004 =E0 21:27, Vincent Knecht a =E9crit : > At the moment, only HTML building works well, DVI kind of works but for > now, only the last language directory listed in crystaldoc/Jamfile is > taken in account, so using fr_dvi target builds spanish version :-( This is fixed now However, DVI output file is written in out/xx/dvi/xx/texinfo/ instead of out/xx/dvi I still have to test dvi transformation to ps or pdf. > The pictures inclusion still doesn't work, since the scripts don't take > the inclusion path in account for them. I modified both DVI and HTML .sh scripts to get pictures from $CRYSTAL/docs/texinfo/ directory, so now we have screenshots in the translations :-) |
From: Vincent K. <vi...@ie...> - 2004-06-25 19:25:13
|
Hi I finally took time to add build files (Jam based) for the translations, they're directly derived from CS ones. There are a few quirks though, and ($lang)/texinfo/Jamfile files rather clumsy taken together. At the moment, only HTML building works well, DVI kind of works but for now, only the last language directory listed in crystaldoc/Jamfile is taken in account, so using fr_dvi target builds spanish version :-( runtexi2dvi.sh utility does not expects args exactly the same way as runtexi2html.sh, or rather the fix for HTML build doesn't work for DVI (for others output format neither). This will need further investigations, and maybe modification of respective scripts, for now i wasn't able to resolve this issue by fiddling Jam rules. So, to build your prefered translation ;-) - set CRYSTAL env var to the directory of CS version which was translated. - call "jam es_html" or "jam fr_html". Resulting files will be in out/es/html or out/fr/html The pictures inclusion still doesn't work, since the scripts don't take the inclusion path in account for them. Note I didn't look closely at CS way of doing so, if I remember well pictures are copied in out/ subdirs. This will need some thoughts and work too. |
From: <ben...@id...> - 2004-05-25 08:44:57
|
Dear Open Source developer I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate. You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it. With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development. With many thanks for your participation, Benno Luthiger PS: The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/. We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list. _______________________________________________________________________ Benno Luthiger Swiss Federal Institute of Technology Zurich 8092 Zurich Mail: benno.luthiger(at)id.ethz.ch _______________________________________________________________________ |
From: Vincent K. <vi...@ie...> - 2004-02-16 19:40:47
|
hi i'm glad you finally was able to commit your files about the site, i added Spanish/Espanol in project block (with tilde, i hope i'm not wrong), and augmented your rights too, however you already should have been able to "submit a node". However, after some minutes connection with the site was refused, maybe another sf issue sorry, i'm not easy with this drupal site, and i'm considering a swap to phpnuke or some other... let me know what you think and if you have difficulties adding an annonce Le lun 16/02/2004 =E0 19:03, Pablo a =E9crit : > hello! > = =20 > now that cvs seems to be working for us i think it'd be the moment of > adding spanish to the languages list in the project, also i think a > section dedicated to the spanish translation would be very nice, so as > to put contact info and general guidelines. maybe also a new telling > about all this. > = =20 > i logged to the drupal site, but i don't think i can really change > anything. i'm sure you know what to do... > = =20 > greetings > = =20 > pablo |
From: Pablo <ca...@si...> - 2004-02-16 18:10:56
|
hello! now that cvs seems to be working for us i think it'd be the moment of adding spanish to the languages list in the project, also i think a section dedicated to the spanish translation would be very nice, so as to put contact info and general guidelines. maybe also a new telling about all this. i logged to the drupal site, but i don't think i can really change anything. i'm sure you know what to do... greetings pablo |
From: Arthur H. <art...@fr...> - 2004-02-16 16:58:19
|
that's a good thing :) good luck ;) |
From: Arthur H. <art...@fr...> - 2004-02-16 16:52:39
|
well sf.net has too much problems now, i will look forward to migrating to savannah because it's unbearable...look at the site status page lool I can't tell you anything now, sorry. |
From: Pablo <ca...@si...> - 2004-02-16 16:51:12
|
hello! right after sending the previous mail i managed to change my password using the sf interface (at the fourth try) and now everything seems to be working ok. i already commited some docs, and later i'll commit the rest i have translated (once i order my folders a bit). thank you for your patience and attention :) pablo |
From: Pablo <ca...@si...> - 2004-02-16 16:47:31
|
hello! i'm still trying to upload my changes to spanish translation. i tried changing my password but it dowsn't seem to work, sf goes stupid, and by ssh it also doesn't seem to work anyways i can download cvs files usingmy sf account, it's just i can't commit changes after that. i'll try creating a private key, but i'm not sure where to put it... sorry for not answering earlier, but i've been pretty busy, anyways i'd like to start working on the cvs as soon as possible... well, i'll report if i achieve any success pablo |
From: Vincent K. <vi...@ie...> - 2004-02-10 17:13:15
|
hi did you get my mail from friday saying you probably were impacted by this SF bug ? http://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D875403&group= _id=3D1&atid=3D200001 doesn't the pasword change trick work for you ? Le ven 06/02/2004 =E0 14:24, Pablo a =E9crit : > hello!! >=20 > i tried to commit the translated pages i have to the repository but it'= s > telling me i don't have write access... >=20 > strange because moments beforei checked everything out using ssh and my > developer account... >=20 > it's not the first time i commit something to sourceforge, but it's not > working and i don't know what can be.. >=20 > any ideas? >=20 > p >=20 >=20 > ------------------------------------------------------- > The SF.Net email is sponsored by EclipseCon 2004 > Premiere Conference on Open Tools Development and Integration > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > http://www.eclipsecon.org/osdn > _______________________________________________ > Crystaldoc-main mailing list > Cry...@li... > https://lists.sourceforge.net/lists/listinfo/crystaldoc-main |
From: Pablo <ca...@si...> - 2004-02-06 13:31:13
|
hello!! i tried to commit the translated pages i have to the repository but it's telling me i don't have write access... strange because moments beforei checked everything out using ssh and my developer account... it's not the first time i commit something to sourceforge, but it's not working and i don't know what can be.. any ideas? p |
From: Arthur H. <art...@fr...> - 2003-12-19 06:17:55
|
> i was speaking of making our own makefiles based on CS one, and check > which changes occured beetween CS 0.96 and CS 0.97 to make sure our > makefiles can cope with these two different CS versions. > > And i see at least one good reason we need a "link" with CS, > it's simply for including english texinfo file when we don't provide a > translated one. Probably through the use of $CRYSTAL. > > There are 2 or 3 solutions if you really don't want to rely on CS: > - producing a partial manual (ie. just the translated chapters) > - import all english file (& pictures), then translate them > - check out CS files from CVS (the CVS version or the 0.96.4) when > building manual (automatically on our CVS) then delete them ? Yeah, sure, we need the original english files included, but in fact after some reflexion your 2nd solution seems the best to me. That way we produce a complete manual, independant from CS. >>the building process is a different work than translation, then i see no >>reason for wich we shouldn't make another module :) >> >>if you're thinking as an enduser then what's possible for CVS is that : >> >>cvs co base >>cd base >>cvs co fr >> >>(note it would depend on our building process) > > that's the whole point, we can therefore not rely on relatives paths don't tell me we were going to use a same base with just one line modified, for both french and spanish translation :) i really hope you're wrong and i think you are, this should be possible to make some script taht will look for a FR/ or SP/ subdirectory to make the documentation, or even a script than will look for all subdirs with 2 letters like UK/ US/ AU/ CA/ etc ! > > >>>Wouldn't module splitting require having two (or 3 with 2 languages) >>>base directories for each (on local side) ? >> >>that's even the definition of a cvs module :) >> >> >>I hope we will be able to find a solution for this building process. >> >>To my mind we need cvs modules. Or we're gonna die under an horrible >>garbage 3 days after having committed our changes :) > > > where would the garbage come from ? do you mean from potential mistake > or what ? because each modification to the building process, will have to be done twice on TWO differents local repositories. That's the problem. If we include spanish tr. to our current module crystaldoc, since we don't care about spanish when translating french, since when translating spanish, pablo doesn't care about french, and since when one of us will make modifications to the building process, then he doesn't care about any translation at all ; i don't see any reason for wich we should have to checkout/update something larger than useful, deleting useless directories, and being warned by the cvs server that we deleted some dirs... There are 3 different ways for crystaldoc for the moment, those are -Building process -Spanish Translation -French Translation they are independant, ie working on one doesn't need the other, even if we finally include the building process into the translations directly (seems dangerous to me).... A.H. |
From: Vincent K. <vi...@ie...> - 2003-12-18 21:49:00
|
Le jeu 18/12/2003 =E0 20:28, Arthur Huillet a =E9crit : > > if it's possible, okay > > at least for now building our 0.96 french manual using 0.97 > > original files when translated one doesnt exists seem to produce > > good output (don't have checked precisely); at least no no-go error > >=20 > > So there's hope to achieve this :-) > > We should check if build process changed by diffing CS involved > > makefiles > /jamfiles > >=20 >=20 > the final building process should not be linked to CS in any way ! i was speaking of making our own makefiles based on CS one, and check which changes occured beetween CS 0.96 and CS 0.97 to make sure our makefiles can cope with these two different CS versions. And i see at least one good reason we need a "link" with CS, it's simply for including english texinfo file when we don't provide a translated one. Probably through the use of $CRYSTAL. There are 2 or 3 solutions if you really don't want to rely on CS: - producing a partial manual (ie. just the translated chapters) - import all english file (& pictures), then translate them - check out CS files from CVS (the CVS version or the 0.96.4) when building manual (automatically on our CVS) then delete them ? > > can you describe us how the retrieving and updating would differ ? >=20 >=20 > if we consider using different modules for ES and FR [and also for sure= =20 > base coz that's much easier to maintain] the cvs would be structured as= =20 > follow : >=20 > CVSROOT/* : >=20 > CVSROOT/fr : fr module > CVSROOT/es : es module > CVSROOT/base : base module >=20 > ie when you, the developer (documentation maintainer), have a=20 > modification to do to the base : >=20 > cvs co base > [modifications] > cvs commit >=20 > or when we will be translating doc : >=20 > cvs [co/update] fr > cvs commit >=20 > > can a module (ie the base) be automatically retrieved when getting > > one of the languages modules ? > > if so, i buy ;-) >=20 > we can but we don't f****** care about it !! mmm > the building process is a different work than translation, then i see n= o=20 > reason for wich we shouldn't make another module :) >=20 > if you're thinking as an enduser then what's possible for CVS is that : >=20 > cvs co base > cd base > cvs co fr >=20 > (note it would depend on our building process) that's the whole point, we can therefore not rely on relatives paths > > Wouldn't module splitting require having two (or 3 with 2 languages) > > base directories for each (on local side) ? >=20 > that's even the definition of a cvs module :) >=20 >=20 > I hope we will be able to find a solution for this building process. >=20 > To my mind we need cvs modules. Or we're gonna die under an horrible=20 > garbage 3 days after having committed our changes :) where would the garbage come from ? do you mean from potential mistake or what ? |
From: Vincent K. <vi...@ie...> - 2003-12-18 19:18:38
|
Le jeu 18/12/2003 =E0 19:06, Arthur Huillet a =E9crit : > Vincent Knecht wrote: > > Le jeu 18/12/2003 =E0 17:50, Arthur Huillet a =E9crit : > >=20 > >=20 > >=20 > > for me there's no problem if you don't want to "downgrade" > he'll see himself, but i'm sure he won't bare that for a long time :) Pablo, please let us know what you think about the CS version to translate > >=20 > >=20 > > if we work on different versions, i'm not sure a common package is a > > good idea. >=20 > this is another problem than the one i'm discussing below, that's=20 > another reason for wich i'd rather support having the same version > anyway, a version-independant and language-independant building process= =20 > is something possible, right ? :) if it's possible, okay at least for now building our 0.96 french manual using 0.97 original files when translated one doesnt exists seem to produce good output (don't have checked precisely); at least no no-go error So there's hope to achieve this :-) We should check if build process changed by diffing CS involved makefiles/jamfiles >=20 > > even if we work on the same version, there would be just a few > > duplicated files ( mainly .def and .tex) here i just forgot to mention texi2html & texi2html.init, which we took out of CS CVS (needed for french terms, for toc headers as well as navigation panel & others) Pablo, maybe you'll want to add spanish terms in these two files ? > > unless we want to share screenshots and images (this could annoy us > > if we wanted to get localised screenshots), i'm not much for making > > one additional package, that all people would need to build the manua= l, > > but surely a very few who'd build two or more language pack... > >=20 > well the other solution is to make a full package for each release,=20 > containing the base plus the language pack > for development though i'm for using differents modules for base and=20 > languages. > I'd like us to take a decision rapidly about CVS :) can you describe us how the retrieving and updating would differ ? can a module (ie the base) be automatically retrieved when getting one of the languages modules ? if so, i buy ;-) Wouldn't module splitting require having two (or 3 with 2 languages) base directories for each (on local side) ? > the third solution i don't like very much, is to do what we want to=20 > build, ie pablo could decide to modify original makefiles while we=20 > decide to use our own...if we have a central project (crystaldoc) i=20 > think there's a reason for that, then i don't support a non-universal=20 > solution for building. please make your tests and let us know if it's possible... as pointed above, maybe there's no problem to do that Vincent |