# /srv/irclogs.ubuntu.com/2010/02/23/#ubuntu-classroom.txt

humphreybc humphreybc humphreybc === kermiac_ is now known as kermiac === mhall119|SCaLE8x is now known as mhall119|work === kermiac is now known as kermiac_ um 04:00 i have a voice! 04:00 === ChanServ changed the topic of #ubuntu-classroom to: Welcome to the Ubuntu Classroom - http://wiki.ubuntu.com/Classroom || Support in #ubuntu || Upcoming Schedule: http://is.gd/8rtIi || Event: 48 Hours of Ubuntu Manual Learning - Current Session: An introduction to the project - Instructor: humphreybc || Questions in #ubuntu-classroom-chat [SLIDE 1] 04:00 https://wiki.ubuntu.com/ubuntu-manual 04:01 Can i have a show of hands for who's actually here? 04:01 === epkugelmass is now known as Guest45531 we'll wait another 2 minutes for some stragglers to arrive 04:02 okay so those who aren't using Lernid, you can get the slides from  http://kevin.godby.org/ubuntu-manual/talks/ 04:04 Also, you can chat in #ubuntu-classroom-chat 04:04 because you're not voiced in this chatroom 04:04 and lastly, to use the ClassBot question feature, ask a question in the chatroom and preface it with "QUESTION" 04:05 eg, "question: why are you telling me all this even though I already know it?" 04:05 i'm going to assume everyone's happy and i'll move on! 04:05 you can ask a question whenever you want btw 04:05 okay so, the ubuntu manual project 04:06 what the project is about. [SLIDE 2] 04:06 what we're trying to do is create some great documentation that's easy to follow and all in one place 04:06 I used to be an Ubuntu beginner once 04:07 and basically when I started I found the help to be quite hard to find, our out dated 04:07 that's nothing against the docs team, they're doing the best they can and it's hard to maintain docs 04:07 so what we're trying to do is create an up-to-date comprehensive manual that's in a context for fairly new people to Ubuntu and computers in general 04:08 We'll re-release a version every 6 months to coincide with Ubuntu releases 04:08 at the moment we're obviously working on the Lucid release 04:08 The project itself only started a couple of months ago with just me writing the document myself. I originally was going to make it closed-source but free, 50 pages or so, not a huge amount of screenshots, in open office and only in english 04:09 but some ubuntu community members advised me to open it for collaboration on launchpad 04:09 So i did 04:09 turned out that a lot of people felt that a manual like this was really needed 04:09 so now we have 250+ contributors, working towards a 200 page manual with 50 screenshots translated into 40+ languages 04:10 instead of using open office we write it using latex 04:10 [SLIDE 3] 04:10 Who it's for 04:10 We're targeting people who have possibly used a computer before on either Windows or Mac 04:11 we expect them to know what a mouse is and we expect them to have basic computer skills - enough to be able to acquire the manual in the first place 04:11 but from then on, our manual is written assuming they've never heard of Ubuntu or Linux 04:11 so we give an introduction to Ubuntu/Linux, history of it, talk about the community and FOSS software etc in the prologue 04:11 we teach them everything they need to know to get stuff done 04:12 but we don't teach them too much 04:12 our target audience view computers as a "means to an end" 04:12 they don't want to know how it works, they just want to know how to get stuff done, like print or send emails or view photos :) 04:12 [SLIDE 4] 04:13 So basically What we want to achieve - i've sort of covered this already 04:13 our goals are inclusion on the default CD at some stage, and definitely in the repositories. 04:13 we want to give the reader many choices with regards to language, format, layout, paper size etc 04:13 so in the future we're planning an HTML5 version, paper sizes will be attached to languages (en_US will be US Letter size, en_GB will be A4 etc) 04:14 and we're going to create a nice website with an easy way to acquire the right manual. probably just three questions that they answer, like "what language do you speak" "what country are you from" and "what distribution would you like the manual for" 04:15 (we might do a Kubuntu/Xubuntu/Ubuntu Netbook Edition/Ubuntu Developers Manual etc down the line, depending on the success of this one) 04:15 okay, so, any questions on all of that before I move on? 04:15 (questions can be asked in #ubuntu-classroom-chat) 04:16 nope? 04:16 okay, moving on 04:16 [SLIDE 5] 04:16 so that's all well and good I hear you say, but _how_ is all this going to happen? 04:17 well, we are using a bunch of existing tools and creating our own tools in some instances 04:17 basically the manual itself is written using LaTeX 2009, in .tex files that are compiled into a PDF (and down the line, other formats like HTML5) 04:18 we use Launchpad for blueprints, code hosting, milestones, bugs, answers and translations 04:18 We use Bazaar for version control, and the Ground Control application as a GUI front end to bzr 04:18 We use Launchpad's rosetta system for translations, and po4a to take the strings out of the .tex files and put them into .po and .pot files 04:19 we use several methods of communication, namely, IRC channel (#ubuntu-manual), mailing list, wiki, weekly meetings, facebook, msn, skype 04:19 we also have an aggregated blog: http://planet.interesting.co.nz 04:19 We thrive on publicity and hype, and we have ambitious goals 04:20 but we have a fast paced development environment 04:20 there isn't much stuffing around, we just "get things done." 04:20 [SLIDE 6] 04:20 Who the key people are 04:21 I won't repeat what's on the slide here because you should be able to see it 04:21 basically there are 6 key people 04:21 vdquynh asked: on which server is the #ubuntu-manual channel (I'm connected and searching irc.ubuntu.com) 04:21 irc.freenode.net :) 04:21 sorry I should have made that clear 04:22 so 6 key people, myself, project leader, dutchie who does a tonne of backend stuff, godbyk who does the latex stuff, Ilya, who works with the authors, Jamin who coordinates editing and thorwil who does the artwork 04:22 we also have a small team of developers working on Quickshot (i'll explain what Quickshot is soon) 04:23 by the way, these slides are all available in our bzr branch lp:ubuntu-manual 04:23 [SLIDE 7] 04:23 Okay, Quickshot! 04:23 So, basically, in our manual we have around 50 spaces for where we'd like to put screenshots 04:23 and we want all the screenshots to be localized (no use putting an english screenshot in the chinese manual) 04:24 so, 40 translations 04:24 the math is 50 x 40 = 2000 screenshots 04:24 we also need the resolution, theme, applications, dpi, file format, file name etc to be consistent so we can work well with them in LaTeX, and also so it looks good 04:24 it would take years for a few people to get all these shots themselves, and it would be very very inefficient and time consuming 04:25 so i came up with the idea to write a program that automates a lot of the stuff 04:25 quickshot isn't really a screenshotting application - that's what it does, yes, but it's only a small part. the big part of quickshot is that it sets up a new default user with the default theme, switches users to that user, pulls a branch full of some code that tells it what screenshots need to be taken. Quickshot then tells the user what screenshot they'll be taking, tells them to set up their screen, takes the shot and 04:26 the UI looks like this at the moment: [SLIDE 8] 04:26 For the technical peeps: it's written in Python using Quickly and Glade to design the UI 04:27 [SLIDE 9] 04:27 Okay, so, how you can help us! 04:27 What's cool about our project is: 04:27 1. We cover a huge range of stuff, from programming to writing, to editing and artwork, to maintaining social sites and updating twitter. you name it, we do it. 04:28 2. We are fast paced, we're fun to work with, and there are always things happening 04:28 3. We run a lot of events and we do a lot of cool stuff 04:28 and 4. We make it easy for you to join and get started 04:29 So, questions? 04:29 no one has any questions at all? 04:30 yay! 04:30 vdquynh asked: Is Quickshot ready to be used right now? 04:30 Nope, it's not. It's still under heavy development - I only thought of the idea last week :P 04:30 you can check out the branch though, http://launchpad.net/quickshot 04:30 bzr branch lp:quickshot 04:30 you can run it by double clicking the run.sh script 04:31 TommyBrunn is working on the Python with ubuntujenkins, i'm helping with the UI and bzr stuff 04:31 and yes, we do need help! 04:31 that's okay 04:32 when it's finished it will be super dooper easy to use :P 04:32 abeisgreat, meh, i'm not very good at python either 04:32 any help would be useful, honestly 04:32 epkugelmass_lern asked: How are discussions progressing with the Ubuntu distro drivers? Are they actively considering Ubuntu Manual for 10.04 release? I know the feature freeze (a3) is coming up fast. 04:33 No, they're not. It won't be in the Lucid CD because a) Lucid is an LTS b) we're a very young project and c) we weren't at UDS-L to actually suggest it 04:33 but don't worry, it will be easily accessible on websites/repos etc 04:33 and i'll put it forward for 10.10 :) 04:33 should be on the CD for 10.10 04:33 Takyoji asked: Where would it be listing of what exact screenshots need to be taken? Also, is it on a basis of a person being assigned to taking screenshots of the same dialog in different languages, or? 04:34 What's happening is the authors are inserting a command into their latex chapters where they think a screenshot is necessary. in the compiled PDF it looks like "MISSING SCREENSHOT" and has a description underneath 04:34 these missing screenshots are actually exported to a file in the branch "screenshots.log" i think 04:34 that list will be taken, with some nifty scripting, and duplicated for 40 different branches, one for each language 04:35 inside each branch will be folders for chapter, and in each chapter will be the relevant screenshots as plain text files containing their description. Quickshot will be programmed to find plain text files and treat them as "screenshots that are yet to be taken" 04:35 it will pull the description out, and, when the shot is taken, replace the plain text file with an image file ending in .png 04:36 Quickshot will then ignore .png files as they've already been done :) 04:36 We are aiming to get this thing ready for the Ubuntu Global Jam 04:36 so we can get tonnes of people screenshotting 04:36 oh also, Quickshot will have the ability to change the system language for the "quickshot" user 04:37 obviously all the english screenshots will be captured first 04:37 so once that's done, we'll have to have the user switch to another language for taking shots :) 04:37 good question. 04:37 https://wiki.ubuntu.com/ubuntu-manual/quickshot 04:38 Abeisgreat asked: How far along is quickshot? I know you said it's only a week old, but how far is it? 04:39 surprisingly we're doing pretty well 04:40 I've finished most of the main UI dialogs 04:40 Quickshot at the moment can: 04:40 Create a new user 04:40 Prompts the current user to switch (and has a button to do that) 04:40 opens on start in the quickshot user 04:40 account 04:40 it can also remove that user 04:40 next on the list is creating the bzr branch, pulling it and installing dependencies like language packs and fonts if they want to change language 04:41 we're aiming for it to be ready by March 18th (manual beta, lucid beta) 04:41 and then finished bug-free by April 1st 04:41 That gives us about a month of solid screenshotting till our RC on the 20th of April 04:41 we'll start the english screenshots on March 4th which is the Lucid UI freeze 04:42 and we are going to use those as "example" shots 04:42 it's all very busy 04:42 yep, it's a cool project 04:43 I really like quickshot, it's a bit of fun 04:43 Takyoji asked: What if the default theme in Lucid is changed? 04:43 the default theme is changing in Lucid :) 04:43 we're packaging Quickshot actually for Lucid, and targeting it at Lucid testers 04:44 and after March 4th, Lucid won't and can't change in appearance at all because that's the User Interface freeze 04:44 we don't have much time, so we'll need all the help we can get 04:44 and we're designing quickshot to be as easy and automated as humanly possible 04:44 so even your grandma should be able to capture screenshots for us! 04:44 vdquynh asked: How will we interact with bzr? Will it be sufficient to have a Launchpad account? 04:45 Yes, the branch will be entirely open so anyone with an lp account should have write permissions and auto-merging. We are considering seeing if the launchpad guys can actually make our branch public so _anyone_ (even without an lp account) can push. Either that, or ask them to sign in on Quickshot and if they don't have an account, create one through Quickshot 04:46 Takyoji asked: Would that imply that March 4th would be a reasonable time to start helping with taking screenshots? (or whenever the new theme is officially released) 04:46 Not much will be happening around March 4th, but on March 18th there will be a huge rush as all hands man the screenshot pumps! 04:46 We're aiming to get everything out of the way in the project before march 18th - that means writing, content, editing, icons, title page, artwork, style, colours... everything 04:47 March 18th is our writing freeze so translations can catch up 04:47 so all of our team will be screenshotting for a whole month 04:47 :) 04:47 vdquynh asked: Do I understand well that translations shoud better start after March 18th? 04:48 yep, at the moment translations are a bit hay-wire. I wasn't even planning on having anything more than an english manual, so I never thought about translations. Then all of a sudden we had like 100 people from all countries start emailing us asking for translation support, so we rushed to build it in 04:49 the problem with translating stuff early is that it is subject to change 04:49 and so a lot of the stuff they're translating is changing every day as authors and editors re-work sections and bits and pieces 04:49 I would wait until March 18th to start translating, because then you know anything you do will stick as our writing is frozen. Anything in the manual on March 18th is there for good, no exceptions. (unless some cheeky blighter drops in a swear word somewhere right before the freeze) 04:50 yup :) 04:51 more questions? we've still got 10 minutes until i start rambling on about ground control and how cool it is :) 04:51 cool :) 04:53 http://launchpad.net/groundcontrol 04:55 Takyoji asked: What will be the licensing of the Ubuntu Manual? 04:59 Creative Commons Attribution Share Alike :) 04:59 === ChanServ changed the topic of #ubuntu-classroom to: Welcome to the Ubuntu Classroom - http://wiki.ubuntu.com/Classroom || Support in #ubuntu || Upcoming Schedule: http://is.gd/8rtIi || Event: 48 Hours of Ubuntu Manual Learning - Current Session: Using Ground Control to make changes - Instructor: humphreybc || Questions in #ubuntu-classroom-chat which basically means that it's free, anyone can use the source code, copy it, change it, redistribute it etc 05:00 okay, ground control! 05:00 [SLIDE 1] 05:00 once again, slides available @ http://kevin.godby.org/ubuntu-manual/talks/ 05:00 or if you're using Lernid, you should see them to the top right! 05:01 So, Ground Control is basically a front end to bzr/bazaar 05:01 it's a python plugin for Nautilus written by Martin Owens 05:01 it's pretty sweet, avoids the command line entirely and makes stuff a lot simpler 05:01 it's not perfect yet, but it does the job and martin needs more testers so I offered to use it in UMP 05:01 soooo for you to install it and run it, i've made a handy dandy walkthrough video 05:02 * humphreybc tries to find the link 05:02 http://www.youtube.com/watch?v=MeNXqfofbWk 05:02 it should appear in Lernid 05:02 so have a watch of that 05:03 it's just over 6 minutes long 05:03 and let me know when you've watched it :) 05:03 [SLIDE 2] 05:05 I just put the commands in the slideshow window 05:05 okay so everyone watched it? 05:08 please say something so i know there are still people here... 05:08 okay cool we can wait, we've got tonnes of time 05:08 groovy, ok we'll move on but i'll leave the video there 05:09 [SLIDE 3] 05:10 so basically, as you can see from the video it's pretty easy to use 05:10 where some people had difficulty earlier today was with setting up the SSH key when logging into your account 05:10 so let me know if that's a problem for anyone 05:10 basically just the most important thing is to a) make sure you're a member of our team 05:11 and b) check the "download my branch" radio button 05:11 if you choose either of the other two, you'll end up with a read only branch that you can't commit, or you'll push and create a merge proposal. We avoid merge proposals, and i'll tell you why 05:11 other projects that are crucial to the system, such as the boot team stuff, software center, synaptic etc 05:12 they use merges because they don't want someone coming along and deleting all the code or stuffing it up and then pushing to main 05:12 so they review each merge and approve or decline it for inclusion into main 05:12 why don't we do that? easy: 05:12 1. We have so many people committing and making revisions, we'd have merge proposals coming out of our easr 05:13 ears* 05:13 2. We don't have time to bother with merge reviews because we're too busy working on the project - we have a tight enough schedule as it is without a full time merge reviewer! 05:13 But you may say "well what happens if someone breaks something?" - we can easily revert to an earlier revision 05:13 in this case, not having merges has more benefits for us than cons 05:14 so, that's why you "download my branch" so you can push directly into main 05:14 remember the requirements to be able to get our branch. You need: 05:14 1. A launchpad account 05:14 2. An SSH key for your computer 05:14 3. To be a member of our team 05:14 4. Have bzr or Ground Control installed 05:14 [SLIDE  4] 05:15 [SLIDE 5] 05:15 wait 05:15 [SLIDE 4] 05:15 there we go :P 05:15 Okay so you probably don't need to know this but I think it's quite cool so i'm going to tell you 05:15 at the end of the video you might have noticed some buttons that say "Make Show" and "Make Clean" 05:15 vdquynh: good question, i'll have to find out. hang on, i'll answer that in a sec :) 05:16 okay so these developer buttons are a feature in Ground Control 1.5 05:16 basically in the root of our branch there is a file called .gcfunctions 05:17 How do we know if our computer has a ssh key? and how to find it? 05:17 oops 05:17 http://www.youtube.com/watch?v=MeNXqfofbWk 05:17 copy pasta fail 05:17 so where was I? ah, right, .gcfunctions 05:18 in this file there is some basic code that sets up some buttons with a label and a command 05:18 all they run is "make show" and make clean 05:18 i just thought they were neat :) 05:18 okay, your question 05:18 vdquynh asked: How do we know if our computer has a ssh key? and how to find it? 05:18 I *think* Applications > Accessories > Passwords and Encryption Keys. "My Personal Keys" tab, and there should be a key for SSH 05:19 also, on launchpad, go to your profile (ie, mine is https://launchpad.net/~humphreybc ) 05:19 and it should say you have an SSH key 05:19 see how it says "SSH keys: benjamin@benjamin-laptop" ? 05:20 https://help.launchpad.net/YourAccount/CreatingAnSSHKeyPair 05:21 vdquynh: have a look at that 05:21 it runs you through setting up an SSH key 05:21 sweet :) 05:22 so any other questions about ground control or bzr? 05:22 There is a session later on on launchpad where i explain more about launchpad features 05:22 the logs for all of these sessions can be found on http://irclogs.ubuntu.com 05:22 and the slides are on godbyk's website, also in our bzr branch under the folder "48hours" 05:23 tomorrow that folder will be renamed to "help" 05:23 to get the branch, follow the ground control video, or run "bzr branch lp:ubuntu-manual" in a terminal 05:23 any other questions? 05:24 * humphreybc likes it how he has a 2 hour break to get some dinner before talking about social media 05:24 neat! well stick around because josh and Ilya have some really cool presentations coming up 05:25 (If you're using Lernid, you can check out the schedule by clicking on "Schedule" up the top) - it also gives you the times in your local timezone! 05:26 okay fellas, i'm off to grab something to eat :) 05:27 any questions you have, just ask in #ubuntu-manual on irc.freenode.net 05:27 Josh will start his session on translations in about 30 minutes 05:27 === nhandler_ is now known as nhandler have fun dutchie! 05:52 === ChanServ changed the topic of #ubuntu-classroom to: Welcome to the Ubuntu Classroom - http://wiki.ubuntu.com/Classroom || Support in #ubuntu || Upcoming Schedule: http://is.gd/8rtIi || Event: 48 Hours of Ubuntu Manual Learning - Current Session: Translations and how they work - Instructor: dutchie || Questions in #ubuntu-classroom-chat OK, here we go again ;) 06:00 Hi everyone, and welcome to my talk on the translations system used by the Ubuntu Manual project. 06:00 My name is Josh Holland, and I go by the nick dutchie. 06:00 I've been involved in the Ubuntu Manual project since pretty much the beginning. 06:00 I run a fair bit of the backend stuff, including the IRC bot, the planet, and, of course, the translations. 06:00 What I'm going to cover today includes: 06:01 * How to contribute a translation 06:01 * A brief overview of the translation infrastructure 06:01 * How to build a translated version of the manual 06:01 If you've got a question, stick it in #ubuntu-classroom-chat with QUESTION: at the front and I'll answer it when appropriate. 06:01 I'll also pause for questions at the end of each section. 06:01 So, let's get started! 06:01 (It's 6 AM here, so if I stop making sense, tell me ;) ) 06:01 [How to contribute a translation] 06:02 (ooh, sorry - no slides for me. Ones on translation won't really be that interesting, and you've got the links to look at) 06:03 This is easy! Just go to http://translations.launchpad.net/ubuntu-manual and click on the language you want to translate. 06:03 You will then see the Launchpad translations UI. 06:03 All you have to do now is enter your translations into the boxes 06:03 They will then be reviewed, and hopefully included in the final translation! 06:04 Any questions so far? 06:04 [The translation infrastructure] 06:06 The Ubuntu Manual and Launchpad use the GNU Gettext system of translations 06:06 This is centred around two types of file: .pot files and .po files. 06:06 .pot files are translation template files, and contain all of the strings that need translation 06:06 Ours is called ubuntu-manual.pot, and, along with all the .po files, lives in the po/ directory at the top of the source tree 06:07 You can see all of the translation files here: http://bazaar.launchpad.net/~ubuntu-manual/ubuntu-manual/main/files/head:/po/ 06:07 The .po files are the ones which actually contain the translations 06:07 They are named after the language they translate, such as fr.po for the French translation, and en_GB.po for the British English one 06:07 More information about the format of .pot, .po and .mo (which we don't need) files is available from http://www.gnu.org/software/gettext/gettext.html 06:08 Essentially, a .po file contains a list of untranslated strings and translated strings next to each other, in a well-defined parsable format 06:08 The text is indexed by file and line number to make it easy to match up where it came from 06:09 GNU Gettext is mainly intended to translate software programs, rather than documentation 06:09 We therefore can't use it directly, becuase it is normally used as a software library 06:09 So, to translate a Python program for example, you'd do "import gettext", then pass every string that needs translating to a special function 06:10 Other languages supported by gettext (all major ones) work in much the same way 06:10 Instead, we use po4a, or po for anything (http://po4a.alioth.debian.org) 06:10 This is a set of Perl scripts that allow you to use the infrastructure built up around translating Gettext files for your project 06:10 There is a lot of infrastructure based on .po and .pot files 06:11 Rosetta (Launchpad's translation interface) is an excellent example, but there are other po editors, such as po mode in Emacs, and GUI ones like poedit 06:12 It supports manpages, Perl pod format, xml, sgml, TeX, plain text, ini and KernelHelp files 06:12 It can be run using individual commands analogous to msgmerge, xgettext and friends, but it is easier to use the po4a(1) command and a configuration file 06:12 We only need the TeX support, but as you can see, it can be used in a wide range of situations 06:13 Any questions on Gettext or po4a? 06:13 hmm 06:15 ClassBot: wake up 06:15 < vdquynh> Question: I either translate directly in LP or I download the vi.po file to work with poedit. IS that OK or should I use po4a when offline? 06:15 You, as a translator, will never need to worry about po4a 06:16 That's a tool I use to generate and keep the po files up to date 06:16 We'd prefer it if you worked directly on Lauchpad 06:16 You'll see why in a moment when I go through updating the translations 06:17 But, if you like, you can use poedit on the files in the bzr tree and commit and push like that 06:17 No more questions? 06:17 [How the translations are updated] 06:18 I try to update the translations around every day. 06:18 However, I have a busy life and I don't always manage this, so be gentle if I forget ;) 06:18 There are two stages to updating the translations. 06:18 1. Updating the translated files 06:18 (Pulling in the new translations from Launchpad) 06:19 2. Updating the translation .pot file 06:19 (Changing the .pot file, and possibly the .po files, if any of the content has changed) 06:19 The translations done on Launchpad are exported into the lp:~jshholland/ubuntu-manual/manual-trans branch 06:19 (This is very clever and useful, a very handy Launchpad feature) 06:20 I merge this in, which inevitably results in conflicts. These are resolved by just using the copy from LP, and discarding any local changes. 06:20 This is the bit that gives Launchpad translations the "upper hand" 06:20 If someone translates the same bit on Launchpad as someone else in the bzr branch, the Launchpad version will be used 06:21 However, if it's unchanged, it will be picked up when Launchpad scans the branch (another awesomely cool feature) 06:21 Once I've done this, I commit the merge and run the following command: 06:22 $po4a --no-translations --copyright-holder="The Ubuntu Manual Team" --package-name=ubuntu-manual --package-version=$(bzr version-info --custom --template={revno}) po4a.conf 06:22 (it's a big one :) ) 06:22 This command updates the .pot file and .po files, without generating translated content, and sets appropriate values in the files. 06:22 As I said, I'm the only one who needs to worry about po4a 06:23 But, if you're interested, the po4a.conf control file is visible here: http://bazaar.launchpad.net/~ubuntu-manual/ubuntu-manual/main/annotate/head:/po4a.conf 06:23 It's very small 06:24 po4a works a lot of the details out for itself, which is quite handy 06:24 This is then committed and the whole lot is pushed up to Launchpad. 06:24 Launchpad then scans the branch, and imports the .po and .pot files to use as a basis for the translations done. 06:24 This means that any new translations done in the branch are imported back into Launchpad 06:25 (if they haven't been overwritten) 06:25 The cycle then repeats. 06:25 Any questions about how this all works? 06:25 vdquynh asked: how much time between the start and end of process for any language? 06:26 Hard to say really 06:26 All of the languages have been open the same time 06:27 I'm sure that they've all got a different number of translators working on them 06:27 As of now, the translation into British English (yes, that has to be done) is complete 06:27 The rest are all at varying stages of completion, as you can see by going to http://translations.launchpad.net/ubuntu-manual and clicking "Show all languages" 06:28 That leads fairly nicely on to freezes 06:29 At the beginning, we had lots of content being written and edited 06:29 People would translate something, then a day or two later, the original would change, and it'd have to be translated again 06:30 This was quite a problem up to the alpha 06:30 Now, though, less of the content is being changed, but this problem hasn't gone away completely 06:31 So, at the beta, we intend to freeze all writing and editing 06:31 This would give the translators a chance to catch up with all of the content before final release 06:31 Questions on the freeze? 06:32 vdquynh asked: When an original string has been translated and changes, is the translated string automatically dismissed or flagged in some way that the translator knows that he /she has to do it again? 06:32 po4a detects that the string has changed and updates the .pot and .po files 06:33 This means that the string has to be translated again 06:33 po4a keeps track of that sort of thing internally 06:34 Just to make this clear, you can do translations now, but there is a small chance they will be lost if the original string changes 06:34 Keep working from now until your language is done, then learn another language and do that one ;) 06:35 [How to build a translated version of the manual] 06:35 This bit was written when you didn't require Tex Live 2009 anyway 06:36 so ignore it for now :) 06:36 Thanks to some cool work from godbyk, our LaTeX guru, it's not too hard to see your translations in the manual. 06:36 Unfortunately, we've had to use the polyglossia LaTeX package to handle the translations. 06:36 This is only available with texlive 2009, which is only in the repos for Lucid (10.04). 06:36 So, if you're running Karmic (9.10), you have two choices: 06:36 1. Upgrade to Lucid 06:36 2. Download and install texlive 2009 directly from upstream 06:36 This set of instructions was taken from https://lists.launchpad.net/ubuntu-manual/msg00548.html (thanks godbyk) 06:36 The first part of this will only apply to people running Karmic (or earlier). 06:36 Step one is removing any texlive packages you've already got. 06:36 You can do this on the command line via "sudo apt-get remove texlive-*" or through Synaptic. 06:36 The next step is to download http://mirror.ctan.org/systems/texlive/tlnet/install-tl-unx.tar.gz, the install script for texlive 06:37 You can then unpack the tarball by "tar -xvvzf install-tl-unx.tar.gz" and change into the newly unpacked directory 06:37 Once in there, run "sudo ./install-tl". The defaults it selects are normally quite good, but you can remove the documentation packages for a smaller download (the full one is about 2.5G!) 06:37 This will take quite a while, so be patient. 06:37 Once this is done, change into the ubuntu-manual directory, and run pkgs/install-pkgs.sh script 06:37 That's the Karmic-specific stuff out of the way. Lucid folks can just install texlive-base. 06:37 It should hopefully find everything; if it doesn't, and you're on Lucid, it's safe to install the suggested ones 06:37 If you're on Karmic, however, something has gone wrong with the installation. 06:37 Drop into #ubuntu-manual and we'll try and help you out. 06:37 So now you've got all the texlive 2009 packages installed, you can build the manual. 06:37 OK, you can start listening again 06:37 This is really easy once you've got everything installed 06:37 This is easy: just type "make ubuntu-manual-LANG.pdf", where LANG is the language code (corresponding to one of the .po files in po/) you'd like to build. 06:37 (so, to build the French version, "make ubuntu-manual-fr.pdf") 06:38 All being well, the manual will now build, and you can see the fruits of your labour 06:38 You may need to install some font packages. The ones you need will be in the error message from LaTeX, and can be found in a package starting with ttf- 06:38 If you're having problems, ask godbyk. He should know what you need to do 06:38 Any questions on that? 06:38 That's pretty much all I have to say about translations. 06:40 I hope this has helped you to understand how the translations, and maybe do some translations for yourself! 06:40 Thanks a lot for coming along. 06:40 I've now got 20 minutes to answer any questions you've got left 06:40 I was obviously very comprehensive :) 06:50 OK, thanks everyone for coming 06:58 Next is IlyaHaykinson_ with a talk on Writing Style 06:58 === ChanServ changed the topic of #ubuntu-classroom to: Welcome to the Ubuntu Classroom - http://wiki.ubuntu.com/Classroom || Support in #ubuntu || Upcoming Schedule: http://is.gd/8rtIi || Event: 48 Hours of Ubuntu Manual Learning - Current Session: Writing style - Instructor: IlyaHaykinson || Questions in #ubuntu-classroom-chat hm, we need to give voice to ClassBot 07:01 ok, folks, we'll start in 2 mins 07:02 [SLIDE 1] 07:02 You can also see the slides at http://www.slideshare.net/ilyah/writing-the-ubuntu-manual 07:03 Alright. Welcome, folks. 07:06 Agenda: [SLIDE 2] 07:06 In this talk, we'll chat about how difficult it is actually to write a good manual 07:06 We'll consider what kind of an audience we're writing for, and what that means to us when writing it. 07:07 We'll discuss what our combined voice should be -- how should we relate to the reader? 07:07 And we'll briefly chat about some desktop conventions that you should use when writing. 07:07 Please feel free to ask questions, but I'll try to take them all at once in the breaks between sections. 07:07 Writing a Manual: Challenges -- [SLIDE 3] 07:08 There's a lot to be decided when writing a manual for an open project of the size of Ubuntu 07:08 we need to figure out what we include -- and, more importantly, what we leave out. 07:08 we've got to decide on grammar -- British? United States? International? what about non-English? 07:08 we need to decide on the voice -- should we be humorous? serious? playful? 07:09 we need to understand the audience that we hope will read the manual, and use that information to decide how to present the information. 07:09 finally, some pratical limitations come up -- we cannot include 1000 screenshots (the file size will be too large, it will take too long to take screenshots, etc) 07:09 so, we compromise on all of these points. 07:10 for Content, we decided to cover only the core of the Ubuntu Desktop. 07:10 for Style, we picked a relatively serious tone, and a grammar that is similar to the Ubuntu Docs team 07:10 for our Audience, we decided to go after new computer users and people new to Ubuntu -- this meant that we did not dive very deep, but provided enough information to let people accomplish some key tasks in the simplest way. 07:10 and, again, practical limitations guide us throughout. 07:10 Writing Challenges: Other Sources -- [SLIDE 4] 07:11 When writing a manual, we need to understand that almost everything that we write about has already been covered by documentation. 07:11 Some of it is Ubuntu's own, some of it comes from the community. 07:11 To the degree that we can, we need to both read and then if possible _copy_ the documentation. 07:11 This copying is limited by fit -- some of the documentation will not work for us when copied. 07:11 For example, Ubuntu's documentation is mainly oriented at specific tasks -- it rarely provides a high level overview to help a user get started and get the larger picture 07:12 instead it dives directly into specific pages and screens to help answer one particular question. 07:12 We can certainly use it to understand how something works, and can copy parts of it, but we cannot copy it in entirety -- it would not match our style or voice 07:12 The GNOME project also has a lot of documentation. Their docs are actually well-created -- well written, organized in a logical way, etc. 07:12 However, GNOME licenses using the GNU Free Documentation License, which is not compatible with the Creative Commons - Attribution - ShareAlike license that we are using. 07:13 Thus, we can read the GNOME docs, but not use them directly in the manual. 07:13 Finally, there's community documentation. Such great things like the ubuntuguide.org or any other fan pages 07:13 or user guides 07:13 Most of these are great, but most of these are also not perfect since they target experts, and not beginners 07:13 We can read them and use them in our troubleshooting sections, but not really much else. 07:14 Any questions before I move on? 07:14 ok, moving on to Our Audience 07:14 Next slide - Our Audience: New Users -- [SLIDE 5] 07:14 We've decided to focus our writing on people who are new to Ubuntu 07:15 this may also mean that they're new to computers in general 07:15 either actually new users, or just very much beginners in their skill set 07:15 For our writing, we assume that the reader knows how to use a GUI -- they know how to use the mouse, or the keyboard 07:15 they also know that there are windows and buttons and scrollbars, and generally know how to use them to get around. 07:15 They may not know that their monitor is a monitor -- lots of people call their monitor their "computer" 07:16 i've even seen people call the actual desktop the "brain" 07:16 they will not know what ethernet is, necessarily; we need to remind them about wifi. 07:16 they will certainly not know anything more complex than that. 07:16 Next slide - Our Audience: New Users -- [SLIDE 6] 07:16 So, we need to be very careful when writing to not include any jargon in our presentation. 07:16 We need to explain, in detail, everything that we mention. 07:17 we can say "click the ____ button", assuming that the person will see the button 07:17 and knows how to click 07:17 but, for example, we need to say "Click-and-hold your mouse button at the edge of the window, and drag your mouse to resize the window" 07:17 instead of assuming the person knows what to do. 07:17 we need to define all terms; in a section on printing, we may want to say "Your printer may connect to your computer using a USB cable. Before starting, plug your printer into an available USB slot on your computer." 07:17 because a user may not remember on their own 07:18 We need to be very precise in our language -- need to know the terms for everything in the operating system. 07:18 so that when we refer to a piece of the user interface, we are consistent with other documentation 07:18 and consistent with ourselves 07:18 I will cover some terms later, but there's a great guide for GNOME user interface terms at http://library.gnome.org/devel/gdp-style-guide/stable/gnome-glossary-desktop.html.en 07:18 Most importantly, when writing for new users, we need to start with very simple things. We can move on to more advanced topics only after we've repeated the simple things again, and again, and again. 07:19 For example, we may start with talking about "Click-and-hold ... to resize" at first. 07:19 And by the end of a section, just say "resize" since we can assume the user has learned a bit already. 07:19 Next slide - Our Audience: Eager to Learn -- [SLIDE 7] 07:19 We are writing for people who picked up a manual. 07:19 People who have either already installed, or interested in installing Ubuntu -- which is saying that they're a captured audience, in a way. 07:20 They are somewhat task oriented in their day to day computing life -- they have no interest in learning the underlying ways things work in Linux or Ubuntu 07:20 any more than they want to know how the Win32 API works, or that MacOS is based on Darwin. 07:20 but they _do_ care to know how to make their printer print. or their scanner scan. or their presentation saved as PDF. 07:20 because those are actually their goals. 07:21 Since we are writing a manual, they may read the manual in fairly large chunks -- many pages at once -- instead of just as a reference guide where they use the index, jump to a page, read a tiny bit, and close it. 07:21 Next slide - Our Audience: Eager to Learn -- [SLIDE 8] 07:21 So, the recommendations are aligned with this eagerness to learn 07:21 we need to keep a narrative that turns a novice into a knowledgeable user over time. 07:21 As i mentioned, start simple -- progress to complex 07:22 We need to think in terms of these user tasks -- title each section with a particular task, and cover only that one task. 07:22 Don't just write how to do something -- make sure you have some indication _why_ someone would want to do something 07:22 Use asides, callouts, and notes in the margins to keep the advanced users happy, too (godbyk's talk on LaTeX will explain how to do this, technically, in the manual) 07:22 so if there's something that you think they _might_ want to know, after reading your manual, stick it in a margin note. 07:23 and if it's advanced, and they probably do not _need_ to know it, mark it as advanced. 07:23 Finally, do not patronize -- do not be condescending to the user. 07:23 The user wants to get some work done. 07:23 they do not need to be told something is "simple" 07:23 it may not be simple for them, and  they'll assume you (the writer) is better than them 07:24 and is taunting them with your betterness 07:24 don't tell them to "just click on" something -- they may take a minute to find that something, and again will feel like you're saying their dumb if it took them a while to find it. 07:24 in general, assume that you're giving a list of instructions on how to reach a particular physical address. 07:24 you tell people "off the highway, third light, make a right; past the gas station, make a left. then, it's the second building on your right" 07:25 that same fairly serious tone should be kept when talking to the user. 07:25 Next slide: Our Audience: International -- [SLIDE 9] 07:25 We are writing in English. But we've got a lot of translations (40+). Plus, even for people reading in English, some may not have it their native language 07:25 Plus, not all humor or witty comments are universal. 07:25 Next slide: Our Audience: International -- [SLIDE 10] 07:26 So, we need to use _very_ simple language. 07:26 Always use a simpler synonym for a word. 07:26 Not "transform" but 'change'. Not "alphabetize" but "put in alphabetical order" 07:26 Use simple phrases as much as possible. Shorter sentences are better. 07:26 If you have lots of words in dependent clauses etc, it will make it hard to translate and understand. 07:27 So use a period instead of a semicolon. List out steps in an enumerated list (1. click here. 2. click there. 3. enter some text. etc) 07:27 Assume that you are speaking to an advanced English learner, basically. 07:28 As a design decision, we're using American spelling and grammar for the manual. This is consistent with the Ubuntu documentation team and other Ubuntu/Canonical guidelines. 07:28 Also, use short paragraphs. If a paragraph has more than 5 sentences, it's probably too long. 07:28 Repeat yourself. So "You may want to use a calculator to help with a calculation. To use a calculator in Ubuntu, click ..." 07:29 Saying this in two phrases helps solidify the concept, and prevents ambiguity. 07:29 Any questions before moving on to Our Voice? 07:29 Next slide: Our Voice: Confident -- [SLIDE 11] 07:29 We are writing a manual, and we are the experts. Our readers are expecting us to be condident in our opinions. 07:30 so, when writing, use language that says that you are condident in what you are saying. 07:30 When giving opinions, state them as facts. 07:30 "With Ubuntu, you can print, scan and email documents" 07:30 no need to say "With Ubuntu, you might be able to ... if you have an internet connection and your drivers work" 07:31 However, I suggest that you consider Ubuntu to not be perfect. 07:32 when talking about windows opening, when giving instructions, I generally prefer saying "Ubuntu should open..." instead of "Ubuntu will open..." 07:32 This way, if something doesn't work quite correctly, we are not lying. 07:32 My personal guideline is that if something is certain to work, use "will". If there's a chance for failure (user clicks in the wrong place, or has a different configuration) use "should" 07:32 Next slide: Our Voice: Direct and Calm -- [SLIDE 12] 07:33 Write as if you're conversing with a reader, face to face. "You may want to use a calculator. To open the calculator, click..." 07:33 or "If your email administrator advised you to use IMAP..." 07:33 As part of being calm, avoid generating excitement for Ubuntu. 07:33 we are writing a manual, not a marketing slick -- no need to use words like "best", "easiest", "simplest", "amazing" etc 07:34 instead of "In ubuntu, it's easy to do X...." say "In Ubuntu, you can do X by...." 07:34 Next slide: Our Voice: Slightly Opinionated -- [SLIDE 13] 07:34 all that said, we are _SLIGHTLY_ opinionated. Slightly <------ this is an important word 07:34 in the Linux world, there is always more than one way to do things. however, not in our manual. 07:34 in our manual, there are only a few ways. 07:35 First, we should recommend the _official_ graphical way to do something. 07:35 Second, we may recommend any simple variation or common shortcut to doing this. 07:35 But we stop there. We don't tell people the twenty ways to install software -- just the Software Center and Synaptic. 07:35 This is because we have a bias towards using the GUI, and being simple. 07:35 We also try to steer people away from bad decisions, lightly. So "You may want to pick a long password if you are worried about security." 07:36 but can also allow them the choice to make worse decisions, if there's a good reason. "If you are the only one who will be using your computer, you can decide to automatically log in without entering your password" 07:36 Next slide: Our Voice: Aligned with Users -- [SLIDE 14] 07:36 When writing sections, consider how users will want to use what you are describing. 07:37 then, name the section with a gerund form of a verb. 07:37 "Using the calculator" or "Reading your email", or "Scanning images" 07:37 setting a topic like that also helps make sure you limit the section to just one idea. 07:37 In each section, mention _why_ a user may want to do that. 07:37 for example 07:37 "If you have a photograph that you want to send over email or post online, you may want to scan it into your computer. To scan images, you will need..." 07:37 a quick intro to a section can provide the _why_ a user may want to do something that is vital to establishing context fo rthe user. 07:38 if you just say "to scan images, you will need..." -- you are not letting a user know what possible reason they will ever have that they should read the following paragraph. 07:38 <- Any questions before I move on to Conventions? 07:38 Next slide: Conventions: Attribution -- [SLIDE 15] 07:39 We have a few conventions for the manual. The main one is to write it about Ubuntu, and not about Linux. 07:39 yes, we mention in an early chapter that Ubuntu is based on Linux. 07:39 but the rest of actions should be attributed to Ubuntu. 07:39 In general, people will perceive the login process, the desktop, Nautilus, panels, window manager etc as being "Ubuntu" 07:40 utility applications should also be "Ubuntu" for purposes of this manual. 07:40 bigger application packages (Ephiphany, Totem, Open Office) should be considered big enough to warrant their own attribution. 07:40 er, Empathy :) 07:40 so for example, "The Ubuntu calculator lets you...", but "Open Office lets you..." 07:40 Also, always ensure active voice. 07:41 If you find yourself writing "It is possible to...", or "...will be opened by..." then chances are you are writing passively 07:41 when providing steps to accomplish some task, write imperatively. "Click the OK button", "Choose File, then Save to save a document" 07:41 but in general, to use an active voice, write "X will do Y" -- "Ubuntu will open a window", "You can click the OK button." 07:42 Next Slide - [SLIDE 16] 07:42 Here we'll briefly run through some common GUI terms. 07:42 button and check box -- please note that you click OK, click Cancel, click Forward, but Click _on_ other buttons (Click on Add, click on Remove Entry, etc) 07:43 check box is two words, and you either _choose_ and _option_, or _select_ / _deselect_ a check box. 07:43 I prefer "option", when possible. 07:44 Next Slide - [SLIDE 17] 07:44 nothing special here, please just review the list for proper usage 07:44 Next Slide - [SLIDE 18] 07:44 please note that double-click (and right-click and middle-click and triple-click) use a dash between the words 07:45 and you always double click _on_ something 07:45 you never drag and drop, but you drag X to Y. 07:45 Next Slide - [SLIDE 19] 07:45 A "field" is a generic term for text boxes, and other input widgets 07:46 for list boxes, I prefer to _select_ from them, but you can _choose_ as well. 07:46 note that the top menubar in Ubuntu is called Main Menu 07:47 also, that a menubar is one word. as is scrollbar, statusbar, titlebar, toolbar 07:47 you Choose from a menu 07:47 [SLIDE 20] 07:47 note the difference between login and log in -- login is a noun or adjective ("remember your login", "start the login process") but log in is the verb -- "please log in to Ubuntu" 07:48 same with log out, shut down, etc. 07:48 for radio button widgets, please use "option" 07:48 Last Slide - [SLIDE 21] 07:48 note that you click _on_ a tab 07:49 and that you _use_ a text box to _specify_ -- however _enter_ something in the /name/ field is better still 07:49 <<-- This concludes my presentation. Any questions? 07:49 Please see the terms document -- http://library.gnome.org/devel/gdp-style-guide/stable/gnome-glossary-desktop.html.en -- for more info 07:50 Or the list of user actions in GNOME -- http://library.gnome.org/devel/gdp-style-guide/stable/gnome-glossary-user-actions.html.en -- for action names 07:50 Finally, for more tips on writing for an international audience, see http://tc.eserver.org/21590.html 07:50 Alright, thank you for attending! next session in 9 minutes! 07:51 === ChanServ changed the topic of #ubuntu-classroom to: Welcome to the Ubuntu Classroom - http://wiki.ubuntu.com/Classroom || Support in #ubuntu || Upcoming Schedule: http://is.gd/8rtIi || Event: 48 Hours of Ubuntu Manual Learning - Current Session: The project and social media - Instructor: humphreybc || Questions in #ubuntu-classroom-chat so what's the attendance like? 08:01 (join #ubuntu-classroom-chat to talk) 08:01 ill just wait a couple more minutes so i can finish mt icecream :P 08:03 wont be long :P 08:06 [SLIDE 1] 08:06 http://www.facebook.com/pages/The-Ubuntu-Manual/266794861575?ref=ts 08:06 how many people are actually here? could those that are here please say so in #ubuntu-classroom-chat 08:08 ok cool, sorry about the delay ive almost finished my ice cream :D 08:09 okay so we'll make a start 08:11 sorry about the delay, i've got my hand back now instead of holding a magnum 08:11 excuse me if i don't really know what i'm doing, i've been up since 3am this morning (it's now 9:15pm) 08:11 also i don't really have a plan for this session :) 08:11 okay so 08:12 social media in ubuntu projects 08:12 using web 2.0 to our advantage 08:12 why social media is important to us: 08:12 [SLIDE 2] 08:12 social media increases publicity about a project. this is good because it not only encourages more contributors to help, but it also makes sure more people actually download our end product - which is want we want! 08:13 media attention/blog posts inspire our team to work harder because they feel they are important 08:13 you are much more likely to feel good about something if your contributions are rewarded with publicity or commendation 08:14 and you are much more likely to like to be associated with a project that is visible and popular among the community 08:14 let me take some examples 08:14 the ubuntu manual project, and the boot team working on the new plymouth boot for Lucid 08:14 the boot team and plymouth are probably more important, more technical and more interesting than UMP 08:15 but we never hear anything about them, apart from the odd update 08:15 but then there's UMP, which is younger than the boot team and probably not as important or as interesting or as fundamental to the operation of Ubuntu 08:16 but because we have generated a huge amount of hype and publicity, we've had hundreds of contributors come forward willing to help, and we've been able to do 4x as much stuff as I ever envisioned us doing 08:16 I originally planned this manual to be 50 pages long, a few screenshots, written in open office and only available in english 08:17 now we've got this huge project, 250+ contributors, available in 40+ languages, 200 pages long, thousands of localized screenshots and we're even writing our own python program for it! 08:17 now none of this would have been possible if it wasn't for the extra contributors we get from: 08:17 blog posts 08:18 planet ubuntu posts 08:18 facebook page 08:18 twitter page 08:18 identi.ca page 08:18 Planet Ubuntu Manual - http://planet.interesting.co.nz 08:18 Running events like this 08:18 Ubuntu Forums survey 08:18 so, what i'm trying to say, is that with social media, you can create more publicity and attention, with more attention you get more people, with more people you not only get more help but you also get more ideas and feedback - which in turn creates a better overall product. 08:19 Not enough Ubuntu teams, or open source projects in general, advertise enough. 08:19 Loco teams should have facebook pages, the Boot team should have facebook pages and regular events to inspire people to help 08:19 also, our team works harder because they have an expectation to live up to now 08:20 if there wasn't hundreds of people commenting on blog posts saying "i can't wait for this manual!" "Ubuntu really needs this!" etc, then we wouldn't be as inspired to do a good job 08:20 [SLIDE 3] 08:20 I'll just show  you our facebook/twitter and identi.ca pages real quickly so you can get an idea of how we use them 08:21 also, join them! spread them to your friends! 08:21 http://www.facebook.com/pages/The-Ubuntu-Manual/266794861575?ref=ts 08:21 I like facebook the most. Why? Because it's suited to projects! It has the ability to schedule events where people can RSVP to, you can upload photos for people to look at, and you can post twitter style updates to keep everyone informed 08:22 oh yeah, that's another thing 08:22 transparency in a project is important 08:22 we're lucky in the open source world because everything is transparent anyway, but only if you do some digging 08:22 you could quite easily find out what the boot team are up to every day, and what they've done this day etc 08:22 but you'd have to do the looking yourself 08:23 why not make it easier by posting updates and keeping the community in the loop of your project? 08:23 by promoting transparency and keeping everyone informed, we not only hold interest, but we also show that the community and people "outside the team" are valued and important, which they are 08:24 we love feedback, we love criticism and I try to make that as clear as possible 08:24 okay, twitter 08:24 http://twitter.com/TheUbuntuManual 08:24 Twitter is, as most of you know, roughly the same as facebook but without the images and events and extra stuff 08:25 it's still popular though, of course. we have 119 followers! 08:25 and we have 177 in facebook! 08:25 so wait a second, let me get this straight 08:25 we're a team of people writing a book for an operating system that has a 1% market share 08:25 yet we have almost 200 fans on our facebook page? 08:25 another thing that projects need to do is run events like this 08:26 they achieve a lot of things 08:26 they give blogs content and news to write articles on, people read these articles and remember the project 08:26 they realise it isn't dead (which happens in the FLOSS world a lot) 08:26 these events also attract more contributors 08:26 and they inform people, they show that we're transparent and we value YOUR opinion 08:27 we've set all this up for you to come along and tell us what you think 08:27 jazz asked: will these lessons or classroom be posted so i can catch  up on what i've missed? 08:28 yes, they're all available on http://irclogs.ubuntu.com 08:28 I'll put up the exact logs on the 48 hours wiki page tomorrow :) 08:28 also, the slides are available in our bzr branch under "48hours" (tomorrow i'll change that folder to "help") 08:28 https://wiki.ubuntu.com/ubuntu-manual/48hours 08:29 So, how can you incorporate all this into your project, or your loco team? 08:29 easy, you just have to: 08:29 generate hype by creating facebook/twitter accounts 08:29 email blog sites and tell them about your project or team 08:30 email ubuntu members with a blog on Planet Ubuntu and ask them to give you some hangtime on the planet 08:30 run an event to explain what your project or team does 08:30 if you're a loco team, attach yourself to a bigger project and ride off the wave that they're creating 08:31 and, be unique, be ambitious, be creative 08:31 be different 08:31 oh and read jono bacons book "The Art of Community" - it's available free www.artofcommunityonline.org/ 08:32 [SLIDE 4] 08:32 So, how can you help us? 08:32 you can help the project in a tonne of ways, from programming to artwork, to writing a chapter or editing one etc etc 08:33 but if you don't feel confident in those roles, we are still looking for someone to help me maintain the facebook and twitter and identi.ca accounts 08:33 the logo/screenshots need to be updated on those accounts, and we need constant tweets and updates to keep the hype reel rolling 08:33 but if you don't feel like helping the project directly, you can also do it indirectly 08:34 if you think our project is cool, tell your friends or your loco team 08:34 or, if you have some people who fit into our target audience (parents, family members, spouse etc), give them the current Ubuntu Manual PDF and ask them to read a bit. Ask them if it makes sense, if it's easy to follow 08:34 ask them how it could be better 08:34 and then email their comments to our mailing list or come into #ubuntu-manual on irc.freenode.net and tell us what they said! 08:35 sorry about the talk being a bit jumbled guys 08:35 i'm going to reorganize it and write it down properly, i'll make some better slides and then i might make a youtube video of it 08:35 but generalize it more for projects in general, not just UMP 08:36 okay, questions? :) 08:36 jazz asked: now these projects are they all volunteer, are there any paying gigs (as in career) 08:41 that's a good question. 08:42 the FOSS world runs on volunteering, but there are companies like Canonical and Novell who employ notable people from the community 08:42 there's no guarantee you'll be employed by them for working on ubuntu 08:42 it's not meant to be an incentive, but it's a possibility 08:43 I do know that if you're in IT, employers like seeing open source experience 08:43 be it volunteer or paid, all this stuff is quite acceptable as experience for your CV/resume. 08:43 yeah, it depends what you want to get out of it 08:44 I think if you're just doing it to get a job in the end, you'll never succeed. 08:44 You need to be genuinely interested in helping out the community, working towards a goal. In our case, or my case, I want to see Ubuntu's market share increase because I think it deserves to be used in the mainstream. 08:44 One of Ubuntu's biggest flaws is lack of education 08:45 the operating system itself is great, but it's ill-educated users that don't know about it or how to use it that's not helping our cause 08:45 also the fact that people have been brought up on windows/mac and they're used to that. We need to make it easier for them to switch 08:45 But in the end, the average consumer is always wanting to get more "bang for their buck" 08:46 so if you have a $400 operating system in one hand, and a$0 one in your other hand that does all the same things as the $400 one, why wouldn't you choose the free one? 08:46 the problem we have, is that people have one eye blinded, so they can't see the free operating system in one hand 08:47 we need to open that eye and explain to them why it's better 08:47 and we need to help them adjust. it's not their fault that Microsoft has a monopoly and has forced us Windows all through school and in our workplace 08:47 but that's what they are used to because this is exactly what Microsoft has done 08:48 so we need to teach them how to convert easily 08:48 and that's what we're trying to do with UMP 08:48 === ChanServ changed the topic of #ubuntu-classroom to: Welcome to the Ubuntu Classroom - http://wiki.ubuntu.com/Classroom || Support in #ubuntu || Upcoming Schedule: http://is.gd/8rtIi || Event: 48 Hours of Ubuntu Manual Learning - Current Session: LaTeX for authors and translators - Instructor: godbyk || Questions in #ubuntu-classroom-chat [SLIDE 1] http://kevin.godby.org/ubuntu-manual/talks/latex-slides/00.html 09:00 Hello, everyone. 09:01 This talk will cover the basics of LaTeX: what you'll need to know as an author, editor, or translator. 09:01 You can get handouts of this talk here: http://kevin.godby.org/ubuntu-manual/talks/latex-handout.pdf 09:01 [SLIDE 2] http://kevin.godby.org/ubuntu-manual/talks/latex-slides/01.html 09:01 In this talk, we'll cover a basic overview of how the Ubuntu Manual project uses LaTeX. 09:02 [SLIDE 3] http://kevin.godby.org/ubuntu-manual/talks/latex-slides/02.html 09:02 By this point, I'll assume that everyone knows the idea behind the Ubuntu Manual Project. 09:02 We're aiming to produce a manual for beginning users in a multitude of languages. 09:03 One of the most important tools we use to accomplish this is LaTeX. 09:03 [SLIDE 4] http://kevin.godby.org/ubuntu-manual/talks/latex-slides/03.html 09:03 LaTeX has been around for over 20 years and it employs an underlying typesetting engine (TeX) that has been around for over 30 years. 09:03 LaTeX code is similar to HTML in that you can think of it as a markup language. 09:04 The .tex files contain plain text -- all the word you want to appear in the PDF -- plus some markup that tells the typesetting program how to format the text and where it goes on the page. 09:04 Unlike HTML, though, TeX is a full programming language. Luckily for you, most of the programming work has already been done, so you won't have to worry about that side of things. 09:05 [SLIDE 5] http://kevin.godby.org/ubuntu-manual/talks/latex-slides/04.html 09:05 All of the code is stored in .tex files. 09:05 These files are just text files and can be read and edited using your favorite text editor. 09:06 There are also some more advanced editors designed just for LaTeX (including Kile and TeXMaker). Most editors have plugins to help with LaTeX code. 09:06 For most of the code you'll be using with our manual, however, a plain text editor will serve just fine. 09:07 LaTeX commands begin with a backslash (\). 09:07 Some LaTeX commands take no arguments (like the \dash command we'll see later}, 09:07 while others take 1 or more arguments. 09:07 An example of a command and its argument is show on this slide: the \textbf command. 09:08 The \textbf command takes a single argument: the test that is should set in bold-faced type. 09:08 [SLIDE 6] http://kevin.godby.org/ubuntu-manual/talks/latex-slides/05.html 09:08 In editing this manual, we'll avoid using the low-level bold, italics, etc. commands and instead use semantic markup. 09:09 Semantic markup lets us create new commands that can apply styles consistently across the entire manual. 09:09 [SLIDE 7] http://kevin.godby.org/ubuntu-manual/talks/latex-slides/06.html 09:09 For instance, instead of putting each menu name in bold, we've created a \menu command. 09:10 If we were to decide later that we wanted menu names to appear in italics instead, we just have to edit one line of code in the style sheet instead of searching the entire manual for any menu names. 09:10 [SLIDE 8] http://kevin.godby.org/ubuntu-manual/talks/latex-slides/07.html 09:11 While you can generally get away with simple typing whatever you like into the .tex file and having LaTeX make a nice-looking PDF from it, there are a few special characters you should be aware of. 09:11 The most common "special character" is the quotation mark. 09:12 LaTeX knows about quotation marks -- it uses what are sometimes called "smart quotes" or "curly quotes". 09:12 That is, the opening and closing quotation marks do not appear the same in the final document. 09:12 When you're editing the .tex files, opening quotation marks are entered using two "backticks" or grave accents. 09:13 The closing quotation marks are entered using two apostrophes. 09:13 So quoted material looks like this''. 09:13 Another special character you'll find in the manual is the dash. 09:13 We use the dash to interrupt a sentence -- Hi, mom! -- or to help place emphasis on an important point. 09:14 When we started writing the manual, we manually entered the dashes using three hyphens --- like this. 09:14 But I've recently written a \dash command (which that no arguments) to do this for us. 09:14 Using the \dash command allows us to use the proper dashes depending on the language. 09:14 In US English, we use an em dash---like this---surrounded by no spaces. 09:15 However, in the UK and elsewhere, they use an en dash -- like this -- surrounded by a small space. 09:15 As you're editing the manual, if you see an em dash written as ---, change it to \dash. 09:15 [SLIDE 9] http://kevin.godby.org/ubuntu-manual/talks/latex-slides/08.html 09:15 There are another few characters that LaTeX considers special. These characters are normally used in LaTeX syntax. 09:16 If you want one of these characters to appear as-is in the final PDF, put a backslash (\) in front of that character. 09:16 If you want a backslash character itself to appear, you will need to use the \textbackslash command. 09:17 (The \\ command actually inserts a line break instead of printing a backslash as you might expect.) 09:17 [SLIDE 10] http://kevin.godby.org/ubuntu-manual/talks/latex-slides/09.html 09:17 The document structure of the manual has been fairly well established by this point. 09:18 However, I wanted to mention these commands briefly so you'll know what they mean when you see them. 09:18 Each of these commands starts a new part/chapter/section of the document. 09:18 They each take a single argument -- the name of the part/chapter/section. 09:18 The name is automatically formatted appropriately and put into the PDF. 09:18 These commands also add the entries to the table of contents automatically. 09:19 [SLIDE 11] http://kevin.godby.org/ubuntu-manual/talks/latex-slides/10.html 09:19 LaTeX doesn't really care if you want to write a paragraph on multiple lines. It will piece them back together into a paragraph for you. 09:19 To tell LaTeX that you want to start a new paragraph, just leave a blank between paragraphs. 09:20 We use short notes in the margin of the manual to tell the reader where to find more information about a topic, either online or in another part of the manual. 09:20 To create these short notes, use the \marginnote command. 09:20 Just tell the \marginnote command what text you'd like it to place in the margin and it'll take care of t for you. It's magic! 09:21 [SLIDE 12] http://kevin.godby.org/ubuntu-manual/talks/latex-slides/11.html 09:21 One more special character that you should take note of: the percent sign (%). 09:21 The percent sign starts a comment. 09:21 LaTeX will ignore the percent sign and everything on the line after it. 09:21 This is useful for making notes to yourself or another editor. TODOs or FIXMEs, for instance. 09:22 If you want a percent sign to appear in the PDF, however, you'll have to precede it with a backslash character. 09:22 [SLIDE 13] http://kevin.godby.org/ubuntu-manual/talks/latex-slides/12.html 09:22 When we're providing instructions for the readers, we reference a lot of GUI elements: menu, buttons, windows, checkboxes, etc. 09:23 Each of these elements has its own command to help keep their appearance consistent throughout the manual. 09:23 The \menu command is used to display menu names and menu items. 09:23 To separate menu items, use the \then command. 09:23 As you can see, writing \menu{Applications \then Accessories\then Calculator} will produce the text "Applications > Accessories > Calculator". 09:24 The \menu command used to be named the \nav command. 09:24 If you encounter the \nav command while editing the manual, please update it to use the \menu command instead. 09:24 Similarly, there was a \menuitem command. This should also be updated to \menu. 09:25 vdquynh asked: Is the blank space before "\then" optional or not? 09:25 vdquynh: The space is optional, yes. 09:25 The \then command will try to remove any extra space around it before printing the arrow. 09:25 Are there any other questions about the \menu or \then commands? 09:26 [SLIDE 14] http://kevin.godby.org/ubuntu-manual/talks/latex-slides/13.html 09:26 Here is a list of the other GUI element commands we have. 09:26 One other outdated command is the \option command. This should be changed to the \checkbox command if you see it. 09:27 Are there any questions about any of these commands, what they refer to, or when they should be used? 09:27 [SLIDE 15] http://kevin.godby.org/ubuntu-manual/talks/latex-slides/14.html 09:27 In the second part of the manual -- the advanced part -- we introduce a few useful terminal commands. 09:28 To display the command prompt, user input, and terminal output, we have a special environment that wraps around these commands. 09:28 The terminal environment is started with the command \begin{terminal} and finished with the command \end{terminal}. 09:29 vdquynh asked: Could you put somewhere the list of commands to be replaced? like \option should be replaced by \checkbox, etc. ? 09:29 vdquynh: Yes, I will compile a list soon and post it to the mailing list. 09:29 Inside the terminal environment, all of the text is printed in a monospaced font. 09:29 The \prompt command simply prints a user-level bash prompt ($). 09:30 For printing root prompts (#), you can use the \rootprompt command. 09:30 Any time the user is typing something into a terminal, you should put that text inside a \userinput command. 09:30 The terminal output can by typed like normal text. 09:31 Are there any questions about the terminal environment or related commands? 09:31 [SLIDE 16] http://kevin.godby.org/ubuntu-manual/talks/latex-slides/15.html 09:31 There are two different types of lists that we use in the manual: numbered lists and bulleted lists. 09:32 The only difference (in the code) between the two lists is their names. 09:32 The bulleted list is called 'itemize', and the numbered list is called 'enumerate'. 09:32 You start and end a list with the \begin and \end commands as shown. 09:32 Each item in the list starts with the \item command. 09:33 Are there any questions about the list environments? 09:33 [SLIDE 17] http://kevin.godby.org/ubuntu-manual/talks/latex-slides/16.html 09:33 vdquynh asked: is there a limit in the number of characters for any \item of the list? 09:33 vdquynh: There is no set limit; you can ramble on for as long as you like. 09:34 There are some practical considerations that may interfere if you're typing a novel as one list item, however. :-) 09:34 dvd asked: can you control the first number in the list? 09:34 dvd: You can, if necessary.  Do you have a specific instance in mind where you need to do this? 09:35 dvd asked: where the list is broken with a paragraph then continued 09:36 Gotcha.  It will depend on the reason for stopping in the middle of the list.  If you encounter a situation where you'd like to do this, find me on IRC in #ubuntu-manual or email the list and I can help you out. 09:36 Similar to HTML, we can include hyperlinks in the PDF. 09:37 We have a couple commands that help cross-reference other chapters and sections in the manual. 09:37 To cross-reference a chapter, use the \chaplink command. 09:37 To cross-reference a section, use the \seclink command. 09:37 Each of these commands takes a single argument: the chapter/section label. 09:38 To find the label for a specific chapter or section, open the .tex file containing that chapter/section. 09:38 Immediately after the \chapter or \section command, you will see a \label command. 09:38 The argument to the label command is the same argument you'll use with the \chaplink and \seclink commands. 09:38 All of the chapters have been assigned labels already. 09:39 Only a few of the sections have. 09:39 If the section you want to link to doesn't already have a label, you can create one. 09:39 Right after the \section{Why Linux Is Awesome} command, add a new command: \label{sec:why-linux-is-awesome} 09:39 The style we use to create the labels is to prefix the label with "ch:" for chapters and "sec:" for sections. 09:40 Then follow that prefix (no spaces!) with a short version of the chapter/section names. 09:40 Each 'word' should be separated by a hyphen. 09:40 vdquynh asked: I'm a bit confused here : in "\chaplink{ch:installation}" where is the "\label" command ? 09:41 vdquynh: The \label command appears after the \chapter command in the installation.tex file. 09:41 So the \label command is telling LaTeX, "Hey, call this chapter ch:installation." 09:41 Then the \chaplink command is used as \chaplink{ch:installation} to refer to the installation chapter. 09:42 Are there any other questions on \label, \chaplink, \seclink, or cross-referencing? 09:42 [SLIDE 18] http://kevin.godby.org/ubuntu-manual/talks/latex-slides/17.html 09:42 A few quick notes for any translators in the crowd. 09:43 When you're translating the text, make sure that you do *not* translate the LaTeX commands themselves. 09:43 If the word starts with a backslash (\), it should remain as-is. 09:43 Most of the arguments of the commands should be translated, however. 09:43 One exception to this rule is that you should *not* translate the labels -- that is, don't translate the arguments to the \chaplink, \seclink, \ref, or \label commands. 09:44 [SLIDE 19] http://kevin.godby.org/ubuntu-manual/talks/latex-slides/18.html 09:44 If you're translating it to a new language, send an email to the mailing list, please. 09:44 It gives me a heads up so I can be sure that your language is supported and can be compiled. 09:45 Are there any other questions about LaTeX? 09:45 vdquynh asked: I think not all fonts are supportive of every foreign language in Unicode ? Example: I often see horrible fonts used for Vietnamese in the liveCD 09:46 vdquynh: That's definitely true. 09:46 We're hand-selected each font on a per-language basis. 09:46 That way we can use the best fonts for that particular language. 09:47 If you have suggestions on good fonts to use for the language you're translating to, please email them to me or hit me up in #ubuntu-manual. 09:47 dvd asked: How do you see the output of what you are doing (never used latex before) 09:47 dvd: Good question! 09:47 If you want to see the English version of the manual, you can just run 'make' and it will generate a PDF called main.pdf. 09:48 If you want to see a translated version of the manual, run "make ubuntu-manual-LANG.pdf" 09:48 where LANG is the language code for your language. 09:48 (The language codes are listed in the po/ directory in our repository.) 09:48 To get started with running LaTeX, check out the ubuntu-manual code from the repository, then go into the pkgs/ directory and run the install-pkgs.sh script from the terminal. 09:49 This script will check to make sure you have the proper version of LaTeX installed along with all the required Ubuntu packages (mostly fonts) and LaTeX packages. 09:50 Are there any other LaTeX questions? 09:51 dvd asked: what about just installing latex from the repositories? 09:51 dvd: Unfortunately, the packages in the 9.10 repositories are too old what what we need. 09:51 The packages in the Lucid repositories may be new enough -- I haven't tested them yet. 09:51 Installation instructions for LaTeX are on the wiki here: https://wiki.ubuntu.com/ubuntu-manual/Prerequisites 09:52 Are there any other questions? 09:52 If you come up with questions later (or run into problems), you can find me on IRC in the #ubuntu-manual channel. 09:53 You can also email the ubuntu-manual mailing list. 09:53 I will try to keep the handout up-to-date and also keep the install-pkgs.sh script updated (in case we require more fonts/packages in the future). 09:53 If there are no other questions, humphreybc will be with you shortly to discuss how the Ubuntu Manual Project employs Launchpad. 09:54 vdquynh asked: Can we use the Texlive 2009 step by step installation described in prerquistes for Karmic ? 09:56 vdquynh: Yes, you sure can. 09:56 === ChanServ changed the topic of #ubuntu-classroom to: Welcome to the Ubuntu Classroom - http://wiki.ubuntu.com/Classroom || Support in #ubuntu || Upcoming Schedule: http://is.gd/8rtIi || Event: 48 Hours of Ubuntu Manual Learning - Current Session: Using Launchpad to manage the project - Instructor: humphreybc || Questions in #ubuntu-classroom-chat humphreybc is going to pass out and beg off his final talk. 10:02 If you missed it the first time around, you can read a transcript of the presentation here: http://irclogs.ubuntu.com/2010/02/22/%23ubuntu-classroom.html 10:02 You can grab a copy of his slides here: http://kevin.godby.org/ubuntu-manual/talks/launchpad.pdf 10:02 If you have any questions, you can email the Ubuntu Manual Project at ubuntu-manual@lists.launchpad.net 10:02 [SLIDE 1] 10:03 https://wiki.ubuntu.com/ubuntu-manual 10:04 humphreybc is going to pass out and beg off his final talk. 10:05 If you missed it the first time around, you can read a transcript of the presentation here: http://irclogs.ubuntu.com/2010/02/22/%23ubuntu-classroom.html 10:05 You can grab a copy of his slides here: http://kevin.godby.org/ubuntu-manual/talks/launchpad.pdf 10:05 If you have any questions, you can email the Ubuntu Manual Project at ubuntu-manual@lists.launchpad.net 10:05 humphreybc is going to pass out and beg off his final talk. 10:13 If you missed it the first time around, you can read a transcript of the presentation here: http://irclogs.ubuntu.com/2010/02/22/%23ubuntu-classroom.html 10:13 You can grab a copy of his slides here: http://kevin.godby.org/ubuntu-manual/talks/launchpad.pdf 10:13 If you have any questions, you can email the Ubuntu Manual Project at ubuntu-manual@lists.launchpad.net 10:13 === ChanServ changed the topic of #ubuntu-classroom to: Welcome to the Ubuntu Classroom - http://wiki.ubuntu.com/Classroom || Support in #ubuntu || Upcoming Schedule: http://is.gd/8rtIi || Event: 48 Hours of Ubuntu Manual Learning - Current Session: Finshing comments - Instructor: humphreybc || Questions in #ubuntu-classroom-chat === ChanServ changed the topic of #ubuntu-classroom to: Welcome to the Ubuntu Classroom - http://wiki.ubuntu.com/Classroom || Support in #ubuntu || Upcoming Schedule: http://is.gd/8rtIi === nhandler_ is now known as nhandler === mohi_away is now known as mohi1 === ChanServ changed the topic of #ubuntu-classroom to: Welcome to the Ubuntu Classroom - http://wiki.ubuntu.com/Classroom || Support in #ubuntu || Upcoming Schedule: http://is.gd/8rtIi || Event: Learning Django - Current Session: Learning Django - Day 1 - Instructor: mhall119|work || Questions in #ubuntu-classroom-chat good afternoon everyone 18:01 can I see a show of hands for who's listing? 18:02 going to give people a few minutes to arrive 18:04 in the mean time, I'll go over what this series of classes is going to be 18:05 there will be 4 session, 1 hour each over 4 days 18:05 the topics to be covered on each day can be found here: https://wiki.ubuntu.com/mhall119/classes/LearningDjango 18:05 it is meant to get you to the point where you have a working, functional Django application that you can continue to work on after this course is done 18:06 I will be taking a different approach from some other classes 18:07 we won't be writing a dummy program 18:07 nor will we be looking at an existing program 18:07 rather, we will be building a useful project that has the potential for continued development after the end of this class 18:07 and I hope that some of you will be a part of that continued development 18:08 specifically, we will be making a web application that will schedule session here in #ubuntu-classroom, so poor cjohnston won't have to spend so much time in wiki syntax ;) 18:08 are there any questions about the course or what we're going to cover 18:09 ? 18:09 Oh, I should mention, we are using the new Classbot https://wiki.ubuntu.com/Classroom/ClassBot 18:11 so if you start you question with "question: ", it'll automatically feed them to me 18:11 cjohnston asked: what is the timing schedule for the course? 18:11 I think we are scheduled for 1500 UTC to 1600 UTC today through Friday 18:12 cjohnston: is that correct? 18:12 1800 UTC 18:12 any other questions? 18:12 ok, moving on then 18:13 What is Django? 18:13 Django is a web application framework for Python 18:13 it provides a lifecycle for HTTP request processing 18:14 it also provides a very large collection of classes and libraries for making it easy to write web-based applications 18:14 as well as some of the best object-relational mapping I've used 18:14 combined with python, it makes it very easy to start writing an application, as well as maintaining and enhancing them 18:15 sorry, yes, 1800-1900 UTC 18:16 Django follows a model-view-controller style, which we will see a little of today and more in the following days 18:16 so, where can you get Django? 18:17 well, if you're lucky enough to be running Ubuntu, you can apt-get install python-django 18:18 otherwise you can download it from here: http://www.djangoproject.com/download/ 18:18 again, if you're lucky enough to be running Ubuntu, that's all you need to do, it will be installed in your python path automatically 18:19 if not, you will need to run the setup.py as instructed in the docs 18:19 I'm going to assume you all are running Ubuntu, or at least some distro that makes it easy to get Django, so I won't go into the manual setup 18:20 if you're curious about where django is installed run this: python -c "import django; print django.__file__" 18:21 if you're ever curious about how Django does something, the source is right there for you to inspect 18:22 any questions before we start creating our project? 18:22 for time, I've created a bzr repository that will walk through everything we're going to discuss 18:23 I'll give the commands you would use, but you don't need them this time around 18:23 okay, so the first thing you would do for a django project is "django-admin startproject $projectname" 18:25 for our example, I ran "django-admin startproject classroom_scheduler" 18:25 and if you run "bzr branch -r tag:day1.3 lp:classroom-scheduler" you will get a copy of what that created 18:26 if you "cd classroom-scheduler/classroom_scheduler" you will see the files that get created 18:27 manage.py is what you will use to control your django project 18:28 settings.py is where you configure your project (more on that next) 18:28 and urls.py is what you use to connect a URL to the code you want to handle that request 18:29 any questions so far? 18:29 okay, moving right along then 18:29 a project in django is composed of a collection of applications 18:30 if you look at the bottom of settings.py, you will see the INSTALLED_APPS array 18:30 this is what tells django what applications make up this project 18:30 and, as you can see, there's already some helpful applications installed for you 18:31 since a project doesn't do much without applications, our next step is to create an application for the functionality we want to add 18:32 to do that, you would cd to the project directory and run "django-admin startapp$appname" 18:32 for this example, I ran "django-admin startapp class" 18:32 and if you run "bzr pull -r tag:day1.4" you will get that 18:33 and now you should see a "class" directory under the project root 18:34 and under there you will see tests.py, views.py and models.py 18:34 remember I said that Django uses the model-view-controller pattern?  Well here is where that happens 18:35 first things first though, we need to configure our project 18:35 look at the top of settings.py in the project root, and you will see fields for configuring the database connection 18:36 this connection will be used throughout Django 18:36 sucotronic asked: is the tests.py some kind of unit testing? 18:36 I believe so, that's something new that I haven't done much with 18:37 hopefully there will be classes on unit testing in Django in the future 18:37 for this course, we're going to focus on views.py and models.py 18:37 so, our next step is to tell our project where to find out database and application 18:38 for testing, it's easiest to just use 'sqlite3' as the database, so you don't have to go through the trouble of setting up a server 18:38 so run "bzr pull -r tag:day1.5" and then look at settings.py again 18:39 or run "bzr diff -r tag:day1.4" to see the changes 18:39 all that I did was set the engine to use sqlite3, with the file classroom_scheduler.db as the database file 18:40 I also added 'classroom_scheduler.class' to the INSTALLED_APPS list 18:41 now that Django knows where to look for the database, we have to initialize it 18:41 to do this, run "python manage.py syncdb" from the project root 18:42 this will create the sqlite.db file, necessary tables, and initial values needed 18:42 it should prompt you for an admin user, just enter a username and password you'll remember 18:42 you should now see the file classroom_scheduler.db in the project's root 18:43 you can also "sqlite3 classroom_scheduler.db" if you needed to access it directly 18:43 alright, so now we have our project, our application, and our database, it's time to make it actually do something 18:44 any questions before we move on? 18:44 ok, moving on 18:45 a view in Django is nothing more than a function that takes an HttpRequest, and returns an HttpResponse 18:46 there's a lot more you can do in between, but that's the essence of it 18:46 so, we're going to create our first view 18:46 run "bzr pull -r tag:day1.6" 18:47 now, when you look at classroom_scheduler/class/views.py, you should see the function "class_home" 18:47 and you can see that it gets 'request' as an argument 18:47 and all I'm doing is stuffing some HTML into an HttpResponse object 18:48 note that I had to import HttpReponse from django.http at the top of views.py 18:49 view functions can be named anything you want, and for the most part can be placed anywhere you want, as long as python can find them 18:49 now that we have our view, we need to give the user a path to it 18:50 to do that, we map it to a url in urls.py in the project root 18:50 again, run "bzr pull -r tag:day1.7" to get the updatre 18:51 and "bzr diff -r tag:day1.6" to see what changed 18:51 in this case, it was only one line in urls.py 18:51 with Django, you use a regular expression to match the URL of a request, and then forward that request to the view 18:52 '^class/' will match a url like http://host:port/class/ 18:52 django will try each pattern in the urlpatterns list, and short-circuit on the first one that matches 18:53 so if you want to have both '^class/(.*)' and '^class/my_view/', you need to make sure the my_view one comes first 18:54 alright, now it's time to see what we've made 18:55 from the project root, run "python manage.py runserver" 18:55 if there aren't any problems, it should tell you that django is running on http://127.0.0.1:8000 18:56 and if you go to http://127.0.0.1:8000/class/ you should see the output of our view 18:56 and it should look something like this: http://growingupfree.org:8001/class/ 18:57 and that concludes our first day of learning django 18:57 are there any questions? 18:57 okay, well then please come back tomorrow for part 2, where we will start making our models 18:58 you can always email me at mhall119@ubuntu.com if you have any questions later 18:59 === ChanServ changed the topic of #ubuntu-classroom to: Welcome to the Ubuntu Classroom - http://wiki.ubuntu.com/Classroom || Support in #ubuntu || Upcoming Schedule: http://is.gd/8rtIi === tsimpson is now known as Guest5579

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!