docs August 2009

docs@lists.fedoraproject.org

40 participants
83 discussions

CC-BY-SA and moral rights provision
by Richard Fontana 14 Aug '09

14 Aug '09

Hi, Sorry to reopen an issue that was supposed to be resolved. When we were discussing whether to go with CC-BY-SA unported or CC-BY-SA US, there was an issue I had overlooked. The unported version of CC-BY-SA 3.0 has a provision, 4d, concerning 'moral rights' that has been the subject of some controversy in the CC community: Except as otherwise agreed in writing by the Licensor or as may be otherwise permitted by applicable law, if You Reproduce, Distribute or Publicly Perform the Work either by itself or as part of any Adaptations or Collections, You must not distort, mutilate, modify or take other derogatory action in relation to the Work which would be prejudicial to the Original Author's honor or reputation. Quick background: many copyright law regimes recognize something called 'moral rights' of authors that are distinct from the 'economic rights' we ordinarily associate with copyright. These are generally unassignable rights (you can't sell them) and in some countries you can't waive them. In the US, oversimplifying a bit, moral rights are generally assumed not to exist for most kinds of copyrightable works other than visual works, but moral rights are important in many other countries, particularly in Europe. I believe the intent of CC-BY-SA 3.0 unported 4d was just to say that, for copyright regimes that recognize moral rights, CC-BY-SA does not affect them in any way. Larry Lessig pointed this out in a blog posting which currently eludes me. However, there is an argument that the provision, as worded, suggests that even where the copyright law regime does not recognize moral rights, the license is effectively importing them in. This provision was, FWIU, not in earlier unported versions of CC-BY-SA, and it is not in the US version of CC-BY-SA 3.0. I understand that there is some effort to clarify this provision in future revisions of CC-BY-SA. Note that moral rights (which in many countries that recognize them apply to software as well as to other kinds of works) are at tension with the FOSS norms that are the heart of Fedora legal policies and which encourage modification even if it might be 'prejudicial' to the author. Most FOSS licenses (which admittedly tend to be drafted by Americans) tend to assume they don't exist. Fedora documentation, though written by many authors, many of whom are unaffiliated with Red Hat, is technically being licensed out downstream by Red Hat, the licensee named in the Fedora CLA. I would assume that 4d would not apply to the extent that applicable underlying law is US law. However, I suppose there is some doubt about this. In the US any moral rights (or similar rights that might be captured by 4d) that do exist are almost certain to be waivable, though there may be some doubt about that too. Anyway, I would not want Red Hat, as licensor of Fedora documentation, to stand behind 4d, as a matter of principle, even if it has no actual applicability. One solution would be to go with CC-BY-SA 3.O US, which omits the moral rights provision entirely. Alternatively, however, we could continue with using CC-BY-SA 3.0 unported and revise the Publican licensing notice to say the following: Copyright © 2009 Red Hat, Inc. and others. This document is licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of this license is available at http://creativecommons.org/licenses/by-sa/3.0/. The original authors of this document, and Red Hat, designate the Fedora Project as the "Attribution Party" for purposes of CC-BY-SA. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version. Red Hat, as the licensor of this document, waives and agrees not to assert the right to enforce Section 4d of CC-BY-SA to the fullest extent permitted by applicable law. That extra language doesn't actually extinguish any moral rights claims that Fedora contributors might have, for better or worse; I think it just has the effect of making clear that the CC license won't be used by Red Hat as a separate mechanism to enforce such moral rights. - Richard

2 2

Vacation reply
by girish.hb＠hotmail.com 14 Aug '09

14 Aug '09

1 0

Alpha Announcement
by Eric Christensen 13 Aug '09

13 Aug '09

I've taken the Alpha announcement from F10 and morphed it[1] for F12. Please take a look at it and see what you can update. This should be completed by COB tomorrow (Friday). [1] https://fedoraproject.org/wiki/Releases/Announcement_for_F12_Alpha_Release --Eric

