Packaging status
by Paul W. Frields
I have the package building working again to coincide with the change in
CVS organization. I don't think I've increased the fragility any, but
I'd appreciate input of course. I tagged the module files as
'pre-package2' before I commited any changes, and 'package2' afterward,
so it should be easy to revert if something is so borked or ugly that we
can't live with it. (I'm thinking only of a "learn from my mistakes"
standpoint there, but there may be value for other people too, I guess.)
Comments and issues welcome... exspecially if you file them in Bugzilla
under Fedora Documentation, docs-common module. (Karsten is the owner
of this bug, but Tommy and I get cc'd on them automatically so you can
be sure we'll see your issue.)
--
Paul W. Frields, RHCE http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
Fedora Documentation Project: http://fedora.redhat.com/projects/docs/
18 years, 2 months
Installation Guide Status
by Stuart Ellis
Just to note that we are not likely to have a complete Guide in time for
the scheduled trans freeze tomorrow. The text may not match current
(i.e. rawhide/test3) package selection screens. I'm also working on the
screenshots.
--
Stuart Ellis
stuart(a)elsn.org
Fedora Documentation Project: http://fedora.redhat.com/projects/docs/
GPG key ID: 7098ABEA
GPG key fingerprint: 68B0 E291 FB19 C845 E60E 9569 292E E365 7098 ABEA
18 years, 2 months
fedora-doc-common RPM specfile
by Paul W. Frields
I believe some changes are in order for the fedora-doc-common package.
Rather than having this package "roll" forever with a "cvsYYYYMMDD"
designator, I think it will be preferable, both for us and Fedora
Extras, to simply version/release tag the specfile, per normal, and "cvs
tag" the docs-common module with that version/release combo. If you
want to see the current state of the file, look at this URL:
http://cvs.fedora.redhat.com/viewcvs/docs-common/packaging/fedora-doc-com...
Currently the %version and %release are provided by the Makefile:
http://cvs.fedora.redhat.com/viewcvs/docs-common/Makefile?viewcvs=docs&vi...
...but this seems less than optimal, as well as possibly counter to some
normal Fedora Extras policies and practices. In the interest of getting
this package entered (since all other fedora-doc-* packages will depend
thereupon), I want the spec to look as "clean" as possible to a FE
reviewer. By using a real version/release, appending the changelog per
normal, committing any changes and retagging the docs-common module
appropriately, we should have all the recall we need for QA purposes.
Note that using an "rpm-info.xml" file in this case is probably not
workable since the fedora-doc-common module doesn't build the same way
as any of the documentation. Also note that changes to this package
will probably only be made by a few individuals, making the "exception"
of negligible impact on the overall FDP.
I've invited Ignacio Vazquez-Abrams, one of FE's staff of reviewers, to
look at (and comment on) the specfile, simply because he has been kind
enough to review some of my packages for FE. (It's like a lottery, only
the prize is more beatings.)
Any or all comments are welcome and appreciated.
--
Paul W. Frields, RHCE http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
Fedora Documentation Project: http://fedora.redhat.com/projects/docs/
18 years, 2 months
[ANN] Mandatory new directory structure
by Tommy Reynolds
Hello, Doc'ers!
In order to better support the translation effort, we need to
reorganize the required directory structure a bit, to better parallel
the current translation group practices.
The idea is to place the XML files for each language into a separate
subdirectory. For instance, the "example-tutorial" document as the
following structure:
$ ls -CF
CVS/ Makefile de/ en/
$ ls -CF en
CVS/ example-tutorial-en.xml para-en.xml rpm-info-en.xml
Each document owner should do this:
1) Create a separate directory for each language supported by the
XML. Use the "en" locale for the English translation, for now,
even though that isn't a real locale.
2) Add the per-language subdirectories to CVS
3) Copy the *-${LANG}.xml files into the ${LANG}/ subdirectory.
4) Add the ${LANG}/*.xml files to CVS
5) Drop the top-level XML files once you've moved them like this:
$ cvs rm -f *-${LANG}.xml
6) Commit your changes.
The shell script "docs-common/bin/migrate-lang" will do steps 1-4 for
you and commit your additions. For safety's sake, it does NOT delete
your top-level XML files as shown in step #5: do that yourself when
the subdirs are correct.
Use the script like this:
$ cd example-tutorial
$ ../docs-common/bin/migrate-lang | sh
I.E., the "migrate-lang" script outputs the actual shell commands
needed to do the work, but you must pipe those commands into another
shell to actually change anything.
HTH
18 years, 2 months
[Fwd: CVSROOT cvsignore,1.2,1.3]
by Karsten Wade
-------- Forwarded Message --------
From: Tommy Reynolds <jtr(a)fedoraproject.org>
To: cvsdocs-administrators(a)fedora.redhat.com
> Log Message:
> Never archive ".po" files because they are ALWAYS a local work in
> progress.
Unless you are running a translation CVS.
We may need to reconsider this idea, because we are going to continue to
host the translations of Fedora documentation.
So, doesn't this mean we need to be canonical for the .po files?
release-notes/en/*-en.xml
release-notes/en/po/*.po
- Karsten
--
Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/
gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41
Content Services Fedora Documentation Project
http://www.redhat.com/docs http://fedoraproject.org/wiki/DocsProject
18 years, 2 months
docs and trans IRC log 02-Feb-2006 22:30 UTC 00:00 UTC
by Karsten Wade
<meeting>
<quaid> ok, ready
<barz> aalam, quaid: so, just 2 kickstart our chat...we need 2 make FC5
press release and release notes available for community translation
<quaid> ok, press release first
<quaid> "By Press Release, do you mean formal communication from the
Fedora
<quaid> Foundation?"
<barz> yep
<quaid> ok
<barz> gdk and ambassadors steering committee are working on a poress
release
<quaid> we have three locations where trans is going on
<quaid> ah, good
<quaid> 1. i18n.r.c
<quaid> 2. cvs.fedora:/cvs/docs
<quaid> 2. fedoraproject.o/wiki
<quaid> s/2. fed/3. fed/
<barz> quaid: do u have access to create directories in FC CVS
repository? dunno exactly how it works...
<quaid> we can fold 2. into 1. when trans CVS _and_ Web apps can move
from elvis.r.c => cvs.fedora.r.c
<quaid> yes
<quaid> are you aware of the trans going on right now?
<quaid> http://webtest.fedora.redhat.com/docs/translation-quick-start/
<quaid> for example
<barz> what docs are we talking about?
<quaid> pt_BR was just posted this morning
<quaid> http://webtest.fedora.redhat.com/docs/RELEASE-NOTES/
<quaid> these are the HEAD of CVS
<quaid> we also have:
<barz> in what format?
<quaid> http://fedora.redhat.com/docs/release-notes/
<quaid> source is XML in CVS
<quaid> translators are working directly in CVS using xml2po and po2xml
<quaid> very archaic and manual
<quaid> but they are heroes, getting the job done
<barz> quaid: that's exactly my point. we can facilitate these
<quaid> after test3 releases, we are reworking our CVS directory
structure to put languages in sub-folders
<quaid> the Makefile all builds all languages
<quaid> so we can keep the actual translated XML ongoing
<quaid> but
<barz> do translators still have to change the makefiles?
<quaid> yes
<quaid> we can automate that
<barz> do u like that?
<quaid> no
<barz> exactly!
<quaid> I want i18n.r.c
<quaid> this is what I understand:
<quaid> we cannot move until elvis.r.c => cvs.fedora.r.c is complete
<quaid> Sopwith and other community infrastructure people are willing to
help
<quaid> but Bernd knows all and needs time to explain
<quaid> once the CVS move is done
<quaid> hooking us in should be easy
<barz> cool! but i believe we can already offer these files in .po
format. aalam: is that right?
<barz> as far as I'm concerned, bernd won't have the time 2 do so at the
moment
<aalam> yes we can
<quaid> would it be helpful if bernd joined us?
<quaid> to talk?
<aalam> quaid, surely yes
<quaid> one sec
<barz> I'm just tryin to get people together here and hopefully offer
the community the .po files
<quaid> exactly
<quaid> if bernd or someone can hook into our CVS and make it avail
through i18n.r.c, great!
<quaid> we're ready, willing, able, etc.
<barz> so, aalam, can u pls explain what u got in mind...
--> bgroh (n=bgroh(a)59.167.110.134) has joined #fedora-docs
<barz> bgroh: g'day doctor!
<quaid> g'day, bgroh, thanks
<bgroh> barz, good day
<aalam> barz, quaid there are very few translators in Fedora-docs
project,
* quaid goes to grab some lines from his buffer
<quaid> aalam: true
<quaid> about six? ten?
<aalam> can we not able to give access to Fedora-GUI Translators?
<barz> bgroh: we wanna offer press release and release notes .po files
for community trans
<bgroh> ok
<quaid> bgroh: ok, I pasted the relevant chat buffer back to you on
#docs, to not break the flow here
<quaid> that is our understanding
<bgroh> quaid, ok, got it
<quaid> can we get .po files out of MoinMoin instead?
<bgroh> basically, we'd need someone or a team around an admin to take
over the status page/job claim page infrastructure
<quaid> the Infrastructure group could conceivably do that
<quaid> Sopwith is leading that, aiui, and it has community members on
it as well
<quaid> we'd have to ask them, of course :)
* quaid looks at nman64
<bgroh> then they could work with the admin group to get it ready for
and installed on fedora.cvs and migrate
<bgroh> and everything else would follow
<quaid> bgroh: so, it is a good thing that we have a robust i18n built
into the Fedora Docs Makefile and common files?
<quaid> i.e., you can use that
<bgroh> should be
<bgroh> all we need is the xml->pot and po->xml part, or?
<quaid> aalam: btw, some of the translatros that came to Fedora Docs did
not come from/through Fedora Trans, so they are going to be newbies
<quaid> bgroh: is that in the Makefile usually?
<aalam> quaid, yes
<quaid> otherwise, yes, that would be all you need on the Web app side
<bgroh> yes, that would go into the makefile
<quaid> ok
<quaid> if you can point me at an example? I'll file a bug and get
Tommy/Paul to work up a solution.
--- Bob-Laptop-Away is now known as Bob-Laptop
<bgroh> we'd have a make update to generate the newest po files
<bgroh> and when it's time, the make <target> used the po files, instead
of some xml
>Bob-Laptop< *psst* we're slipping release by a week, the caballistic
are trying to work up an estimate, should be announcing tomorrow ...
'splains some of why I stalled this week :)
<quaid> we have been doing some stuff to try to make the XML diff sane
<bgroh> it's not too difficult, just wasn't something that was worth it
setting up on elvis
<quaid> 1. we can run xmlformat with a custom configuration against the
CVS module as the content is being checked in, before it hits the
repository
<quaid> this solves lots of local $EDITOR differences
<barz> bgroh, quaid: do u have a timeline for the migration project?
will it happen before FC5 launch?
<quaid> but we haven't tried that with any translation
<bgroh> would we want to put xml into the repo though?
<quaid> barz: probably not
<quaid> bgroh: oh, in the /cvs/i18n repo?
<quaid> no, I guess not
<bgroh> barz, I don't have a timeline, I'm simply ready to hand it
off ;)
<-- yeliaB[] has quit ("Leaving")
<quaid> +1
<quaid> bgroh: I want to find a way to take the burden from you :)
<quaid> bgroh: I'm thinking about the line diffs that were a problem
with SGML
<barz> quaid, bgroh, aalam: can we have a workaround for FC5, then we
make big noise translating the presse release to several different
languages?
<bgroh> quaid, just take it, it's on bob, module perl-i18n, see elvis
for setup guidelines :)
<quaid> we're trying out some of the xmldiff tools, as well, just for
our own diffing.
<quaid> bgroh: well, I can't shoulder the burden myself :) ... but I'll
try to get someone else to :)
<quaid> barz: yes
<barz> cool!
<quaid> nman64: do you know if MoinMoin can output .po files?
<quaid> are they are hard format to hack, the .po file?
* quaid doesn't think he's seen the inside of one.
<bgroh> btw, moin
--> snowlet (n=snowlet(a)60-240-151-239.tpgi.com.au) has joined #fedora-
docs
<quaid> g'day snowlet
<snowlet> quaid, morning
<barz> snowlet: morning!
<snowlet> morning, barz
<bgroh> moin zam'n!
<barz> ?
<bgroh> good morning everyone!
<quaid> bgroh: I'm wondering about MoinMoin because it runs
fedoraproject.org/wiki and they could author the press releases in an
ACL restricted area, and we could spit them out and suck them back in
somehow
<snowlet> sorry I'm late
<quaid> otherwise, we'd have to generate .po files from ... XML?
<bgroh> quaid, that ok too though, that's what we do with RHEL
<quaid> snowlet: I'm going to /msg you to give you the discussion so far
from my IRC buffer, ok? just reply when I do the /msg
<quaid> well the thing is
<bgroh> quaid, maybe they can spit out xliff?
<quaid> we don't have a Press Release stylesheet
<bgroh> oh, I see
<quaid> and DocBook does not a pretty press release make
<quaid> wonder if we can get .po into and out of OO.org
<barz> hang on! press release is a small doc, and aalam easily converted
it into .po yesterday
<quaid> ok
<quaid> from what source format? plain text?
<barz> we just tested with an old PR I had
<quaid> text2po?
<barz> yep
<quaid> ok, that's fine
<snowlet> quaid, sure
<quaid> we'll just do nice, structured text
<barz> oh dunno, aalam: what tool did u use
>snowlet< just type something back, and X-Chat will open a tab on my
side
<aalam> I save *.sxw document into *xml format with openoffice
<quaid> ah, ic
<quaid> yeah, I was thinking of .sxw -> .po directly, since .sxw == a
tarball of XML and directories
<quaid> ok, so we can do it manually for the first few times
<quaid> 1. SXW file is finalized by gregdek et al
<quaid> 2. Hands it to FDP for edits, etc.
--- BobJensen-Away is now known as BobJensen
<quaid> 3. FDP creates XML and puts it into CVS
<quaid> 3.1 FDP creates .po files and puts them into CVS
<quaid> or something
<barz> then we need to convert it back to text...
<barz> and make it available to ambassadors
<barz> to spread the word
<quaid> a press release doesn't need SXW
<quaid> it should be ASCII
<quaid> just nice whitespace usage and good blocking
<quaid> that's how they go out to businesswire from RHAT
<quaid> a wire service was traditionally a teletype machine of some
kind, right? plain text was the rule :)
<barz> quaid: ur plan sounds good, just the edits will be done by the
FAMSCO
<barz> then FAMSCO hands it to FDP translations
<barz> or infrastructure to make them available in .po before
<quaid> bgroh: can we easily go text <==> po
<quaid> docs has edit approval, that's all
<quaid> if we find a problem, we suggest a fix :)
<barz> sure!
<barz> understood
<bgroh> quaid, hmm, I suppose, depends on how strict the text format is
<barz> u can give us guidelines on the format that will suit the
procedure
<quaid> /cvs/docs/press-releases/xy/famsco-YYYY-MMM-DD-xy.txt
<quaid> where xy == two-letter country code
<quaid> we haven't settled on how we're doing the sub-directories
<quaid> but I just realized that would mean we should put en/ in it's
own directory
<quaid> each with their own Makefile, etc.
<bgroh> quaid, you can do whatever you want, as long as you tell me what
format, and it's strict, we can do
<quaid> yeek
<quaid> bgroh: I was thinking of standard structured text
<bgroh> should be fine
* quaid grabs a poor example
<quaid> http://people.redhat.com/kwade/fedora-docs/selinux-faq-
en-1.3-8.txt
<quaid> that was docbook2txt, iirc
<quaid> but the idea is the same
<bgroh> hmmm, we'd have to decide how we split the text
<bgroh> as in write a converter
<bgroh> you'd certainly not want to split by newline only
<quaid> yeah, I don't seem to see anything written already, either
<barz> paragraph, maybe...
<barz> line break...
<bgroh> neither will be good for bullet lists
<quaid> tell them no bullet lists? :)
<bgroh> haha
<quaid> I don't want to have to make up a new tool
<bgroh> if we can go newline, it's easy
<barz> is newline same as line break?
<barz> like when u press enter. sorry for my ignorance
<bgroh> refers to the same
<bgroh> but looking at the text, newline wouldn't make for a nice po
file
<barz> so should work as a paragrapgh then?
<bgroh> or paragraph wouldn't make for a nice po file
<barz> but a paragrapgh of a press release looks like a good .po file
entry
<bgroh> quaid, but you do compile form xml at the moment, or?
<bgroh> s/form/from/
<quaid> bgroh: normally, yes
<quaid> the press releases are vapor right now, so we can have them
written in whatever format.
<bgroh> quaid, can't we go xml->pot po->xml then?
<quaid> and we can output XML from SXW, then go xml -> po, po -> xml,
and xml -> sxw, it will probably work :)
<quaid> which xml is the only question
<bgroh> docbook?
<quaid> back to the stylesheets
<bgroh> yeh, true
<quaid> docbook makes for ugly press releases
<bgroh> but for good release-notes
* quaid needs an XSL superstar in FDP
<quaid> very nice release notes,yes
<bgroh> maybe use xml for release-notes, and see what to do with press
releases?
<bgroh> as in really really think about it
<quaid> yeah, the relnotes translation is a no brainer, it's happening
already
<quaid> yes, think about it
<quaid> we'll take it to f-docs-l perhaps
<quaid> barz: ok, I'm going to start a discussion on fedora-docs-list
about press-release formats for translation
<quaid> barz: yes, thanks, I much appreciate the schedule-eye-view
* quaid sets a watch on that page
<quaid> those of you who understand .po files and translation
<quaid> please watch the discussion thread on f-docs-list
<barz> quaid: that's gr8! thx!
<barz> ok
<barz> quaid: just 2 make things clear. r u the one leading this? of
course, you can always count on us
<quaid> well
<quaid> our purvie ==
<quaid> purview
<quaid> moving content from contributor to reader through the
translation process
<quaid> so we own formats of documents, the CVS repository for
documents, and conceptually every single document on the system
<quaid> ideally, we should be a step in the process of string freeze
<quaid> so we edit the strings for clarity and translatability in
English, then pass on for trans, etc.
<quaid> anyway
<quaid> that's what I'm focusing on
<quaid> file format, approving contributions (the FAMSCO press release),
and moving into and out of translation
<quaid> what you guys do works really well, obviously
<barz> yep, i'm leading the FC5 Launch promotions, and will work 2gether
with aalam and snowlet with communicating with trans list
<quaid> we want to plug in to you in smart ways, learning and gaining
from each other by that.
<quaid> awesome
* quaid <-- Californian in his idioms
<barz> lol...so i suggest outlining the process in the wiki, then link
it to the Media Plan. sounds reasonable?
<aalam> quaid, barz Just for conformation"how will translator work for
Press-R translation" thro' *- docs project, ture?
--> yeliaB (n=ed(a)adsl-065-005-194-118.sip.rdu.bellsouth.net) has joined
#fedora-docs
<quaid> we haven't decided that, I guess
<quaid> aalam: we can make .po files available ... in our CVS
structure ... or maybe just as a build target that you can (manually for
now?) pull into i18n.r.c?
<quaid> if you want a .po file for the release-notes as well, we can
give that over, too
<quaid> we plan on doing changes to our i18n between test3 and fc5
<quaid> but maybe we can squeeze it in sooner, if it's important
<quaid> we may miraculously have time
<quaid> what that gives us is:
<quaid> * .po make target
<quaid> * directory structure /cvs/docs/release-notes/xy/
<barz> considering the multiplied noise we can make with translations I
guees it's very important
<quaid> I mean, you could host a matching tree ... or even sync just
that tree?
<quaid> just for this release?
<quaid> bgroh: I haven't wanted to ask that, but it is possible to do,
you could pull the content anonymously and we could pull the sync back
the same way? or what is the right way?
<quaid> some kind of CVS sync to tide us over ...
<quaid> s/tide us over/keep us working until we can migrate CVS/
<barz> I guess bgroh got tied up with something else
<barz> quaid: any suggestions on how we can progress from here?
<bgroh> quaid, would have to think about what you were saying, but if it
gets too technical, I may not be the right person to ask.
<bgroh> I'm a very bad sys admin :(
<quaid> :)
<barz> bgroh: when do u reckon u can give us some updates?
<quaid> if we don't mind breaking the history of the files ... or making
them unlinked for a while ...
<bgroh> barz, updates on what?
<barz> bgroh: weel, u said u gotta think about it...
<bgroh> barz, when I get some time :)
<bgroh> basically, if it's development stuff, it's easily done, if it
has anything to do with sys admin stuff, I'm useless
<quaid> bgroh: where would I find a Makefile that does xml2pot and
po2xml? the RHEL ones?
<bgroh> quaid, yes
<quaid> do you keep the .po files in local CVS?
<bgroh> quaid, yes, we do
<quaid> is there any reason you couldn't do something similar to this:
<bgroh> l10n xml is only transition during build
<quaid> CVSROOT=cvs.fedora:/cvs/docs (short version)
<quaid> sorry
<quaid> just check out a local copy of the .po files from
the /cvs/docs ?
<quaid> and point the i18n workbench at it?
<quaid> this is all just until we can fix it right ... but ... we could
then have a person go locally and use a CVS account to check all the .po
files back into cvs.fedora:/cvs/docs/release-notes/xy/po-files/
<bgroh> could be possible in theory, but I'd think there'd be some
things to do still
<quaid> even do it unattended, using phraseless sshkeys
<bgroh> I doubt we could use our RHEL infrastructure for Fedora
<bgroh> reason being that it's customized for our build sys
<quaid> barz, aalam, snowlet: this is where I have to hand the resource
request back to you
<quaid> oh, sure
<quaid> I mean the Fedora infrastructure
<bgroh> for example, there are some global workarounds that apply to the
software installed on our build machine and apply to our langs
<quaid> barz, aalam, snowlet: you need to find someone who can do system
administration tasks with the various web applications and work to hook
this in ... it could be Sopwith (Elliot Lee), nman64, and the rest of
the Infrastructure/Web teams
<bgroh> hmmm, maybe I need to take some time later to clearly think
about what you've said
<quaid> bgroh: ok
<quaid> all: I am going to post a slightly edited version of this IRC
log to fedora-docs-list
<quaid> for our reference, as well as the other people we are asking to
think about these things with us
<barz> quaid: gr8!
<barz> all: can we wrap this meeting up?
<barz> 5....
<barz> 4...
<barz> 3...
<barz> 2...
<barz> 1...
<aalam> barz, quaid, I did not get
<Bob-Laptop> Happy New Year!!!
<barz> hehehe
<aalam> how translator can work?
<barz> aalam: quaid will send an email to f-docs list explaining the
idea for discussion
<aalam> which account will they use?
<aalam> Fedora-GUI or docs?
<aalam> those are my questions:)
<snowlet> barz, Fedora-GUI would be better. translators are there
<quaid> 1. we need to give bgroh a chance to thinkk about it
<quaid> 2. you three need to see if you can find some technical help to
take over the i18n.r.c from bgroh
<quaid> I will help you with 2.
<quaid> from those will come our next steps
<quaid> we _want_ .po files on i18n.r.c and available through Fedora-GUI
<quaid> for press release and release notes
<quaid> but it may take some hacks or someone taking over the migration
and making it happen in the next few weeks
<quaid> we need to raise this to gregdek's attention
<quaid> if we need help getting resources
<barz> quaid: maybe u can copy FAMSCO list on ur email
<quaid> snowlet, aalam: does that answer your questions for now?
<quaid> barz: it's moderated, but I'll put it on the Cc:
<aalam> quaid, no more! thanks for explaining again
<quaid> still, this email is about press release format
<barz> quaid, ok. i'll also update the media plan accordingly so pp know
what's goin on
<quaid> to get resources, you need to contact sopwith(a)redhat.com, and/or
file bugzilla requests against Fedora Infrastructure
<barz> what kinda resources?
<snowlet> quaid, yes
<quaid> barz: infrastructure resources.
<barz> ok
<quaid> barz: who can i) move CVS, ii) take over Web apps, etc.
<barz> I thought that maybe we had all resources in this meeting
<barz> quaid, bgroh: but u guys know it better
<quaid> barz: technical resources, which of us can solve those problems?
<quaid> Perl programmers, CVS gurus, etc.
<quaid> not i :D
* Bob-Laptop looks for a BIG rock to hide behind
<barz> quaid: ok, got it
<barz> all: can we pls close this meeting?
<bgroh> and not I (depsite being a perl programmer)
<barz> almost 2hs now
<aalam> barz, yes
<aalam> :)
<snowlet> sure~<barz> quaid: we'll leave the next steps to you then -
email to f-docs, resources gathering... is that ok?
<snowlet> does anyone know how to save this log?
<barz> window -> save text
<snowlet> barz, eagle eyes~ :)
<aalam> snowlet, u can keep automatic logging Setting->Pref->Chatting-
>Logging (Enable)
<barz> alright guys, i'll get goin. thx 4 all ur support! really hope we
can make it. FC5 will be a big splash!
<barz> all over the world!
<BobJensen> that can take up a fair amount of disk space when you are in
10 Channels 24/7
<snowlet> aalam, thanks. that would be super helpful
<barz> see you all!
<BobJensen> Bye barz
<barz> see you, BobJensen!
<-- barz has quit ("fui!")
<quaid> punk
<quaid> he still thinks I'm doing resources gathering
<quaid> :P
</meeting>
18 years, 2 months
Self-Introduction: Steven Pierce
by Steven Pierce
1.
Steven Pierce
-
Huntington Beach USA (Pacific Time Zone)
-
Currently working for the Dept. Of homeland Security (TSA) Also have a
second job doing consulting for a small company here in Huntington Beach
-
See above
-
Your goals in the Fedora Project
-
What do you want to write about?
I am very open to this topic. I am trying to learn more about
linux. I am currently in the process of trying to
set up a web, mail, dns server so that I can expand my skill
set.
-
What other documentation do you want to see published?
None currently, but I have done a couple of FAQ for my employers
(Past / Present)
-
Do you want to edit for grammar/writing and/or technical
accuracy?
I would be open to either. grammer / writing is how I
discovered the project
Thanx to Paul Fields.
-
Anything else special?
-
Historical qualifications
-
What other projects or writing have you worked on in the past?
I have done a master's thesis and a couple FAQ's.
-
What level and type of computer skills do you have?
I am not a novice, but I am not guru either. I put my skills in
the more
advanced level. I can set up most types of machine, I have
built my own
machines. I have set up a couple of servers with RH 9.
-
What other skills do you have that might be applicable? User
interface design, other so-called soft skills (people skills),
programming,
etc.
I have a fair amount of people skills, I have done tech support
for a long time. I am currently learning more about
HTML / CSS. I am hoping to take a couple java script classes in
the future.
-
What makes you an excellent match for the project?
My willingness to learn.
18 years, 2 months
do not (yet) use translated legal notices
by Karsten Wade
Translators:
In your file docs-common/common/fedora-entites-{lang}.ent, please set
this entity to point at the -en legal notice:
<!ENTITY LEGALNOTICE-CONTENT SYSTEM "./legalnotice-content-en.xml">
This is the actual content. To translate it, we need the translations
approved by a lawyer. Probably for each translation, and the lawyer
needs to be fluent in the language to approve it.
Alternately, we could get some text from a lawyer that says, "This is a
translation of the English license that may or may not pertain to your
country and laws. It is therefore not a legal license in all
jurisdictions." The we translate that.
Meanwhile, please use the only legally approved legal notice for all of
our documentation.
Save the translations of the legal notice, hopefully we need them Real
Soon.
- Karsten
--
Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/
gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41
Content Services Fedora Documentation Project
http://www.redhat.com/docs http://fedoraproject.org/wiki/DocsProject
18 years, 2 months
