-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Marco, Am 12.06.2008 um 20:09 schrieb Marco Ciampa: > On Thu, Jun 12, 2008 at 03:39:33PM +0200, julien wrote: >> Hi, >> [...] >> Is it easy to find what has changed in the Wiki? >> > So, Joan, Julien and me are all convicted that a wikipedia > approach it not without (big) drawbacks. For my understanding Joao makes some very valuable suggestions on the question "how to ensure a stable structure for the manual" Limiting access to the documents that are relevant for the structure is only one of them. But for me this discussion is not about who is on which side in the first place. It is more about seeing the drawbacks of each scenario and I have some very very serious concerns about the gettext scenario. First of all we have two problems that are related to each other: - - we do lack of a engaged community (do you agree?) - - we specially do not have any native english author for english (right?) So, how would the gettext scenario affect this? As I see it, for the translators does the "work" get easier, but also a lot less creative. This is IMHO not much of a chance to attract new authors. What about the engaged creative that want's to share his knowledge but happens to be not good enough in english to write in this "master" language??? Even worse is the other side. What we need more urgent than anything else is authors for the so called master language: english. But just for that class of people the gettext scenario does not only get things not easier to write, but with the gettext technology a NEW layer of technology would be added. I don't see how this can work. With the gettext scenario I see half a dozen very good translators, but no forthcoming for the GIMP help at all. Are I painting to black? Did I miss something in here?? > > > The use of the gettext tool with all the .po/.pot file format > conversion is > meant mainly to enable: > > - automatic revision control: easily find(!!) and update(!) updated > strings > - use of specialist translation editors > (poedit/kbabel/gtranslator/emacs/etc.) > - even tools with web interface ready like rosetta > (wich enable group revision and commit supervision...) > or pottle: see -> http://translate.sourceforge.net/wiki/ this is _all_ about technique, but currently we do not have a lack on the technology front, we do lack better content right? And again, you're focusing on the translator side, how about the primary manual writing?? > > > this is _much_ more than wiki! Hmm... Greetings, lexA P.S: are there somewhere some example pages yet? How do the language dependant images work in your scenario? I'd really like to get an idea about what editing and translating would look like? The translators would still have to do docbook xml, right? I mean can somebody (may be you) just prepare one file, lets say a typical dialog or filter description as an example? > > > -- > > Marco Ciampa > > +--------------------+ > | Linux User #78271 | > | FSFE fellow #364 | > +--------------------+ > _______________________________________________ > Gimp-docs mailing list > Gimp-docs@xxxxxxxxxxxxxxxxxxxxxx > https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-docs - --- /voodoo.css #meinFeind {position: absolute; bottom: -6ft;} -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iD8DBQFIUY8HR9mXLVsAbiQRAlzNAJ961n68plQzhbxgBS6pMpoZNOyZlgCg4hay lvQz/o9gQR3QBlQ01F0rmio= =l2cy -----END PGP SIGNATURE----- _______________________________________________ Gimp-docs mailing list Gimp-docs@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-docs