3 5

Release Notes Meeting 2009-08-13 Summary
by Eric Christensen 13 Aug '09

13 Aug '09

======================================== #fedora-meeting-1: Release Notes Meeting ======================================== Meeting started by Sparks at 15:03:13 UTC. The `full logs`_ are available. .. _`full logs`: fedora-meeting-1.2009-08-13-15.03.log.html Meeting log ----------- * *LINK*: http://www.redhat.com/archives/fedora-docs-list/2009-August/msg00072.html (Sparks-15:05:32_) * *ACTION*: jjmcd to follow up with lynx maintainer about homepage (Sparks-15:07:01_) * *ACTION*: jjmcd to contact #f-devel-l about deprecating homepage (Sparks-15:07:20_) * *LINK*: http://www.mi-nts.org/sl/DocMenu3.png (jjmcd-15:08:18_) * *ACTION*: Sparks to follow up with mhideo about how RHEL handles multiple languages of Publican docs. (Sparks-15:09:51_) * *IDEA*: Install all languages and have Yelp figure out what language to display based on logged in language. (Sparks-15:13:05_) * *IDEA*: Install all html and write a helper app (jjmcd-15:13:26_) * *ACTION*: jjmcd to file a bug against Yelp to fix revision history from a Publican file (Sparks-15:17:38_) * *LINK*: http://quality.kde.org/develop/howto/howtodocs.php <-- indicates KDE uses XML (stickster-15:27:12_) * *LINK*: http://kde.org/getinvolved/documentation/ (stickster-15:28:07_) * *LINK*: http://l10n.kde.org/docs/doc-primer/ (stickster-15:29:07_) * *LINK*: http://l10n.kde.org/docs//markup/index.html (Sparks-15:29:27_) * *LINK*: https://fedoraproject.org/wiki/Features/YumLangpackPlugin (stickster-15:47:41_) .. _Sparks-15:05:32: fedora-meeting-1.2009-08-13-15.03.log.html#l-9 .. _Sparks-15:07:01: fedora-meeting-1.2009-08-13-15.03.log.html#l-16 .. _Sparks-15:07:20: fedora-meeting-1.2009-08-13-15.03.log.html#l-18 .. _jjmcd-15:08:18: fedora-meeting-1.2009-08-13-15.03.log.html#l-23 .. _Sparks-15:09:51: fedora-meeting-1.2009-08-13-15.03.log.html#l-31 .. _Sparks-15:13:05: fedora-meeting-1.2009-08-13-15.03.log.html#l-39 .. _jjmcd-15:13:26: fedora-meeting-1.2009-08-13-15.03.log.html#l-40 .. _Sparks-15:17:38: fedora-meeting-1.2009-08-13-15.03.log.html#l-60 .. _stickster-15:27:12: fedora-meeting-1.2009-08-13-15.03.log.html#l-91 .. _stickster-15:28:07: fedora-meeting-1.2009-08-13-15.03.log.html#l-94 .. _stickster-15:29:07: fedora-meeting-1.2009-08-13-15.03.log.html#l-96 .. _Sparks-15:29:27: fedora-meeting-1.2009-08-13-15.03.log.html#l-99 .. _stickster-15:47:41: fedora-meeting-1.2009-08-13-15.03.log.html#l-166 Meeting ended at 16:09:44 UTC. Action Items ------------ * jjmcd to follow up with lynx maintainer about homepage * jjmcd to contact #f-devel-l about deprecating homepage * Sparks to follow up with mhideo about how RHEL handles multiple languages of Publican docs. * jjmcd to file a bug against Yelp to fix revision history from a Publican file Action Items, by person ----------------------- * jjmcd * jjmcd to follow up with lynx maintainer about homepage * jjmcd to contact #f-devel-l about deprecating homepage * jjmcd to file a bug against Yelp to fix revision history from a Publican file * Sparks * Sparks to follow up with mhideo about how RHEL handles multiple languages of Publican docs. * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * jjmcd (88) * Sparks (83) * stickster (45) * rudi (24) Generated by `MeetBot`_ .. _`MeetBot`: http://wiki.debian.org/MeetBot

1 0

Release Notes Meeting 2009-08-13 IRC log
by Eric Christensen 13 Aug '09

13 Aug '09

15:03:13 <Sparks> #startmeeting Release Notes Meeting 15:03:28 * Sparks 15:03:32 * stickster (somewhat here) 15:03:58 <jjmcd> Well, we already started the discussion we have to have today 15:04:48 <Sparks> Yeah... let's look at the old tasks and see what we still need to do and then continue that conversation 15:05:13 <Sparks> anyone else? 15:05:18 <jjmcd> where's the minutes? 15:05:20 <stickster> link to the old stuff? 15:05:32 <Sparks> http://www.redhat.com/archives/fedora-docs-list/2009-August/msg00072.html 15:05:53 <Sparks> I've been posting all the meeting information at the same place as the Docs Meetings 15:06:07 <Sparks> jjmcd to contact lynx developers about homepage 15:06:25 <jjmcd> OK, last week I emailed the lynx maintainer 15:06:30 <jjmcd> no response yet 15:06:45 <jjmcd> still didn't write f-dev-l, wanted the lynx maintainer to have a few days 15:06:54 <jjmcd> and email been borked past coupld 15:07:01 <Sparks> #action jjmcd to follow up with lynx maintainer about homepage 15:07:08 <Sparks> jjmcd to contact #f-devel-l about deprecating homepage 15:07:20 <Sparks> #action jjmcd to contact #f-devel-l about deprecating homepage 15:07:35 <Sparks> Sparks to investigate how RH handles various languages of Publican 15:07:46 <Sparks> rudi: Can you answer that? 15:08:04 <jjmcd> Sparks, I tested, handles them poorly 15:08:06 <Sparks> How does RH manage different languages for installations of RHEL? 15:08:18 <jjmcd> http://www.mi-nts.org/sl/DocMenu3.png 15:08:37 <Sparks> Hmmm 15:09:07 <jjmcd> well, publican, still want to hear what RH does 15:09:14 <Sparks> Ya 15:09:19 <rudi> Sorry -- I'm not sure 15:09:27 <Sparks> I'll try to follow up with mhideo tonight. 15:09:41 <stickster> rudi: Is RHEL 5 using Publican-based docs at this time? 15:09:47 <rudi> Yes 15:09:51 <Sparks> #action Sparks to follow up with mhideo about how RHEL handles multiple languages of Publican docs. 15:10:32 <stickster> Sparks: So when we say "handle," you mean, what's installed by default, and what are considered the expected behaviors when someone installs multiple languages? 15:10:41 <Sparks> yes 15:11:15 * stickster is thinking adopting a Fedora default of "install all languages" needs to go to f-devel-l 15:11:15 <Sparks> Anything else in old tasks? 15:12:11 <Sparks> Okay... let's move to ideas of handling multiple languages in GNOME 15:12:27 <jjmcd> Well, if it's only Gnome, it's easy 15:12:34 <jjmcd> yelp does the job well 15:13:05 <Sparks> #idea Install all languages and have Yelp figure out what language to display based on logged in language. 15:13:26 <jjmcd> #idea Install all html and write a helper app 15:13:34 <Sparks> Yelp ONLY knows if the file has all the languages in it. Can it handle it if the languages are in different files? 15:13:51 <jjmcd> THey are in different files 15:14:21 <Sparks> Yeah? So can they handle various xml files made in Publican? 15:14:23 * stickster confused what "the file" is 15:14:41 <stickster> Yelp expects things to land in /usr/share/gnome/help/$DOCNAME/$LANG/ 15:14:50 <jjmcd> Sparks, yes, we take publican's output xml and give that to yelp 15:14:54 <Sparks> "the file" == Publican output of a specific language of a book 15:15:01 <jjmcd> Only prob is yelp doesn't display the changelog 15:15:17 <Sparks> But the changelog is included INSIDE the book 15:15:28 <jjmcd> Yes, but it shows up as empty in yelp 15:15:34 <stickster> jjmcd: Did you know that shaunm can probably help you get that fixed? 15:15:36 <Sparks> file a bug in yelp 15:15:44 * stickster thinks inviting him into this meeting might be good 15:15:53 <stickster> shaunm maintains gnome-doc-utils upstream. 15:15:59 <jjmcd> stickster, no, I didn't. I suspect it is a yelp bug or a publican-specific tag 15:16:09 <stickster> It's not a publican-specific tag, it's just DocBook 15:16:12 <stickster> <revisionhistory> 15:16:29 <jjmcd> Yeah, kinda strange how it doesn't show up 15:16:58 <jjmcd> So good, now I know it's yelp and not Publican, so I can file a bug 15:17:38 <Sparks> #action jjmcd to file a bug against Yelp to fix revision history from a Publican file 15:18:41 <Sparks> So this is no longer a problem? 15:19:07 <jjmcd> Sparks, FYI: /usr/share/gnome/help/fedora-release-notes 15:19:29 * Sparks really doesn't like this stuff being under "help" 15:20:03 <jjmcd> Publican does not create the omf file. If we stay with yelp, perhaps we should request that feature 15:20:07 * stickster notes that fedora-doc-utils used to have a way of putting things in a Documentation menu, but still using Yelp for the display. 15:20:27 <stickster> I don't think Yelp requires scrollkeeper anymore, but I could be wrong 15:20:41 <jjmcd> Yes, I think in 10 we had about-fedora in two places 15:22:16 <jjmcd> stickster, If I recall, I took some liberties in 11 and was surprised they worked 15:22:32 <jjmcd> So perhaps yelp is smarter than I was giving it credit for 15:23:05 <Sparks> jjmcd: Okay... experiment with Yelp and see what you can do... 15:23:14 <stickster> There are two ways to make Yelp bring up a doc 15:23:16 <Sparks> let's move on to KDE to see if we can get some ideas out about that. 15:23:23 <stickster> yelp file://$PATH/$DOC.xml 15:23:26 <stickster> or 15:23:31 <stickster> yelp ghelp://$DOCNAME 15:23:40 <jjmcd> We know we can make yelp work, but that doesn't help the KDE guys 15:23:43 <stickster> the second form for things that are entered into whatever's the new form of scrollkeeper 15:23:46 <jjmcd> Ahhh, cool 15:24:14 <jjmcd> and $DOCNAME is a subdir of gnome/help? 15:24:30 <stickster> jjmcd: correct 15:25:08 <jjmcd> I know there are those who would prefer html because it is desktop-agnostic 15:25:25 <Sparks> And on the topic of HTML... 15:25:33 <jjmcd> maybe rudi can enlighten us 15:25:35 <Sparks> KDE can't use XML, AFAIK 15:25:53 <rudi> Sorry guys -- one sec 15:26:10 <Sparks> So do we have to use HTML for KDE? 15:26:21 * stickster notes rudi is in #fedora-meeting right now too 15:26:42 <rudi> Yeah -- power management stuff :) 15:26:56 <Sparks> We see where we rank. 15:27:04 <rudi> lolz 15:27:12 <stickster> http://quality.kde.org/develop/howto/howtodocs.php <-- indicates KDE uses XML 15:27:24 <rudi> Let me check to see what the help on my machine here looks like 15:27:43 <Sparks> So we CAN use xml for both GNOME and KDE? 15:28:07 <stickster> http://kde.org/getinvolved/documentation/ 15:29:04 <Sparks> Looks like they are pushing DocBook 15:29:07 <stickster> http://l10n.kde.org/docs/doc-primer/ 15:29:21 <stickster> They may require a conversion to HTML for their display tool 15:29:25 * stickster refreshing memory, it's been a while. 15:29:27 <Sparks> http://l10n.kde.org/docs//markup/index.html 15:30:04 <stickster> A lot of these will make things hard for Publican. 15:30:52 <Sparks> Okay... so what do we NEED to know? 15:30:56 <stickster> Among tags they don't use: articleinfo, edition, sgmltag, productname, productnumber, remark, revhistory (!) 15:31:10 <stickster> Sparks: That HTML is probably going to be the way to go. 15:31:28 <stickster> You would probably need to install two .desktop files for a document 15:32:00 <stickster> One would include "OnlyShowIn=GNOME" and the other "OnlyShowIn=KDE" 15:32:01 <Sparks> two .desktop files? We'd need to packages for each language... 15:32:11 <Sparks> one with HTML and one with XML... 15:32:23 <Sparks> as I THINK it only packages it with XML, now. 15:32:23 <stickster> Why? 15:32:24 <jjmcd> both with html 15:32:37 <Sparks> Okay... so can Yelp handle HTML? 15:32:39 <jjmcd> No, we package both in the same rpm currently 15:32:49 <Sparks> With Publican? 15:32:50 <stickster> yelp file://$PATH/somefile.html <-- works fine 15:32:54 <stickster> try it: 15:33:07 <jjmcd> Ahhhhh 15:33:15 <stickster> yelp file:///usr/share/doc/HTML/fedora-release-notes/en-US/fedora-release-notes-en-US.html 15:33:25 <stickster> Except that dang .SVG file 15:33:27 <Sparks> Okay, so we aren't going to push any more XML... only HTML? 15:33:40 <jjmcd> We gotta get rid of the svg file 15:34:29 * jjmcd can see he is going to have to get a lot more friendly with sed 15:34:42 <Sparks> So are saying that we will not push any document as XML, only HTTP? 15:34:54 <jjmcd> I don't know we said that 15:35:12 <Sparks> Okay, I ask, then... Why do we need to use XML? 15:35:19 <stickster> Sparks: XML is for the document creation. 15:35:31 <jjmcd> Altho, if we can set up yelp to automagically select the correct html that may be a plus 15:35:33 <Sparks> I'm talking about the end product not the production 15:35:56 <stickster> Sparks: For the end product, I'm not seeing a big reason to ship XML in a package for end users. 15:36:16 <jjmcd> Yeah, I'm thinking that too. That would cut the payload almost in half 15:36:22 <Sparks> Okay... now does Publican 1.0 package HTML? 15:36:38 <jjmcd> But I'm from Missouri, I need to do more testing 15:37:30 <Sparks> rudi: Can Publican 1.0 package HTML? 15:37:39 <jjmcd> Don't know what Publican 1.0 does, but 0.44 does it lamely 15:38:06 <Sparks> Well, there is going to be no further development of 0.44 so we need to look towards 1.0 15:38:25 <rudi> Again, I have to say don't know -- I haven't really checked out the packaging features 15:38:47 <jjmcd> Sparks, I'm not sure it matters, at this point I'm not expecting Publican to make the package. The only question in my mind is can we make it look right for the end user 15:39:02 <Sparks> We have to use Publican 15:39:16 <Sparks> This is a decision that affects ALL our guides 15:39:21 <jjmcd> There are so many things it does wrong now it would be a miracle for it to get them all fixed in the next release 15:39:39 <Sparks> 1.0 has fixed many things. 15:39:49 <jjmcd> OK, I can see that. But the other guides are only going to be packaged as single languages, right? 15:40:08 <Sparks> yes... how are you going to do the RN? 15:40:19 <jjmcd> And if you have a single html, publican already does that 15:40:25 <jjmcd> Like we do today 15:40:52 <jjmcd> Like Paul said, we probably need a long discussion with releng if we want to take 41 langs off LiveCD 15:41:13 <Sparks> Well, there are definite negatives to a single package 15:41:31 <Sparks> We wouldn't take the languages off the LiveCD... just separate them 15:41:40 <jjmcd> Yes, but the negatives of multilple packages are much more significant for RNs than for the others 15:41:48 <Sparks> like? 15:42:02 <rudi> That said, how many of those 41 languages are translated to any appreciable degree? 15:42:06 <jjmcd> RNs are in the default distro and, more significantly, in the live CD. 15:42:17 <jjmcd> rudi - I would say better than half 15:42:31 <jjmcd> Only a few are 100% but most are probably >50 15:43:36 <rudi> Only 10 are >50%...https://translate.fedoraproject.org/projects/docs-release-notes/f11-t… 15:44:12 <jjmcd> So 1/4, makes it an easier sell I suppose, but is that really what we want? 15:44:24 <Sparks> so every time you update a single translation you are forcing everyone to pull that new RPM even if their language didn't change 15:44:39 <jjmcd> We only do that once per release if at all 15:44:46 <jjmcd> historically 15:44:50 <Sparks> why? 15:45:08 <Sparks> We should be pushing updates many times... whenever they are ready 15:45:20 <jjmcd> Just the way it's been. By the time there are significant new translations, we are mired in the next release 15:45:22 <Sparks> otherwise, lock the translations after the release 15:46:26 <jjmcd> Sparks, once we have the new tfx, we should be able to gen new rpms easily, but right now it is still a day's job or better 15:46:33 * stickster thinks it would be a good idea for Sparks and jjmcd (and other interested Doc'ers) to stay tuned into the yum-langpack issue 15:46:53 <Sparks> stickster: not familiar with that issue. 15:47:41 <stickster> https://fedoraproject.org/wiki/Features/YumLangpackPlugin 15:48:12 <Sparks> jjmcd: Yeah, I know it is a pain but if the translators are doing the work we should reward that 15:48:26 <jjmcd> Sparks, I agree 15:48:31 <rudi> +1 15:48:44 <Sparks> Apparently Transifex 0.7 is being readied now. 15:48:58 * stickster lost on what question we're trying to answer at this point. 15:50:09 <jjmcd> Sparks wants one rpm per language. Actually makes sense for the guides, I'm not convinced on RNs 15:50:27 <Sparks> What's the difference between the Guides and the RN? 15:50:45 <jjmcd> The RN's get installed by default 15:50:51 <Sparks> so? 15:50:58 <jjmcd> And people expect to find them 15:51:13 <Sparks> So if the Security Guide gets installed by default then that changes things? 15:51:24 <jjmcd> What lang are you going to install? 15:51:28 <Sparks> all of them 15:51:54 <jjmcd> And what lang will be on the LiveCD. Remember, LiveCD is most folks first exposure to Fedora, and not all of those folks are in the US 15:52:17 <stickster> jjmcd: I'm not sure the release notes SHOULD be installed by default 15:52:23 <Sparks> you said, last week, that the space difference between pushing all langs as a single package or by separating them into separate packages was neglegiable 15:52:35 <jjmcd> I can buy that, but I'm not willing to make that decision unilaterally 15:52:36 <Sparks> jjmcd: All of them 15:52:44 <stickster> You've installed. And now you want to see what's different. Maybe we should provide a way to *get* relnotes. 15:52:59 <rudi> 25 languages are <10%, and of them, 11 are <5% 15:53:14 <jjmcd> That would certainly help out the LiveCD space issues 15:53:28 <rudi> I think there's a "least astonishment" issue here 15:54:00 <jjmcd> rudi, I suspect the most commonly used languages are the most translated, but I don't have data 15:54:23 <rudi> If people click on something purporting to offer them the release notes in Finnish, and the only extent that it's "in Finnish" are a couple of headings and the rest of the text is in English, I think that's a fail 15:54:42 <Sparks> well of course they are the most commonly used languages... they are the only ones that are provided! :) 15:55:06 <stickster> rudi: I think that offering a download, and indicating the translation level and a link to help improve it... might be a win 15:55:13 * stickster has to split for another meeting 15:55:36 <jjmcd> Could be that I'm somewhat Euro-centric, but I suspect there are more Dutch users than Assamese, for example 15:55:58 <jjmcd> stickster, That does sound like a good idea 15:56:36 <jjmcd> I'm also assuming that if we have a large user community, we likely have a large translator community, too 15:57:31 <Sparks> Okay... five minutes left... 15:57:45 <Sparks> Did we agree to only ship HTML and no XML? 15:57:57 <jjmcd> Sparks, I could see fancying up docs.fp.o to include trans stats, and f-r-n.rpm simply has a menu entry 15:58:11 <Sparks> jjmcd: I'm good with that 15:58:18 <rudi> jjmcd -- great idea 15:58:43 <jjmcd> rudi, is there a clean way to capture trans stats when we make the html? 15:59:05 <jjmcd> We want the online stats to reflect the production doc so we can't just link to tfx 15:59:24 <rudi> In Publican 0.x yes -- really nice actually 15:59:25 <jjmcd> I would hate to do that by hand, but we could 15:59:38 <rudi> But I think the feature was dropped in 1.0 coz no-one was using it :) 15:59:48 <jjmcd> cool, OK then, lets assume that;s our jumping off point 15:59:59 <jjmcd> :-( 16:00:12 <rudi> But Transifex gives us statistics right there 16:00:48 <jjmcd> Yes, but can I write a script to capture tfx stats into index.php at the time I make index.php 16:01:03 <jjmcd> Oh wait 16:01:09 <rudi> I don't know -- ask glezos :) 16:01:19 <jjmcd> One of the utils tells me that, so of course I can script it 16:01:27 <jjmcd> Just gotta figure out how 16:02:10 <jjmcd> You just reminded me that there is a util somewhere that looks at the po and tells me the % xlated which is exactly what we want 16:02:29 <rudi> Yeah, one of the gettext utilities 16:02:33 <jjmcd> yep 16:02:34 <rudi> *thinking* 16:02:41 <rudi> msgfmt? 16:03:48 <jjmcd> I'll find it 16:03:59 <rudi> msgfmt --statistics, I think 16:04:32 <jjmcd> Ahhh yes, man says so 16:05:15 <rudi> Yep -- just confirmed it 16:05:22 <jjmcd> So I could take that output and use it to add % trans to index.php 16:06:11 <jjmcd> OH I gotta go too 16:06:18 <Sparks> Did we agree to only ship HTML and no XML? 16:06:22 <jjmcd> Looks like we have a plan 16:06:25 <rudi> Yep -- 2AM and bedtime here 16:06:31 <jjmcd> No, we are only going to ship a menu item 16:06:43 <Sparks> a menu item? 16:07:01 <Sparks> to point to docs.fp.o? 16:07:02 <jjmcd> We'll save LiveCD 20 megs, people will get latest version, and trans stats 16:07:05 <jjmcd> Yep 16:07:16 <Sparks> What about those that don't have web access? 16:08:07 <jjmcd> Not much in Fedora works without web access these days, anyway. That was bbasically stickster's suggestion so lets talk about that with him, but use this as our current target 16:08:47 <Sparks> Okay.... I'm good with that approach for the LiveCD... I'm thinking about our SIPRNET users and airplane users 16:08:49 <jjmcd> I'm thinking the 22Mb will be worth more than the problem with offline 16:09:10 <Sparks> ya 16:09:13 <Sparks> Okay... anything else? 16:09:44 <Sparks> #endmeeting

1 0

[Fwd: Re: [fedora] question about &PRODVER;]
by Noriko Mizumoto 13 Aug '09

13 Aug '09

Hi Docs team There is one question I can not find the answer, please help. I've looked through https://translate.fedoraproject.org/projects/docs-common-entities/master/, but it seems no such entity in this file. thank you for your help noriko -------- Original Message -------- Subject: Re: [fedora] question about &PRODVER; Date: Wed, 12 Aug 2009 13:11:02 +1000 From: Yulia Poyarkova <yulia.poyarkova(a)redhat.com> To: noriko(a)redhat.com References: <4A8204E2.6020908(a)redhat.com> <4A823045.3020602(a)redhat.com> He mentioned file https://translate.fedoraproject.org/projects/docs-readme-burning-isos/maste… Apparently there is a string like this: "... if downloading Fedora &PRODVER; for a Pentium 4..." Noriko Mizumoto пишет: > Yulia Poyarkova さんは書きました: >> Hi Noriko, >> >> I got a question from Russian Fedora translators. >> Is there some place/file where we could see the list of those special >> symbols like (&PRODVER; —), >> because sometimes it's not quite clear what they mean exactly. >> >> Thank you, >> Yulia > Can you point where those entities can be found? > > noriko >

2 2

No meeting this week
by Eric Christensen 13 Aug '09

13 Aug '09

Sorry for the late notice... Zikula meeting is preempting the Docs meeting this week. I'll be asking for updates on the list later tonight. -- Thanks, Eric Christensen Fedora Docs Project Lead Fedora Talk: 5102043 Phone: 919-424-0063 x 5102043 E-Mail: sparks(a)fedoraproject.org SIP: sparks(a)talk.fedoraproject.org IRC: Sparks on freenode.net GPG Fingerprint: CA02 4ACA EB6C 1A76 F0D6 1127 7D04 D240 BD0C 14C1

1 0

Docs on fh.o
by Eric Christensen 13 Aug '09

13 Aug '09

Are all guides in a repo on fedorahosted.org? --Eric

2 1

Updated Fedora 12 Schedule
by John Poelstra 13 Aug '09

13 Aug '09

I have updated the schedules based on the public schedule review held on 2009-08-06. I have also changed the formatting of the report as requested to group major tasks/sub-tasks versus a purely chronological report. Documentation: http://poelstra.fedorapeople.org/schedules/f-12/f-12-docs-tasks.html Translation: http://poelstra.fedorapeople.org/schedules/f-12/f-12-trans-tasks.html Combined/chronological: http://poelstra.fedorapeople.org/schedules/f-12/f-12-docs-and-trans-tasks.h… As always let me know what needs to be fixed or should be reported differently. John

3 4

agenda and idea for 12 Aug meeting
by Karsten Wade 12 Aug '09

12 Aug '09

(Cross-posted to logistics & docs lists because of wider topic.) John Poelstra has proposed having the Zikula schedule discussion as the first part of the Docs meeting this week, after Paul's suggestion to preempt the Docs meeting for this important topic. Because that works best via voice, we are going to be mostly discussing on sip:2009@talk.fedoraproject.org. How about if we just *move* the Zikula coordination meeting to interact with the Docs meeting until the CMS is rolled out? How does Docs feel about that? To do that, we would want to take all of the status-of-guides notices directly to the list _before_ the meeting. Then we can discuss exceptions to the schedule in the meeting, if needed. This week, I propose that we spend the second part of the meeting discussing the Docs/L10n schedule. These goals: 1. Explain it to everyone present 2. Figure how to show key dates, etc. so it is clear to writers/editors 3. How to manage regular reminders (nagging) of upcoming dates My experience shows that a complex schedule with a distributed team requires regular reminders and continuous understanding. Talk about it often. Show how it changes over time. Make sure people don't forget key dates. That's the (permanent) agenda topic I propose, starting this week with deeper understanding for all. Since John (poelcat) will be present, he can help us explain the schedule; we can talk about presentation choices, etc. cheers - Karsten -- Karsten 'quaid' Wade, Community Gardener http://quaid.fedorapeople.org AD0E0C41

3 4

← Newer
1
2
3
4
5
6
7
8
9
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

docs August 2009