text:
Cookbook talk:Table of Contents/Archive 3

index generation
The recipe index is kind of insane. It's a big page, and just getting bigger. Worse, it is unmaintainable. How can one tell if a recipe is missing? By looking, recipe by recipe, in that huge page. Probably a category would be better, but note that recipes really should appear under multiple names. I believe the term for this is a "permuted index". So a "Spicy Chicken" recipe would also appear as "Chicken, Spicy", etc. AlbertCahalan 03:24, 17 May 2005 (UTC)

 * Agreed, I was thinking about this but for slightly different reasons. Seems like uber-categorization is the "answer" though it's more difficult for newbies to maintain. So, for instance, we could have categories like so:
 * Category:Cookbook:Ingredient
 * Category:Cookbook:Technique
 * Category:Cookbook:Recipe
 * Category:Cookbook:Recipe:Poultry
 * Category:Cookbook:Recipe:Vegan
 * The cookbook seems like an ideal candidate for fairly strict categorization like this. Notice that I put the "Cookbook" namespace into the category -- I think this makes more sense if other wikibooks want to use the same categories (Category:Recipe, for example might be used in a technical setting like a HOWTO).
 * Of course, this requires tagging every recipe with the recipe category, but that seems like what we need to do to get an automatic index. Kellen 02:14, 22 May 2005 (UTC)

 * I think we really should have an giant global index for people to browse. I just don't think we should be trying to maintain one by hand. I want to see automatic generation of:
 * Toasted Cheese Sandwich
 * Cheese Sandwich, Toasted
 * Sandwich, Toasted Cheese
 * Vegetable Stew and Dumplings
 * Stew and Dumplings, Vegetable
 * Dumplings, Vegetable Stew and
 * Mussels with Potatoes
 * Potatoes, Mussels with
 * AlbertCahalan 03:45, 22 May 2005 (UTC)

 * Agreed that we shouldn't try to maintain one by hand. Automatic permutation of titles like that would be helpful, but there would be some odd cases:
 * Grandma's Pumpkin Pie
 * Pumpkin Pie, Grandma's
 * Pie, Grandma's Pumpkin
 * Odd? No, that's perfect. It's what you need if you half-way remember the name of a recipe. It's also good if you just want to browse through all the pumpkin pie or pumpkin recipes, eliminating the need for lots of obscure categories like "pumpkin pie". AlbertCahalan 18:44, 22 May 2005 (UTC)
 * We are facing two problems:
 * Finding recipes by major ingredient (e.g. Chicken or Pumpkin)
 * Easily distinguishing content within a namespace (Recipes from Cooking Techniques, or Stews from Breads)
 * For (1), a custom tag which created an index based on the tagged "major" ingredients would be good (so we could have a Chicken section); for (2) I think the existing category tags are enough, we just have to be more strict and thorough with them, which means a set policy to which new users can be pointed.
 * Kellen 04:10, 22 May 2005 (UTC)

 * The category problem is different. Indexing needs to be done automatically. For categories, we could use automatic suggestions. Imagine if it worked like autocompletion in a web browser URL entry area or in an email client "To:" area. Google has a beta of this for their site, letting you choose from common queries. See here (Wikipedia article), here (animated gif demo), and of course here (Google's beta). Tree-structured browsing, as is done on freshmeat.net for project categorization, could be somewhat helpful as well. Note that this all pretty much means that the categories need to be edited separately from the wiki text. AlbertCahalan 18:44, 22 May 2005 (UTC)

 * As a test, I created a couple of fake recipes:
 * Kellen:Fake Recipe 1
 * Kellen:Fake Recipe 2
 * Each of these is tagged with a namespace-enabled category, e.g. Category:Cookbook:Recipe
 * Unfortunately the automatic links to these categories don't work correctly, but if one goes to the page directly: Cookbook:Recipe Category page it seems to work. I'm not sure about how easy it is for us to ask for/get modifications to the wiki software to fix this, or to customize it to properly alphabetize things with respect to namespaces (i.e. not file everything under "Cookbook"), but seems to me that this could work. Kellen 04:50, 22 May 2005 (UTC)

categorization proposal
After looking at this a bit more, I think that categorizing all of our cookbook pages will be essential to indexing and browsing. I'd propose using a (fake-)namespace-enabled system, like so: This requires that: (2) means to have the correctly set the sort-order name; for "Chicken Salad", the link would be "Category:Cookbook:Recipe|Chicken Salad"
 * Category:Cookbook
 * Category:Cookbook:Recipe
 * Category:Cookbook:Recipe:Breakfast
 * Category:Cookbook:Recipe:Bread
 * Category:Cookbook:Recipe:Diet:Gluten_Free
 * Category:Cookbook:Recipe:Diet:Kosher
 * Category:Cookbook:Recipe:Cuisine:African
 * Category:Cookbook:Recipe:Cuisine:Caribbean
 * Category:Cookbook:Cooking_Technique
 * Category:Cookbook:Equipment
 * Category:Cookbook:Ingredient
 * 1) All existing pages in the cookbook be tagged with the approprite category (e.g. all recipes should minimally be in Category:Cookbook:Recipe)
 * 2) To be useful, all these category tags must be aliased properly

I realize that this is a very labor intensive process, but I believe it'll help readers immensely. The initial conversion of adding Category:Cookbook:Recipe to all pages linked from Cookbook:Recipes could be done with a bot.

More info about Categories is available On the mediawiki web site Kellen 20:19, 22 May 2005 (UTC)

 * We're seeing some rather serious problems with caching, and with the use of ":" in a category name. Until somebody fixes all the bugs, we should stay away from anything likely to trigger problems. Also, namespace problems have not been a problem with categories. It's better to keep things short and simple if we can. Before we start using lots of categories, we should have some sort of an autocompletion and suggestion mechanism in place. Otherwise, there's no way people will get something like Gluten_Free right on all the recipes. AlbertCahalan 20:28, 22 May 2005 (UTC)

 * I see the caching problem, what's the problem with ":" in a category name?
 * I don't think I was clear on my reasoning: I wanted to categorize things like this because it would allow us to have an automatically generated index listing for each item. For example, my Cookbook:Cardamom_Bread recipe could be tagged with:
 * Category:Cookbook:Recipe:Cuisine:Scandanavian
 * Category:Cookbook:Recipe:Bread
 * Category:Cookbook:Recipe:Vegan
 * And if a user browses to the main Category:Cookbook:Recipe, they'll see it linked in the main listing. If they browse to the "Vegan" or "Bread" subcategory, they'll see it listed there, and if they browse to "Cusine" then to "Scandanavian", they'll see it listed there.
 * The main advantage of this is that it centralizes the categorization of a recipe. Right now, we add a recipe, then add it to up to the bread page, to the recipes page, to the vegan_cusine page, etc. Using categories, we can just edit the page for the recipe and add it to all these places at once.
 * I share your reservations about the software, but I tend to think that we'll eventually have to do this sort of categorization anyway.
 * Kellen 20:58, 22 May 2005 (UTC)
 * Would anyone be opposed if I tagged all of the recipes from Cookbook:Recipes with the category Category:Cookbook:Recipe? Kellen 04:11, 25 May 2005 (UTC)
 * I do, for several reasons. First, no other category is named like that. Conflicts have not been a problem. Second, that's a lot of edits. You'd better get near-unanimous agreement that this is right before proceeding. Third of all, will this get us a friendly index? It won't be permutated. Fourth, over on the Commons, people have been saying nasty things about the performance of categories and the effects they have on the wiki servers. Perhaps using a template might be wise. Sorry to be so down about the idea, but I'd rather we all think this through carefully before editing like mad. AlbertCahalan 11:36, 25 May 2005 (UTC)
 * Ok.
 * I do think that a relatively friendly index will be created; true it won't be permuted, but it'll be something easier to maintain than the Cookbook:Recipes page.
 * Would you be equally opposed if I suggested just tagging recipes with Category:Recipe?
 * There are already a fair number of categorized pages (I think by Gentgeen) under Category:Recipes.
 * Can I get a link to the commons discussion? Seems like some of these things could/should be easily solved. Kellen 19:07, 25 May 2005 (UTC)

 * It seems that Category:Recipes is meant to hold sub-categories, not recipes. You should either choose a different name, like Category:Recipe (no s) or Category:Index, or move the sub-categories out. Other than that I guess it is kind of a nice idea. I'd like to see a few other people (maybe Redlentil and Gentgeen) show enthusiastic support before you start though. The nice thing about the current setup is that the boilerplate overhead is small enough that I can easily type it all in from memory. Maybe you should do this as a   template at the top, in place of the  Cookbook  wikitext we put there now. That way we could add other stuff later, without having to go back and re-edit all the recipes. AlbertCahalan 02:43, 26 May 2005 (UTC)
 * I'll wait for a few other users; I'd like Gentgeen's approval as well. Good idea on the templates. Kellen 04:58, 26 May 2005 (UTC)
 * The Commons discussion is here, where it is noted that "The category way takes hundreds to thousands of times the resources of the normal page view and prevents serving the page from Squid servers close to the viewer." and categories are called a "denial of service attack on the servers". AlbertCahalan 02:43, 26 May 2005 (UTC)
 * A lot of the discussion seemed to be about how category caching and optimizations haven't happened because we (wiki-X-ians) haven't forced the issue yet. Maybe we can start =) Kellen 04:58, 26 May 2005 (UTC)

 * Kellen, thanks for inviting my comments but I'm pretty clueless about categories. I'm never entirely convinced of their value. As I understand Albert's view, excessive use of categories can cause server problems, particularly when they include colons. Is that right? If so, I think detailed categories as you earlier suggested, although very useful are impractical. Using a thick category like Category:Recipe is OK, but I can't see it would make anything any easier. This may be just my ignorance. As for templates, my cluelessness there is almost entirely complete. Sorry. Redlentil 17:32, 29 Jun 2005 (UTC)

Work-around for non-updating category listings
You erase completly the category from the article and you save the page... then you link again the category with the new asigned word after the | sign.

Solution from mediawiki bugzilla:

I have just noticed that someone on en.wikipedia started to remove categories from articles with one edit only to revert the change with the next edit. That seems to be the current work-around for this bug. Needless to say, I agree that fixing it is a rather high priority.

A bug has been filed here

 * Yes, I noticed that and did that on a couple of my categories and test pages. Thanks for encoding it here though! Kellen 22:15, 25 May 2005 (UTC)

 * Hey, glad you filed a bug, looks like it's already been fixed by Brion_VIBBER Yay for him! Kellen 22:24, 25 May 2005 (UTC)

cool feature examples
Recipe scaling exists. You type in how many servings you want, and the recipe is scaled. Unless the info is in a cookie, this and this should be fine examples of how it works. Just change the number of servings.

Also, look at this category page. It shows ratings and has links to reviews. Anybody can post a review. I don't think people have to understand wikitext markup. :-/

Better than simple ratings would be ones like those used by a music recommendation service, where a recipe is ranked by how it pleases people who rate recipes similarly to yourself. (and by how it displeases people opposite to yourself) The same software feature used to ensure a heavy-metal fan doesn't get suggested country and western should work to make sure that I never get suggested to eat habaneros on tofu. (and I know, some of you are thinking "Yum!")

AlbertCahalan 12:03, 25 May 2005 (UTC)

 * Neat! The scaling is nice (and relatively easy). What I like is the conversions between US and metric -- they must have some DB of the weight per tablespoon/cup/whatever of various ingredients. Kellen 19:14, 25 May 2005 (UTC)

move featured recipe template
I'd like to move to  and use  for a main navigational template (Cookbook, Recipe Index) and category inclusion (into Category:Recipe). I will do the migrations. Objections? Kellen 05:41, 26 May 2005 (UTC)

 * Good idea. There's an one too, probably deserving the same treatment. The other major article classes are tools (pot, stove, fork), techniques (boiling, pickling, chopping), and geographic cuisines (Russian, Spanish, Mexican). I suppose the rest (oven temperatures, vegan stuff, contributers) go in "misc". AlbertCahalan 15:03, 26 May 2005 (UTC)

 * I moved the featured ingredient and recipe to Template:Featured recipe and Template:Featured ingredient respectively. The second word is lowercase so that if you do it still works (since it's common to lowercase the template names).Kellen 19:12, 26 May 2005 (UTC)

 * I made the template. I tried including a Category:Recipe in it, but that leads to a weird sort order that doesn't please me too much. See Cookbook:Cardamom_Bread for an example. Kellen 05:55, 27 May 2005 (UTC)

 * A pipe rename in the category tag (Is that what it's called?) would keep things from always sorting under "R". If the article name was used, as is done for the template on Wikipedia, we'd get everything sorted under "C". That's no improvement. Supplying the recipe name as a parameter would work, but usage is not as nice. Renaming a recipe would require an edit. AlbertCahalan 18:36, 1 Jun 2005 (UTC)

 * Oh neat, a macro. That's fun! It at least gets everything in alphabetical order in the right spot (not renamed to "Recipe"). I wonder if there's any other macros like that that'll strip out the namespace prefix. Kellen 01:25, 2 Jun 2005 (UTC)

 * Well according to if "Cookbook" were a proper namespace, we'd be able to use  to get the name we wanted, alternatively a variable to strip off all preceding false namespaces would also work. Kellen 01:45, 2 Jun 2005 (UTC)

 * I posted a request about this on Help_talk:Variable, and I will file a bug when I get a password for bugzilla. I also noticed this bug report which would clear up the problem for us at least, though I think this will become a more general need in the future (for instance if we introduced further false namespaces under a true Cookbook namespace, e.g. for a page "Cookbook:Recipe:Cardamom_Bread"). We could also (as you noted) use a piped variable to our template, but we'd have to update that when the name of a page changed. I might do that for the time being in any case. Kellen 07:41, 2 Jun 2005 (UTC)

 * Bug report filed. Kellen 18:35, 2 Jun 2005 (UTC)

 * update: Response from mediawiki people is that we should just use real namespaces and the real variables and that they don't have capabilities for nested namespaces. We should be getting a real namespace soon, and the upgrades to the mediawiki software should make it easier to deal with namespaces in the future. Kellen 02:52, 17 Jun 2005 (UTC)

advertising
A while back I added a bunch of info about vegan ingredient substitutes, with specifics of brand names and links to their respective webpages User:The_bellman did some amount of purging of these with a NPOV complaint. I responded both on his user talk page and the Talk:Cookbook:Vegan_cuisine page, with no replies on either. I am going to reinstate these links for the reasons I have written in both places. If somebody can think of a better format, I am open to suggestions, but I think the info itself is useful. Kellen 02:50, 17 Jun 2005 (UTC)

 * I have no problems with product recomendations. Our NPOV policy is much looser than our big sister's, and specifying specific brand name products is common for a cookbook. Gentgeen 21:08, 26 Jun 2005 (UTC)
 * Agree that recommendation of specific brands - particularly for tricky things like vegan substitutions - is OK. A similar thing would perhaps apply to kitchen equipment, where someone might want to suggest that Acme Food Processors are a reputed product, etc. Redlentil 17:36, 29 Jun 2005 (UTC)

Classic Recipes
I think that certain 'classic' classes of recipes should be dealt with differently. Take, for instance, Lasagna. Right now there is a - no doubt lovely - specific lasagna recipe. The problem is that these recipes are added on a sort of first come, first serve basis. There are a thousand different lasagna-recipes that could just as well take this place. I think it should be general practice to move these to a more specific name like "Ricotta Lasagna" and use the "Lasagna" page for a lasagna recipe that is as generic as possible, with not so much a recipe as a general description and notes and tips that apply to all lasagna's.

I think this would provide a way to transition smoothly between 'information pages' and recipes. For instance, the "Pasta" page gives information on pasta, with tips and notes, the "Lasagna" page does the same, but with more of a recipe structure on how lasagna's are basically made and some tips on ingredient combinations and finally the "Eggplant Lasagna" gives a specific lasgna recipe. For an example of what I mean, check the Risotto page.

I may be stating the blindingly obvious here, in which case I apologise. :) risk 17:18, 21 Jun 2005 (UTC)

 * You are correct. In wikipedia these are generally turned into disambiguation pages. In our case, of course, we're disambiguating between some relatively similar things, but I think that's OK. I say if you find something like this, move the old recipes and link them from your new disambiguation page. Also consider creating a "____ recipes" category for it if there's enough need, e.g. "Category:Lasagna recipes" Kellen 06:33, 22 Jun 2005 (UTC)


text:
User talk:66.88.133.80

Hi! Welcome to wikibooks. I'm happy to see another cookbook contributor! Kellen 21:43, 12 July 2005 (UTC)
 * You should consider creating a user account and logging in while doing editing.
 * Please check out the Cookbook policy page and the Cookbook talk pages.
 * In discussions, please sign your name using four tildes ~.

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/

title: User talk:66.88.133.80


text:
User:Jaxl

Hello, I'm an administrator on both the English Wikipedia and the English Wikiquote. I don't really use this account often, and since all of the video game wikibooks are being removed from the project, there's really nothing I can help contribute to here as of right now. Oh well. Maybe I'll go read up on something someday. Jaxl 02:19, 30 June 2006 (UTC)

title: User:Jaxl


text:
User talk:Aya/Wikibooks/A critique of Wikibooks

Leave a comment if you wish, although I also peruse Staff lounge. I'm trying to get as many opinions as possible about the way things currently work. These will eventually be translated into workable policy, and merged in to the main document, but be aware, it can take a lot of time to sort through these. - Aya 00:44, 13 July 2005 (UTC)

Once more, from the top
Note: This section copied from one of my posts on Talk:Grand Theft Auto: San Andreas, which, I guess, is where all this started. Note that some of my conclusions were subsequently altered. I shall merge in the more pertinent parts when I have time. Please don't add replies to this section. - Aya 18:34, 13 July 2005 (UTC)

Okay. I think we both have different interpretations of what Wikibooks actually is, and the most effective means of using it. I guess it was rather a dumb idea of mine to choose some standards without adequately justifying those choices. This almost always fails to produce standards which get adhered to, in any system where people are not rewarded for following said standards. e.g. In a company, you get paid money to follow their rules. On a wiki there is no obvious financial reward at all. But I hope you at least agree that standards are important on collaborative projects, if only to the extent that we interpret language in the same way. i.e. We share a common 'dictionary'.

For what it's worth, I'm a 28-year-old software developer, and during some of the projects I've had to 'endure', I came across various pitfalls of the processes commonly used within those projects. Most of these don't really pertain to wiki, but some do. I also fairly new to the wiki community, but I really like the idea, because it does to information what web-forums and newsgroups can only dream of.

The dangers of page naming
I've finally read through all the material I can find about page name delimiters, and I'll just summarise what I've found here:

N.B. I use the character '*' to represent any amount of whitespace, including no whitespace. Valid whitespace characters seem to be: '_' and '%20', but not ' ', since this is an illegal character in a URL. All browsers convert it to '%20'.

page name -> wiki interpretation

"*GTASA*" -> a page in the global namespace named "GTASA"

"*Talk*:*GTASA*" -> a page in the "Talk" namespace named "GTASA"

"*GTASA:Ryder*" -> a page in the global namespace named "GTASA:Ryder"

"*GTASA:_Ryder*" -> a page in the global namespace named "GTASA:_Ryder"

"*GTASA/Ryder*" -> a page in the global namespace named "GTASA/Ryder". Provides a link to "GTASA"

"*GTASA/_Ryder*" -> a page in the global namespace named "GTASA/_Ryder". Provides a link to "GTASA"

"*GTASA_/_Ryder*" -> a page in the global namespace named "GTASA_/_Ryder". Provides a link to "GTASA"

Notice the last three are conceptually identical, but will return three different pages. Not really what we want.

The dangers of hierarchies
Hierarchies are probably most familiar in things like URLs. The idea is to use them when something is conceptually a 'child' element of another element. This is great for some applications, but the problem is that with a bunch of disparate concepts, as you might find in a guide for GTA:SA, it's nigh impossible to get everyone to agree which means of arranging things in a hierarchy is best.

e.g. I noticed above that the page 'Vehicle Missions' is a child of the 'Vehicles' page, whereas since it's ultimately talking about missions, and not vehicles, I might have decided to make it a child of the 'Missions' page.

The same is true for most classification schemes. Let's take an example for movies. If I decide on some categories like 'Action', 'Drama', 'Comedy', 'Horror', 'Sci-Fi', etc.

The problem now is that when I want to add a movie to one of these categories, which one should I choose? The movie 'Pulp Fiction' surely belongs to more than one of these categories.

The error here is defining categories which are not mutually-exclusive. A good example of categories might be 'A', 'B', 'C', etc., in which case, there could be little argument that the movie 'Pulp Fiction' should belong in the 'P' category.

Categories also fail where the category names are poorly defined, as they are right now.

Furthermore the hierarchy might change as new content is added, and if this hierarchy is included in the page name, then the page name will have to change also. From my experience, it's a lot easier to change the content of a page, than it is to change the page's name.

Another problem with using the '/' notation is the implication that the parent node MUST exist. I might want to have a page "foo/bar", but not a page "foo".

Conclusions
To avoid confusion, I shall define the following terms:

 * bookshelf:Conceptially, an index of one of more categories of books on Wikibooks.
 * book:This is perhaps analagous to a paper book. This book may belong to any number of bookshelves.
 * page:This is perhaps analagous to a chapter in a paper book. Note that one of the design goals of Wikibooks was to allow many books to share the same pages. e.g. Most of the Wikibooks relating to computer programming, tend to include the global page containing the ASCII chart.
 * page name:The suffix of the URL used to retrieve a page. i.e. http://en.wikibooks.org/wiki/ page name. Note that many similar suffices may be used to reference the same page, so I shall define it to mean the shortest suffix required to retrieve the page.
 * content page:Conceptually, perhaps, a leaf-node page which contains mostly useful content pertaining to its page name.
 * index page:A page whose primary reason for existence is to provide an index to other pages. The index could be hierarchical, alphabetical, or whatever. A bookshelf page is an example of such a page.

 * Use page names solely to uniquely identify discrete concepts within the scope of the book. They should not be used to denote hierarchy.
 * Keep the page names as short as possible, while making every effort to avoid namespace collision, by using scoping or disambiguation where necessary.
 * To provide a hierarchical model of all the content pages relevant to the book, use an index page to index the existing content. This is the current purpose of the 'Contents' page. If the conceptual hierarchy should need to change, you only need to modify that one page. This also allows you to apply multiple conceptual models to the same information, simply by having multiple index pages. e.g. the 'Index' page will ultimately provide an alphabetical index of the same content pages, and the FAQ page is starting to link back into the main content.
 * To provide a hierarchical model of all the content pages relevant to a smaller scope (e.g. all missions in Los Santos), use another index page.
 * Try to avoid changing the page names of existing pages, or creating too many new content pages until there is a clear page naming standard.

Perhaps it would be clearer if I specified how I ultimately expect the pages to be named. The string "GTASA" should be interpreted as "Grand Theft Auto: San Andreas":-

 * Index pages
 * "GTASA" - Main page, linking only to other index pages.
 * "GTASA: Contents" - Full hierarchical contents, linking to every content page.
 * "GTASA: Index" - Full alphabetical index, linking to every content page.
 * "GTASA: Frequently Asked Questions " - This page is a little hairy, since it contains both indices and content, but I shall put it in here in the hope that ultimately it will only contain links to other pages.
 * Content pages
 * "GTASA: Mission: Ryder" - Anything pertaining to the 'Ryder' mission.
 * "GTASA: Mission: End of the Line" - Anything pertaining to the 'End of the Line' mission.
 * "GTASA: Character: Ryder" - Anything pertaining the the character 'Ryder'
 * "GTASA: Vehicle: Infernus" - Anything pertaining the the vehicle 'Infernus'
 * "GTASA: Item: Night-vision Goggles" - Anything pertaining the the item 'Night-vision Goggles'
 * "GTASA: Item: Night-vision Goggles" - Anything pertaining the the item 'Night-vision Goggles'

If you think having only a single index to all missions is too much of a 'spoiler', then you could create another index page, say, just for Los Santos missions, which would link to the 'Ryder' mission, but not to the 'End of the Line' mission.

The means used to disambiguate the page names is arbitrary. I merely chose the colon (as used typographically rather than in a scoping context. i.e. "foo: bar" rather than "foo:bar"), because this seemed to be the way that the content was already organised. Some other examples:

 * "GTASA: Ryder (mission)"
 * "GTASA: Mission - Ryder"

I really don't care which method is used, providing it's agreed upon. Maybe the colon is a bad idea because it implies a namespace where none exists.

See also: Naming_conventions

Okay. It's 8:00pm here, and I'm off to the pub for a while.

Aya 18:56, 16 Jun 2005 (UTC)

 * I wasn't aware that there was a misunderstanding at all, but now I finally see what you're getting at! Yes I did think of the hierarchy of the Vehicle Missions--after I'd moved it! Certainly it should go under missions.
 * But what other examples are there of multiple-location pages like the Pulp Fiction example you gave? From a quick look at the list, pretty much everything might as well stay right where it is until such time as good names are found for "collectible hidden things" and such. For neatness' sake the Burglary guide should go under the Vehicle Missions page, but, again, that's minor.
 * As for implying the parent exists, in the currently applicable situations I can't think of a parent directory that would be unwanted, except for /Cheats/ but I've got plans for content there too.
 * The colons as they look nice and make nicer-looking page auto-titles than the slashes do, but they still imply an upper directory exists. Brackets make users less inclined to think there is a higher level, but as a downside they generate ugly URLs ("Grand_Theft_Auto:_San_Andreas_%28Contents%29").
 * I'm interested in using slashes because that is the standard for nested pages both in many of the other books here and the pages on other Wikis. Also, and more importantly, the MediaWiki engine will eventually support a TOC link on each page that will generate a list of its child pages, but this will not however support colon-based directories. Therefore for future-proofing and overall cohesiveness with the style adopted by the rest of the Wikibooks projects it seems the slash should be the way to go. Hmmm...
 * But hang on, I've got an idea, I'll just post this and do that :) Master Thief Garrett 14:22, 17 Jun 2005 (UTC)

Other bits to be merged

 * Staff lounge
 * Wikibooks talk:Votes for deletion
 * Talk:Main Page
 * User talk:KelvSYC

Category hierarchies
From the main page: The problem is, categories duplicate the functionality offered by the '/' subpage notation.

This is incorrect. In the cookbook, the recipes fit into many different categories, e.g. a recipe in Category:Vegan recipes and in Category:Bread (see: Cookbook:Cardamom Bread). Kellen 01:48, 13 July 2005 (UTC)

 * You're correct of course. We really need a good policy on use of categories. They're just too flexible for their own good. Maybe it's no big deal, and "Use categories at your own discretion" is about all we can say. I guess they can always be moved or renamed later on if there's a conflict. It was so much easier on Wikipedia, since there could be fewer arguments about the correct use of categories. It's almost as if each book on Wikibooks would benefit from having its own namespace, with its own pages, categories, images, and templates in that namespace. Another way of saying it is, perhaps with the current software implementation, each Wikibook needs its own wiki, in the same way that Wiktionary and Wikipedia are effectively separate books in their own right, but both theoretically could have been separate Wikibooks projects on this site. I suspect there would be many advantages from having all WikiMedia projects sharing the same wiki, providing the MediaWiki software could keep them all separate. Intra-wiki-linking feels much more professional than inter-wiki-linking. - Aya 14:36, 13 July 2005 (UTC)

Where hierarchical categories come into play is where there are managment issues in the categories. In the main wikipedia this is not so much a problem since everything belongs to the same "book." In the cookbook we have lots of stray categories with only one or two things, many of which are not subcategories of the "main" cookbook categories. If we make sure that we prefix everything category for the cookbook with "Cookbook:", this mangment becomes much easier. Kellen 01:48, 13 July 2005 (UTC)

 * I can't see a conceptual difference between making those categories subcategories of the 'main cookbook' categories, and altering their names to make it look like they are subcategories (regardless of whether you subsequently add them to be bona fide subcategories too.) Having said that, and based on my previous reply, it might be worth prepending them anyway, to serve as a scoping tool to prevent namespace collision, rather than implying a hierarchy. Perhaps the following might be useful:

 * For a book entitled "foo", the following page prefixes are reserved for that book:

(Main:)Foo[/*] (Main:)Foo[:*] Talk:Foo[/*] Talk:Foo[:*] Image:Foo[/*] Image talk:Foo[/*] Template:Foo[/*] Template talk:Foo[/*] Category:Foo[/*] Category talk:Foo[/*]

 * Only use pages outside these prefixes where they are conceptually designed to be shared between multiple Wikibooks. It may also be worth listing these generic pages on another page, so people are aware of them, and don't accidentally create a fork.
 * This is part of WB:NC (although images, templates, and categories are in recommended use only), although it is not strictly enforced because little effort has gone in by users to enforce them. KelvSYC 04:26, 14 July 2005 (UTC)
 * Wow. I accidentally came up with the existing policy without having read it. "Great minds think alike" or just "blindlingly obvious"? Yeah. It's obviously not a followed convention for those who have never read it. - Aya 13:25, 14 July 2005 (UTC)

 * In a way this seems like common sense, but it's not written down anywhere. Note that I only allow the ':' syntax for pages in main and talk namespaces, since it's the only one which provides different wiki behavior. I still believe the '/' is typographically preferable. I already used this convention with the page header template Template:Grand Theft Auto: San Andreas/Header for the book Grand Theft Auto: San Andreas. - Aya 14:36, 13 July 2005 (UTC)

My inclination is that categories probably shouldn't be shared across wikibooks anyway, though maybe entire wikibooks could be categorized together (Category:Physics books). Kellen 01:48, 13 July 2005 (UTC)

 * Again, you're probably correct. I guess there has to be a distinction between the categorization of books, and the categorization of pages within a single book. Back to your original question, I'd go ahead and create categories of the form 'Category:Cookbook/Meat recipes', etc. I guess it's probably worth including them all as subcategories of 'Category:Cookbook'. - Aya 14:36, 13 July 2005 (UTC) Check out The movies example to see if we are even talking about the same thing. - Aya 13:35, 14 July 2005 (UTC)

confirming 2833 fixed Kellen 01:48, 13 July 2005 (UTC)

 * Wow. Thanks. That was quick. It just works now. I'll add in a bug-reporting policy, just so that everyone knows the proper procedure. i.e. they go to http://bugzilla.wikimedia.org/. - Aya 14:36, 13 July 2005 (UTC)

Test Wiki
You can find a test wiki here.

http://test.leuksman.com/index.php/Main_Page

It's running MediaWiki 1.5, indeed was running it long before any other project. So that's basically one BIG sandbox to make use of.

There, one problem solved already! :) GarrettTalk 04:54, 13 July 2005 (UTC)

 * Cool. If that site can be guaranteed to remain up 24/7, that's exactly what we need. If we can get the DNS name sandbox.wikimedia.org to point to the same IP address, and co-ordinate with the developers to ensure that this site always contains the latest bleeding-edge release of MediaWiki, we can get some free beta-testers, while minimizing site damage. We also need to make sure all WikiMedia sites include this link. This could prove more difficult, since there are hundreds of them. I'm beginning to think Geocachernemesis was right, and that I should move all this stuff to meta.wikimedia.org. - Aya 14:37, 13 July 2005 (UTC)

 * Update: merged into User:Aya/Wikibooks/A critique of Wikibooks - Aya 18:34, 13 July 2005 (UTC)

 * By the way, how d'ya get that different signature to work without using a template? - Aya 18:34, 13 July 2005 (UTC)
 * Look in your Preferences. My nickname is set to  GarrettTalk  but "raw signatures" must be checked or it tries to re-bracket it.

The movies example
See: The dangers of hierarchies

Talk moved from that section:

In your example here for movies, my current view of things would be to make the movie pages distinct from any hierarchical page naming except for the top-level namespace (e.g. Movies:The Blob), then have your structural book pages as necessary (e.g. Movies/Horror and Movies/Sci-Fi), have appropriate categories (e.g. Category:Movies:Horror and Category:Movies:Sci-Fi), include Movies:The_Blob in both these categories and link to the category listings from the structural pages. This is not without its problems -- say if you wanted extended descriptions of the movies on the listings page, or you wanted to have more defined categories.

 * I agree with "Movies:The Blob", but I might prefer "Movies/The Blob" to get the auto-link. The use of categories is obviously correct for this example, although I would've chosen the names "Category:Horror movies" and "Category:Sci-Fi movies", and added them both to the category "Category:Movies". But I don't understand why you need the pages "Movies/Horror" and "Movies/Sci-Fi". - Aya 19:07, 13 July 2005 (UTC)

 * In the current paradigm you'd want "Movies/Horror" or "Movies/Sci-Fi" as detailed descriptions of the genre, but you'd have "Category:Horror movies" to actually catalog all of the horror movies. In reality, you could put your detailed description on the catagory page, but that doesn't seem to be current practice. I'm actually inclined in some instances in the cookbook to make the category pages more like these "normal" pages, especially where on the pages there are listings of recipes Cookbook:Vegan cuisine for an example. If the "Vegan cuisine" page was actually a category page, you'd automagically get the listing of recipes and subcategories below. Kellen 00:50, 25 July 2005 (UTC)

 * I'd be inclined to agree with your idea of adding more detail to the category pages, rather than creating new pages for the detail. I'm sure this was how they were intended to be used, since otherwise, I wouldn't see the point of the software forcing you to create the category page solely to list the entries in that category. It subsequently occurred to me that if category pages can be used in this way, and also have the benefits of subsetting, why would you ever need a regular (non-category) page? A regular page strikes me as being a category page that you can't add subcategories to. I also wonder as to the reasoning behind having a separate template namespace, although it may be purely for performance reasons (i.e. changing a template page forces the software to flush its cache for all pages which include that template). - Aya T C 02:46, 25 July 2005 (UTC)

 * "changing a template page forces the software to flush its cache for all pages which include that template" is not true in the case of categories. You must do a null edit on each page which includes the template in order to flush the cache. See the meta help page for more info. Kellen 08:57, 25 July 2005 (UTC)

You may want a movie to be in Category:Movies:1980s and Category:Movies:Horror, but as far as I know, there's no category intersection pages... /ramble Kellen 18:02, 13 July 2005 (UTC)

 * This may be the point of confusion between us, since as far as I was aware, there is such a feature, and its unique to categories. As well as adding a category tag to a regular page, you can also add the tag to a category page. In this case, the category for the page you added the tag to, is considered to be a sub-category of the category name specified in the tag. When you subsequently click on the super-category, it will list not only the pages in the category, but also all it's subcategories. If you were unaware of this, it was the reason I gave for why category names should not imply hierarchy. See Category:Science for an example. - Aya 19:07, 13 July 2005 (UTC)

 * I mean something different.
 * First, some other observations: When you make a category a subcategory of another category (yeesh), you're essentially including all the pages in that category in the supercategory. The pages in the subcategory do not show up in the pages listing in the supercategory. It is implied that they would also belong there, but there's no way to view all of them at once (so far as I know). This is problematic for, say, recipes, where you might sometimes not care about the category structure, and you just want to see all the recipes that fall under Category:South American recipes, for example. The interim solution for us is to add everything to Category:Recipes to create a big index. This is getting unweildy though, so I think I might move them all into Category:Recipe and leave the subcategories under Category:Recipes.
 * What I was specifically referring to above is that if I have two distinct categories which have pages in common, there is no way to filter my view so that I see only the recipes that belong to both. This comes into play in the cookbook where we have Category:Soups and Category:Vegan recipes. There is currently a Category:Vegan soups, but this seems wrong to me. The correct way would be to file the recipe under both "Soups" and "Vegan recipes" and then get a view which is limited to things in both of these categories instead of replicating all of the possible food types (Soups, Desserts, Mains, Peruvian recipes, etc) with "Vegan" prefixed to them. I realize that "Vegan soups" can be categorized under both "Vegan recipes" and "Soups" but that still strikes me as redundant work. Kellen 01:03, 25 July 2005 (UTC)

 * Ahh. I see. Perhaps substituting the word 'category' for the word 'set' might make things clearer (i.e. formal set theory). Thus you can have a set of soups and a set of vegan recipes, but there no way to automatically generate an intersection of the two sets (i.e. the set of all vegan soups). In addition, you can have a set of meat recipes and a set of fish recipes, but you can't generate a union of the two sets (i.e. the set of all meat or fish recipes, probably equivalent to the set of all non-vegitarian recipes). Furthermore, the elements of a subset are not shown in a superset, which might be considered more 'correct' in set theory.

 * This would no doubt require a software change, and a new syntax for creating unions/intersections, and perhaps an option to show entries in all subcategories. Sounds like a neat idea, and might be worth suggesting to the dev team, although I suspect you probably know better than I how to do this. I'm beginning to think I'd be better off joining the dev team, and fixing things in there, rather than creating extensive documents to workaround these issues.

 * Regardless, I still don't think that implying hierarchy in categories by their name is a good idea, since it conceptually duplicates the behavior of subcategories. The original Pokemon example is perhaps a special case, since it deals with a fictional universe. I see that more as 'scoping' to prevent namespace collisions, rather than 'hierarchy', although they can be argued to be conceptually equivalent. - Aya T C 02:46, 25 July 2005 (UTC)

 * Agreed in most instances. The main thing I am concerned about is whether the categories should be scoped to the book or not. I tend to think that they should, but that the books should be categorized (mentioned this before). A potential problem with this approach is that at some point someone may wish to categorize related chapters in different books, but I think this is a rather minimal downside for having a clean category space. Kellen 08:57, 25 July 2005 (UTC)

Be bold
Having said what you said in your critique, why don't you be bold and try to fix some of these problems that are plaguing Wikibooks? KelvSYC 04:36, 14 July 2005 (UTC)

 * The point of writing the document was to mostly to serve as justification for any subsequent changes I make, so that when my actions get questioned (as they no doubt will), I don't have to tediously explain the same point to several different users, but rather give a link to the document. Futher, as I stated in Staff lounge, I was going to make some changes, but it would be fair to consult other Wikibookians before doing so, which I'm hoping this talk page will become. It just seemed logical to keep a record of my train of thought, to make it easier for other users to identify any flaws in my reasoning.

 * The fundamental problem I have identified is that the current policy documents are numerous, invisible, vague and self-contradictory. That is why people keep discussing their meaning so much. In order to solve the problems, I figured the best procedure would be:

 * 1) Identify the problems with policy
 * 2) Identify the causes of the problems
 * 3) Solve the problems, by eliminating the cause where possible
 * 4) Devise new policy to implement the solutions in a practical fashion
 * 5) Make sure people agree with the new policy, to prevent my edits getting reverted
 * 6) Update the policy documents to prevent future misunderstanding
 * 7) Make sure the policy is more visible to new users, especially those creating new books
 * 8) Retroactively apply new policy to existing books

 * There seems little point in performing the final step as long as the policy is unclear. New books are being created all the time, and I just don't have time to fix them all. - Aya 13:10, 14 July 2005 (UTC)

 * So far, the only policies actively enforced are WB:WIN (the constitution if you will), WB:FP, and WB:AT, although there is an increasing amount of WB:NC enformcement. Other policies are pretty much common to all MW wikis (deletion, editing, etc). KelvSYC 06:39, 15 July 2005 (UTC)

 * Aha. I think I've found one of the sources of confusion. See this diff, made by yourself. You completely changed the meaning of the document, by changing the more specific term "primary research" (adequately defined), with the incredibly vague term "original research". Its new definition arguably covers every existing book on the site. This needs to be fixed. WB:FP is common sense, especially for software-engineering people link myself, but needs to remain, and ought to tightened up (especially forking from Wikipedia). WB:AT should probably be merged into WB:WIN. WB:NC is a bit more fuzzy at the moment, especially as it starts with a link to WB:HNS. WB:WIN is a bad idea for a 'constitution' anyway. It's much more effective to define what something is, rather than define what it is not. I'm thinking of something more akin to User:Aya/Wikibooks/A critique of Wikibooks - Aya 08:16, 15 July 2005 (UTC)

 * Perhaps the diff you have shown introduces ambiguity, but the current version of WB:WIN does not have it (thanks for User:Dovi who pointed it out in the talk page). It should still reflect the spirit of what it is meant.

 * Most of the policies are fuzzy because they are not well fleshed out (or in dire need of enforcement). Historically, I believe WB:AT is separate due to this being an agreed-upon policy between Wikibooks and Wikisource.  I will be the first to admit that perhaps WB:WIN is a "bad idea", but we need a series of pages that will define what Wikibooks is (of course, I will ask you to contribute in a big manner, seeing you have your ideas and seem to be willing to implement them).
 * Books for what consitutes book material.
 * Instructional material for what constitutes instructional material. The two together will define what is a proper Wikibook.
 * Bookshelf and WikiProject Librarian ("the first Wikibooks WikiProject") for how Wikibooks defines a bookshelf and how users can contribute to stocking these shelves with new books as they are created.

 * Of course, with radical changes to Wikibooks as we know it, we may have to relent on existing policies and introduce. I admit that I can be considered "old guard" as these changes may change the mission of Wikibooks, but if the public likes the wiki to go that way, they may force our hand.  Among these we would need:
 * Reference material for what constitutes general nonfiction books (as opposed to, say, Wikipedia articles or books of a nonfictional material). This would form the third part of defining what appropriate Wikibooks should be.

 * KelvSYC 05:20, 26 July 2005 (UTC)

 * Pah. Now we have the same conversation going on two pages. I've just replied to your post to the mailing list on your talk page. Let's shift it to there for the moment. - Aya T C 17:57, 26 July 2005 (UTC)

We could sure use someone to enforce WB:NC to General Chemistry or determine through WB:FP what parts of Programming:C plus plus and Programming:C -/- -/- to keep in a merged book (both long debacles that has existed since well before I was a user, let alone an admin). KelvSYC 04:36, 14 July 2005 (UTC)

 * I was aware of these problems, and they do need to be addressed, but the problem will only get worse as new users create more pages making the same errors. I already made to effort to apply the new naming conventions to the Grand Theft Auto: San Andreas guide, as well as all the other tidying up required to cope with the changes, and it can take a long time. Feel free to 'be bold' yourself if you want these other books changed more speedily, but I would probably first devise a scripting system for a bot to make these changes. Probably only needs 50 lines of perl (not that I recommend perl, but it is well known). - Aya 13:10, 14 July 2005 (UTC)
 * Pratically all MW bots use Python by the way. KelvSYC 06:39, 15 July 2005 (UTC)
 * Yeah. I had seen the Sourceforge project. I much prefer Python to perl. I have personally submitted source code corrections to it before. Since it's the most common, I tend to use the word "perl" to mean "any scripting language comparable to perl". - Aya 08:47, 15 July 2005 (UTC)

The problem is that not a lot of users venture out of their own book, and it would be great if you would be one who helps keep things orderly rather than complaining about how things aren't. KelvSYC 04:36, 14 July 2005 (UTC)

 * I'm not complaining, and it worries me that you interpret it as such. Be aware that the word "criticism" does not necessarily imply a "complaint". I'm just trying to sort things out. I'm just not sure that I've come up with the best method yet, and I don't want to change anything until I am. - Aya 13:10, 14 July 2005 (UTC)

How about rather than putting down stuff like or  in every policy page, go out and just enforce these policies? KelvSYC 04:36, 14 July 2005 (UTC)

 * To be fair, that template stuff was probably a mistake. It's no worse than it was before, but it's only marginally better. Since most of the policies here have been (inappropriately) forked from Wikipedia, I figured I'd copy Wikipedia's current system for policy, hoping it might make a difference. I was wrong. Problem is there are far too many policy documents, they are not always clearly identified as such, and no-one has actually read them all. I feel a massive merge and delete operation coming along soon.

 * On a personal note, can I inquire as you your age, sex and location, since it's not on your user page. It might be easier to communicate, since I could alter my dialect to use metaphors more common to you. (e.g. using the US Constitution as a metaphor is obviously more effective for people of US origin). - Aya 13:10, 14 July 2005 (UTC)

 * I'd rather not disclose that here, for personal reasons, although you will invariably find what you are looking for on the MW projects. KelvSYC 06:39, 15 July 2005 (UTC)

 * Apologies for not looking. Your Wikipedia user page is slightly clearer, and tends to indicate you are a Canadian immigrant from a Chinese-speaking nation. Based on your contributions and use of language, I'm guessing that you are male, and between the ages of 14 and 24. - Aya 08:16, 15 July 2005 (UTC)

English language
English is not the official language of the UK. There isn't one! Although, of course, it is conventional to speak English. See the article on the United Kingdom on wikipedia. --Mark Lewis 14:24, 19 July 2005 (UTC)

 * Thanks for the correction. I've updated User:Aya/Wikibooks/A critique of Wikibooks appropriately. - Aya T C 17:40, 24 July 2005 (UTC)

Revising Wikibook policy standards
OK, I'm going to betray my ethnic background somewhat here, but my country got into a big pickle when we tried to adopt previous institutions that were inherited from the "parent" country, and found out the hard way that the whole thing was so screwed up that it was totally unworkable. In short, we tossed out the entire body of law and started anew. The resulting document was the United States Consitituion. - Rob Horning 04:38, 24 July 2005 (UTC)

 * First of all, a sincere thankyou for your extensive, and well thought out contribution. Based on your comments and your apparent timezone, I'm assuming you're a US citizen, and the 'parent country' to which you refer is the UK. Please correct me if I'm wrong. - Aya T C 18:19, 24 July 2005 (UTC)

In the same vein, Wikibooks may have to do exactly this as well. We know the founding principles of what got Wikibooks going, and I don't want to betray that at all. At the same time, this is not Wikipedia, and there needs to be a way to "declare independence" from Wikipedia and its policies as well. We are still under the umbrella of the Wikimedia Foundation, but it is only the Wikimedia board that we should be obligated to please.

Furthermore, there has been a couple of years of hard won experience here at Wikibooks. What has worked, what hasn't, and where should we go? In this regard you are doing us all a big favor Aya, by taking this issue by the horns and trying to make something of this work. The #1 issue that I would see, however, is that something of this scope needs to include more than just en.wikibooks. We need to get the other languages involved in setting general broad policies governing Wikibooks and its relationship to the other Wikimedia sister projects.

I've long complained (for a couple of months or so, I guess) that Wikibooks has become the dumping ground for projects that the other sister projects don't want to deal with. The 1911 Encyclopedia is a classic example of this, and was (unfortunately) suggested by one of the participants on Meta. By establishing firm policies as to what is and is not proper content that can be placed on here, we can clean up Wikibooks and make it a jewel that it can become.

Wikibooks is also at a transition. New blood is coming into Wikibooks, and there seems to be a slight clash of cultures going on right now. As for myself, I would not have been involved with Wikimedia projects if it weren't for Wikibooks. I looked at Wikipedia several years ago (more than one), and even poked around at the content, but never felt compelled to get involved. After reading several Wikipedia entries from Slashdot, and an article about Wikibooks, I finally had a book idea that was digging into me and I had to write. Programming:Serial Data Communications is the result of that initial effort (and I'm not done). - Rob Horning 04:38, 24 July 2005 (UTC)

 * Seems as if you've pretty much come to the same conclusions as I. I had taken a slight break from writing this document, while I did some research on other Wikimedia projects, to see how they deal with these problems. During this time I discovered extreme content overlap with other wikis, and have tried to address these by creating Directory as an authoritative index of Wikimedia projects, languages, wikis, and appropriate content. As for authoritative policies, I've made a start on Policy; the idea being to move all policy, and debate thereof, from each individual project, to Meta. I feel as if this was the intended purpose for Meta anyway (read m:Meta:About). In effect, this would mean that most pages in the 'project namepace' (e.g. the Wikipedia namespace on the Wikipedia project) ought to be moved to Meta.

 * The main problem I am now facing is the classic 'tradition' vs. 'evolution' conflict. (e.g. w:Wikipedia talk:Bad Jokes and Other Deleted Nonsense). It seems people would rather carry on in the current tradition of chaotic scope and policy, rather than allowing it to evolve into something more meaningful and well-defined; the reason being that for convenience, long-term users would prefer things to stay the same, whereas new users would prefer the content to be in more obvious locations. In this particular case, perhaps the correct thing to do would have been to just ignore what other people think, be bold, and just do it, but I have a feeling my changes would be reverted, and it would thus be a waste of my time.

 * The other problem is that Meta is a complete mess. There are too many pages which are out-of-date, and too many on the same subject which contradict each other. I'm beginning to think Meta needs to be redesigned from the ground up, but I don't think it's something I can get done by myself. I'm still pondering various ideas, but in the interim, I'd be grateful for any suggestions you might have on the subject. - Aya T C 18:19, 24 July 2005 (UTC)

Carry on, Aya. I'll try to make some comments about some specific points you have raised later. - Rob Horning 04:38, 24 July 2005 (UTC)

 * That would also be appreciated. I stick by the idea that even where pages should contain all users POVs, it should retain a single editor (preferably one who is well-versed in the finer points of language) to ensure it has a meaningful structure, and maintains consistent language use throughout. - Aya T C 18:19, 24 July 2005 (UTC)


text:
File:Chinese Characters.gif

Formation of Chinese characters.

title: File:Chinese Characters.gif


text:
File:Chinese Characters2.gif

Chinese Character formations can be in different proportions.

title: File:Chinese Characters2.gif


text:
File:Chinese Characters3.gif

In Chinese Character formations one can be included in parts of others'.

title: File:Chinese Characters3.gif


text:
User talk:67.40.22.37

Hi! Welcome to wikibooks. I'm happy to see another cookbook contributor! Kellen 04:00, 13 July 2005 (UTC)
 * You should consider creating a user account and logging in while doing editing.
 * Remember to preview all your edits before saving -- check to make sure you didn't break any links.
 * Please check out the Cookbook policy page and the Cookbook talk pages.
 * In discussions, please sign your name using four tildes ~ so people can tell who you are.

title: User talk:67.40.22.37


text:
Talk:Movie Making Manual/Pitching/Treatment

Beethoven's ninth? I think you meant his fifth, with its famous dun dun dun dunnnn theme...


text:
User talk:205.188.116.65

Hello and welcome to Wikibooks!

Here are some tips to help you get started:

 * Remember to conduct any editing experiments in the sandbox.
 * Check out our help page if you need additional help.
 * Eventually, you might want to read the Manual of Style and Policies and Guidelines.
 * Remember to maintain a Neutral point of view.
 * Explore, be bold in editing pages, and have fun!

Good luck!

(Donovan|Geocachernemesis|Interact) 05:50, 13 July 2005 (UTC)

title: User talk:205.188.116.65


text:
User talk:80.235.136.129

Hello and welcome to Wikibooks!

Here are some tips to help you get started:

 * Remember to conduct any editing experiments in the sandbox.
 * Check out our help page if you need additional help.
 * Eventually, you might want to read the Manual of Style and Policies and Guidelines.
 * Remember to maintain a Neutral point of view.
 * Explore, be bold in editing pages, and have fun!

Good luck!

(Donovan|Geocachernemesis|Interact) 05:56, 13 July 2005 (UTC)

title: User talk:80.235.136.129


text:
User talk:70.109.111.148

Hello and welcome to Wikibooks!

Here are some tips to help you get started:

 * Remember to conduct any editing experiments in the sandbox.
 * Check out our help page if you need additional help.
 * Eventually, you might want to read the Manual of Style and Policies and Guidelines.
 * Remember to maintain a Neutral point of view.
 * Explore, be bold in editing pages, and have fun!

Good luck!

(Donovan|Geocachernemesis|Interact) 06:07, 13 July 2005 (UTC)

title: User talk:70.109.111.148


text:
Cookbook:Low-Carb

Low-carb diet is a general term referring to numerous specific diets that advocate for a reduction of carbohydrate intake as a healthier balance of foods. The concept is based on the fact that grain-based foods cause the body to store the fat it consumes rather than burning it for fuel. Low-carb diets, in various prescriptions, favor "complex carbs" (vegetables) over "simple carbs" (grains and starches), while also reducing the consumption of saturated fat in favor of unsaturated fat.

The Atkins Diet is the most well-known and heavily marketed low-carb diet, though its specified prescriptions for regimented protein intake are controversial. The South Beach diet is also well known, though more generalized. The Zone diet is controversial because it prescribes a balance between carbs, fat, and protein according to a "40:30:30" ratio.

It's important to note that both the Atkins and Zone diets are controversial due to the specific claims or prescriptions they make. Further, both are business trade names for diets and are considered proprietary and licensed franchises (though to a different degree). However, the basic general principles of low-carb dieting are not intellectual property, and likewise, the general ideas about proportions and balance in these specific diets are free to examine and learn from.

title: Cookbook:Low-Carb


text:
Template:Cookbookwelcome

 * Please also check out the Cookbook policy page and the Cookbook talk pages.

title: Template:Cookbookwelcome


text:
User:134.10.24.231

Welcome, 134.10.24.231!

Come introduce yourself in the general reading room or your project in the project reading room. If you have any questions, you can ask in the assistance reading room or contact me personally. Kellen 06:40, 13 July 2005 (UTC)
 * Please also check out the Cookbook policy page and the Cookbook talk pages.

title: User:134.10.24.231


text:
Portuguese/Contents/Complete Pronunciation

Portuguese alphabet, like in other Romance languages has a natural evolution from Latin and so it is not strictly phonetic and has some features inherited from its history. Although, compared to English or even French it is easy to read and not so hard to write.

Letters
The sounds are better explained in the next chapters.

Glossary:
 * Coda: the sounds in a syllable after the vowel, for example t in spit;
 * Onset: the sounds in a syllable before the vowel, for example sp in spit;
 * Nucleus: the vowel of a syllable;
 * Glide: the sounds /j/ and /w/;
 * Stressed: (of a syllable) which is pronounced more emphatically, for example compounding.

Note: the letter q is always followed by a u.

Digraphs
Digraphs is a pair of letters used to sign one sound.

Diacritics
In Portuguese, a letter with or without Diacritics is considered the same.


text:
Programmed Math/Fractions

A fraction is most easily thought of as representing some portion of a unit.

The simplest fractions to think about are numbers like "one half" or "one tenth." For example, one third is the number you get when you divide one into three equal parts and take one of them.

We write one third as $$\frac{1}{3}$$.

Every fraction looks like that, having an integer on top, which we call the numerator, and an integer on the bottom, which we call the denominator. This fractional notation represents the number that we get when we divide the numerator by the denominator. In our simple examples we had a numerator of 1.

So, what do we mean by the expression $$\frac{2}{3}$$?

When we read this in English, we say "two thirds." That sounds like we have "two" of something, namely two "thirds" or two of: $$\frac{1}{3}$$, which we naturally think of as $$2 * \frac{1}{3}$$ or $$\frac{1}{3} + \frac{1}{3}$$. But in our more technical definition of a fraction we said it was a number we get by dividing a pair of integers, so that $$\frac{2}{3}$$ is defined as $$2\div3$$.

Well fortunately for our intuitions, it will turn out that $$\frac{1}{3} + \frac{1}{3} = \frac{2}{3}$$.

Thinking about a fraction as some portion of a unit works nicely so long as the numerator is less than the denominator. But what do we mean by $$\frac{4}{3}$$? Well, intuitively, we think of having four of $$\frac{1}{3}$$, which, thinking about huge slices of cake, must surely be equal to $$1 + \frac{1}{3}$$. And, sure enough, if you do the division of 4 by 3 you'll end up with 1.33333..., which is 1 + 0.3333... or $$1 + \frac{1}{3}$$.

Fractions can represent whole numbers, too. Nothing but our boring desire for simplicity and clarity keeps us from writing 12 as $$\frac{120}{10}$$ whenever we like.

Further topics in fractions:
 * reducing fractions
 * finding least common denominators
 * adding and subtracting fractions
 * multiplying and dividing fractions

title: Programmed Math/Fractions


text:
User talk:203.199.215.116

Come introduce yourself at the new users page. If you have any questions, you can ask there or contact me personally. (Donovan|Geocachernemesis|Interact) 11:15, 13 July 2005 (UTC)

title: User talk:203.199.215.116


text:
User talk:195.60.2.244

Come introduce yourself at the new users page. If you have any questions, you can ask there or contact me personally. (Donovan|Geocachernemesis|Interact) 11:19, 13 July 2005 (UTC)

title: User talk:195.60.2.244


text:
Programmed Math/Division

Division can thought of a reverse multiplication of sorts, where you find how many numbers go into another number.

Division is usually in the format:

$$\frac{2}{4}$$ (two divided by four) OR $$2/4=x$$

For an example:

We want to find out what 100 divides by. We start with 1. We know that $$1*100=100$$ So 100 is divisible by 1.

And we find that $$2*50=100$$ So 100 is divisible by 2.

But $$3*33.33=99.99$$ So 3 isn't. We can't divide 100 by 3 to get a straight answer.

So we go onto 4. $$4*25=100$$ So 100 is divisible by 4.

And so on for each number. But this format takes too long, so we go:

$$100/4=25$$

title: Programmed Math/Division


text:
Programmed Math/Sine

In a right angled triangle, Sine is the opposite side of the angle needed divided by hypotenuse; so: $$\sin\theta=\frac{o}{h}$$ An equation with Sine would be the following, when the opposite is equal to 5 and the hypotenuse is equal to 10: $$\sin\theta = \frac{o}{h}$$ = $$\sin\theta\ = \frac{5}{10} = 0.50$$

Sine is usually used for triangle with the angle in the corner of lower point of the hypotenuse.

Sine can also be reversed, to find out the length of the sides when you have the angle already.

This can be used by going $$\sin ^-x =\frac{2}{h}$$, where x is the angle you have, and h is the side you want to get.

title: Programmed Math/Sine


text:
Talk:Serial Programming/RS-232

Why merge this almost empty article? Shouldn't it better just be removed?

 * This was part of an edit conflict, but in general the philosophy is that this is to become a reference manual, while the Serial Programming Wikibooks is more of a step-by-step textbook. There is an important distinction between the two, and the textbook is much harder to write, to be honest.  --Rob Horning 04:24, 5 November 2005 (UTC)

title: Talk:Serial Programming/RS-232


text:
User:Nihilistic.nazgul

I am a teenage student, programmer, geek god (So the tests have told), computer technician and physics geek. I love Science Fiction, especially Isaac Asimov and Arthur C Clark. I enjoy programming in several languages, such as C++ and python for applications, XHTML, XML, CSS and PHP for web development and lisp and C for some nostalgia.

I am constantly adding to my already impressive hardware dungeon type room with more computers and geek items.

My website is http://the-endless-abode.dhs.org

My computer is better than this one:

title: User:Nihilistic.nazgul


text:
Programmed Math/Cosine

Cosine in trigonometry is the adjacent divided hypotenuse, in the form of $$\cos\theta=\frac{a}{h}$$ An equation with Cosine would be the following when the adjacent is equal to 5 and the hypotenuse is equal to 10: $$\cos\theta = \frac{a}{h}$$ = $$\cos\theta\ = \frac{5}{10} = .877562$$

Cosine is usually used for triangle with the angle in the corner of lower point of the hypotenuse.

title: Programmed Math/Cosine


text:
User talk:195.194.188.5

Come introduce yourself at the new users page. If you have any questions, you can ask there or contact me personally. (Donovan|Geocachernemesis|Interact) 12:19, 13 July 2005 (UTC)

title: User talk:195.194.188.5


text:
Cookbook:Damper (Australian Campfire Bread)

| Cuisine of Australia

Damper is Australian bushman's bread, made while camping or "waltzing matilda" (carrying a swag around looking for work). It is meant to be made outside by a campfire.

Ingredients

 * 1 large cup self-raising flour
 * 1 generous pinch salt
 * scant ¼ cup water (more and it will be as tough as an old boot)

Procedure

 * 1) Add salt to flour.
 * 2) Add water, then mix and form into a round loaf.
 * 3) Dig a 1 foot-deep hole near a fire, and fill it with 2 shovels of hot coals and ash.
 * 4) Add damper mixture to a greased camp oven (traditional cast iron round pot with lid).
 * 5) Cook in the hole for a maximum of 40 minutes. If undercooked it will be flat and rubbery.
 * 6) Your first try may be inedible. Keep trying, you'll soon be an expert.

Notes, tips, and variations

 * This cookbook also has a Drover's damper recipe.
 * You can do this in a barbecue grill with the mixture in greased metal foil as well. During cooking, damper increases in volume by ⅓ to ½, so allow room for expansion.
 * If you aren't outdoors, just add mixture to greased oven tray and bake in a moderate oven for 30–40 minutes.


text:
Cookbook:Drover's Damper

| Australian Cuisine

Drover's damper is Australian bread, made by stockmen while taking care of or rounding up stock. It is meant to be made outside by a campfire. This is the "flash" version, made when butter and milk are available.

Ingredients

 * 2 cups self-raising flour
 * ¼ teaspoon salt
 * 2 teaspoons sugar
 * 1 tablespoon butter
 * 1 cup milk

Procedure

 * 1) Add salt to flour, then add sugar.
 * 2) Rub in butter.
 * 3) Mix in milk to make a medium-soft dough.
 * 4) Knead lightly on flat surface until smooth.
 * 5) Pat dough into a round shape.
 * 6) Place damper mixture on coals or hot ash. Cook for maximum of 40 minutes.
 * 7) Discard burnt outside and eat the inside.
 * 8) Serve with butter, (golden syrup) or jam.

Notes, tips, and variations

 * This cookbook also has an "ordinary" damper recipe.
 * You can do this using a hole near the fire in a greased camp oven or greased aluminium foil in a barbecue.
 * If you aren't outdoors, just add mixture to greased bread tin, brush with milk and cook in a hot oven, reducing heat until cooked (20 minutes).
 * You can add dried fruit to make "Johnny Cake".
 * As a variation, add grated cheese.
 * Use beer instead of milk to make "Beer Damper".

title: Cookbook:Drover's Damper


text:
Diagnostic Radiology/Musculoskeletal Imaging

Musculoskeletal imaging is a specialized branch of medical imaging that focuses on visualizing and diagnosing disorders and conditions related to the musculoskeletal system, which includes bones, joints, muscles, ligaments, tendons, and other connective tissues. Various imaging modalities are employed to assess and diagnose musculoskeletal conditions. Here are some key aspects of musculoskeletal imaging:

 * Imaging Modalities:
 * X-rays (Radiography): X-rays are commonly used to visualize bones and detect fractures, joint dislocations, and bone abnormalities. They are a quick and readily available imaging option.
 * Magnetic Resonance Imaging (MRI): MRI provides high-resolution images of soft tissues, making it ideal for assessing ligaments, tendons, muscles, and joint structures. It is commonly used to diagnose conditions like ligament tears, tendon injuries, and joint disorders.
 * Computed Tomography (CT): CT scans are valuable for detailed evaluation of bones, especially in cases of complex fractures, bone tumors, and spinal conditions. They can provide 3D reconstructions for surgical planning.
 * Ultrasound (Sonography): Ultrasound is used to examine soft tissues, such as tendons and muscles, as well as to guide needle placement for procedures like joint injections.
 * Nuclear Medicine Imaging: Bone scans, positron emission tomography (PET) scans, and single photon emission computed tomography (SPECT) scans are used to assess bone and joint diseases, including cancer, infection, and metabolic disorders.

 * Common Musculoskeletal Conditions and Applications:
 * Fractures: X-rays and CT scans are essential for evaluating the location and severity of bone fractures, helping in treatment decisions.
 * Arthritis: Imaging can aid in diagnosing various types of arthritis, including osteoarthritis, rheumatoid arthritis, and ankylosing spondylitis.
 * Soft Tissue Injuries: MRI is particularly useful for diagnosing injuries to tendons, ligaments, muscles, and cartilage. Common conditions include rotator cuff tears, ACL injuries, and meniscal tears.
 * Spinal Disorders: Imaging helps in assessing spinal conditions such as herniated discs, spinal stenosis, and vertebral fractures.
 * Bone Tumors: CT and MRI scans are used to evaluate bone tumors, both benign and malignant.
 * Infections: Imaging can detect bone and joint infections, such as osteomyelitis and septic arthritis.
 * Sports Injuries: Musculoskeletal imaging plays a critical role in diagnosing and monitoring sports-related injuries, such as stress fractures and tendonitis.

 * Interventional Procedures:
 * Image-Guided Injections: Musculoskeletal imaging, especially ultrasound and fluoroscopy, is used to guide injections into joints or soft tissues, providing accurate delivery of medications or contrast agents.
 * Biopsies: Image-guided biopsies can help diagnose musculoskeletal tumors or infections.

 * Pediatric Musculoskeletal Imaging:
 * Imaging in children may require specialized techniques due to differences in anatomy and the need to minimize radiation exposure. Ultrasound and MRI are often preferred for pediatric musculoskeletal imaging.

Musculoskeletal imaging is essential for diagnosing and managing a wide range of conditions that affect the musculoskeletal system. It helps healthcare professionals make informed treatment decisions, plan surgeries, and monitor the progress of treatments and rehabilitation. Radiologists, orthopedic surgeons, rheumatologists, sports medicine specialists, and other healthcare providers use these imaging techniques to provide optimal care for their patients.

Musculoskeletal Radiology

 * 1) Aspects of Basic Science Related to Bone
 * 2) Techniques Relevant to Musculoskeletal Radiology
 * 3) Normal Features and Variants
 * 4) Congenital and Developmental Abnormalities of the Spine
 * 5) Congenital Anomalies and Dysplasias (Basic)
 * 6) Congenital Anomalies and Dysplasias (Advanced)
 * 7) Infection
 * 8) Tumors and Tumor-Like Lesions (Basic)
 * 9) Tumors and Tumor-Like Lesions (Advanced)
 * 10) Soft Tissue Lesions
 * 11) Trauma
 * 12) Metabolic, Systemic, and Hematologic Disorders (Basic)
 * 13) Metabolic, Systemic, and Hematologic Disorders (Advanced)
 * 14) Joint Disorders

These broad categories are adapted from those developed by the Education Committee of the American Society of Musculoskeletal Radiology, 1997-1998.


text:
Diagnostic Radiology/Musculoskeletal Imaging/Infection

Basic concepts

1. Routes of spread a. Hematogenous b. Spread from a contiguous source c. Direct implantation

2. People a. Infants b. Children c. Adults d. Intravenous drug users

Osteomyelitis

1. Terminology a. Sequestrum b. Involucrum c. Cloaca d. Brodie abscess e. Sclerosing osteomyelitis of Garre

2. Organisms a. Bacterial b. Tuberculous c. Fungal d. Syphilis e. Rubella f. Leprosy g. Lyme disease h. Bacillary angiomatosis i. Parasitic infection j. Hydatid disease k. Cysticercosis

3. Miscellaneous a. Sarcoidosis b. Osteitis pubis c. Pyomyositis d. Gas gangrene e. Ainhum f. Necrotizing fasciitis g. Chronic multifocal osteomyelitis h. SAPHO Syndrome i. Septic Arthritis


text:
User:Rosiemary

Kellen 17:28, 13 July 2005 (UTC)
 * Please also check out the Cookbook policy page and the Cookbook talk pages.

title: User:Rosiemary


text:
Diagnostic Radiology/Musculoskeletal Imaging/Infection/Basic Concepts

 * 1)  Routes of spread
 * 2)  Hematogenous
 * 3) Spread from a contiguous source
 * 4)  Direct implantation
 * 5)  Sites of localization
 * 6)  Infants
 * 7)  Children
 * 8)  Adults
 * 9)  Intravenous drug users


text:
Diagnostic Radiology/Musculoskeletal Imaging/Infection/Osteomyelitis

1. Terminology a. Sequestrum b. Involucrum c. Cloaca d. Brodie abscess e. Sclerosing osteomyelitis of Garre

2. Organisms a. Bacterial b. Tuberculous c. Fungal d. Syphilis e. Rubella f. Leprosy g. Lyme disease h. Bacillary angiomatosis i. Parasitic infection j. Hydatid disease k. Cysticercosis

3. Miscellaneous a. Sarcoidosis b. Osteitis pubis c. Pyomyositis d. Gas gangrene e. Ainhum f. Necrotizing fasciitis g. Chronic multifocal osteomyelitis


text:
Diagnostic Radiology/Musculoskeletal Imaging/Basic Science

Histogenesis of developing bone

 * 1)  Intramembranous ossification
 * 2)  Endochondral ossification
 * 3)  Remodeling

Bone anatomy

 * 1)  Cellular constituents
 * 2)  Osteoblasts
 * 3)  Osteoclasts
 * 4)  Non cellular constituents
 * 5)  Organic matrix
 * 6)  Inorganic matrix

Bone physiology

 * 1)  Mineralization of bone
 * 2)  Calcium homeostasis
 * 3)  Bone resorption
 * 4)  Bone formation
 * 5)  Humoral regulation
 * 6)  Parathyroid hormone
 * 7) Calcitonin
 * 8) Vitamin D
 * 9)  Osteoprotegerin
 * 10) Other humoral factors


text:
Diagnostic Radiology/Musculoskeletal Imaging/Techniques

A. Radiography 1. Routine views 2. Specialized views

B. Computed tomography

C. Magnetic resonance imaging

D. Fluoroscopy

E. Conventional tomography

F. Ultrasonography

G. Densitometry

H. Leg length or axis determination

I. Bone age determination J. Interventional procedures

1. General considerations a. Evaluation of patients for interventional  proceduresrequires a knowledge  of appropriate  indications and contraindications, objectives, alternatives,  and possible  complications. Coordination with the referring physician is essential to ensure appropriate  patient selection and, for biopsy, appropriate approach.

2. Arthrography, major joints a. Shoulder b. Hip (including prosthesis evaluation) c. Wrist (radiocarpal joint)

3. Arthrography, less common sites a. Wrist (midcarpal joint, distal radioulnar joint) b. Spinal facet c. Sacroiliac d. Knee e. Elbow f. Ankle

4. Percutaneous biopsy a. Presumed metastases b. Presumed primary tumors


text:
Diagnostic Radiology/Musculoskeletal Imaging/Normal Features

A. Sequence of ossification at joints (e.g., elbow)

B. Physiologic radiolucencies

C. Bone island (enostosis)

D. Vascular channels 1. Nutrient canal in phalanx or long bone cortex 2. Vertebral body 3. Scapula 4. Iliac bone

E. Normal sulci 1. Preauricular sulcus (paraglenoid fossa) 2. Rhomboid fossa

F. Supracondylar process

G. Dorsal defect of patella

H. Epiphyseal ossification from multiple centers (e.g., bipartite patella)

I. Irregular epiphyseal ossification (e.g., Meyer dysplasia)

J. Periosteal reaction of infancy

K. Physiologic bowing

L. Transverse (growth) line

M. Vacuum joint


text:
Diagnostic Radiology/Musculoskeletal Imaging/Congenital Spine

 * 1) Os odontoideum
 * 2) Klippel-Feil
 * 3) Sprengel deformity
 * 4) VATER association
 * 5) Vertebral anomaly (e.g., butterfly vertebra, hemivertebra)
 * 6) Spinal dysraphism, meningomyelocele
 * 7) Diastematomyelia
 * 8) Caudal regression syndrome including sacral agenesis
 * 9) Schmorl node
 * 10) Scheuermann disease
 * 11) Limbus vertebra
 * 12) Scoliosis


text:
Diagnostic Radiology/Musculoskeletal Imaging/Dysplasia Basic

A. Developmental dyplasia of the hip

B. Proximal femoral focal deficiency

C. Blount disease

D. Discoid meniscus

E. Foot deformity 1. Tarsal Coalition 2. Talipes equinovarus (clubfoot) 3. Pes planus 4. Pes cavus 5. Metatarsus adductus varus 6. Vertical talus 7. Rocker-bottom foot

F. Congenital pseudarthrosis

G. Madelung deformity

H. Pectus excavatum

I. Pectus carinatum

J. Asphyxiating thoracic dysplasia (Jeune)

K. Thanatophoric dwarfism

L. Achondroplasia

M. Chondrodysplasia punctata (stippled epiphyses)

N. Chondroectodermal dysplasia (Ellis-van Creveld)

O. Cleidocranial dysplasia (dysostosis)

P. Spondyloepiphyseal dyplasia

Q. Multiple epiphyseal dysplasia

R. Dysplasia epiphysealis hemimelica

S. Osteogenesis imperfecta

T. Osteopetrosis

U. Pyknodysostosis

V. Osteopoikilosis

W. Melorheostosis

X. Osteopathia striata

Y. Diaphyseal dysplasia 1. Engelmann 2. Van Buchem

Z. Metaphyseal dysplasia (Pyle)

AA. Pachydermoperiostosis

BB. Nail-patella syndrome

CC. Holt-Oram

DD. Macrodystrophia lipomatosa

EE. Fibrodysplasia (myositis) ossificans progressive

FF. Mucopolysaccharidosis (general findings)

GG. Neurofibromatosis

HH. Tuberous sclerosis

II. Trisomy 21 (Down syndrome)

JJ. Marfan syndrome

KK. Ehlers-Danlos syndrome

LL. Turner syndrome


text:
Diagnostic Radiology/Musculoskeletal Imaging/Dysplasia Advanced

 * 1) Achondrogenesis
 * 2) Hypochondroplasia
 * 3) Pseudoachondroplastic dysplasia
 * 4) Diastrophic dwarfism
 * 5) Metatrophic dwarfism
 * 6) Mesomelic dwarfism
 * 7) Spondylometaphyseal dysplasia
 * 8) Metaphyseal chondrodysplasia (dysostosis)
 * 9) Dyschondrosteosis
 * 10) Idiopathic osteolysis (Hajdu-Cheney)
 * 11) Tarsal-carpal osteolysis
 * 12) Arthrogryposis multiplex congenita (amyotonia congenita)
 * 13) Amniotic band syndrome
 * 14) Mucopolysaccharidosis (MPS) types
 * 15)  Hunter syndrome (MPS II)
 * 16) Hurler syndrome (MPS I-H)
 * 17)  Maroteaux-Lamy syndrome (MPS VI)
 * 18)  Morquio syndrome (MPS IV)
 * 19)  Sanfilippo syndrome (MPS III)


text:
Diagnostic Radiology/Musculoskeletal Imaging/Tumors Basic

A. Natural history

B. Staging criteria

C. Bone lesions

1. Cartilaginous a. Enchondroma i. Ollier disease ii. Maffucci syndrome b. Chondromyxoid fibroma c. Chondroblastoma d. Osteochondroma i. Hereditary multiple exostoses e. Juxtacortical (periosteal) chondroma f. Chondrosarcoma i. Primary ii. Secondary iii. Clear cell iiii. Dedifferentiated

2. Osseous a. Osteoma b. Osteoid osteoma c. Osteoblastoma d. Osteosarcoma i. Parosteal Osteosarcoma ii. Periosteal Osteosarcoma iii. Telangiectatic Osteosarcoma

3. Fibrous and fibrohistiocytic a. Fibroxanthoma (nonossifying fibroma) b. Fibrous dyplasia i. McCune - Albright syndrome c. Fibrosarcoma d. Malignant fibrous histiocytoma

4. Vascular a. Hemangioma b. Angiosarcoma

5. Miscellaneous a. Simple (unicameral) bone cyst b. Langerhans cell histiocytosis (histiocytosis X)          c.  Giant cell tumor d. Aneurysmal bone cyst e. Adamantinoma f. Ewing sarcoma g. Chordoma h. Multiple myeloma/plasmacytoma i. Leukemia j. Lymphoma i. Hodgkin ii. Non-Hodgkin k. Metastasis


text:
Diagnostic Radiology/Musculoskeletal Imaging/Tumors Advanced

A. Bone lesions

1. Cartilaginous a.  Mesenchymal chondrosarcoma

2. Osseous a.  High grade surface osteosarcoma

3. Fibrous and fibrohistiocytic a. Benign fibrous histiocytoma b. Osteofibrous dysplasia (ossifying fibroma of long  bone) c. Desmoplastic fibroma

4. Vascular a. Hemangiomatosis (angiomatosis) b. Gorham disease c. Glomus tumor d. Hemangiopericytoma e. Lymphangioma f. Hemophilic pseudotumor

5. Miscellaneous a.  Lipoma b.  Adamantinoma c.  Primitive neuroectodermal tumor d.  Intraosseous ganglion e.  Epidermoid inclusion cyst

B. Soft tissue lesions

1. Adipose tissue a.  Fibrolipomatous hamartoma of nerve b.  Lipomatosis c.  Parosteal lipoma d.  Liposarcoma (types) i. Well differentiated (atypical lipoma) ii. Myxoid iii. Round cell iiii. Pleomorphic iiiii. Dedifferentiated 2. Vascular and lymphatic a.   Glomus tumor b.   Hemangiopericytoma c.   Hemangioendothelioma d.   Kaposi sarcoma e.  Lymphangiomatosis

3. Fibrous and fibrohistiocytic a.   Elastofibroma b.   Infantile fibromatosis c.  Juvenile aponeurotic fibroma (calcifying juvenile  fibroma) d.   Fibrous hamartoma of infancy e.  Myofibromatosis f.   Fibromatosis coli g.   Dermatofibrosarcoma protuberans

4. Muscle a.   Leiomyoma b.   Rhabdomyoma

5. Peripheral nerve a.   Plexiform neurofibroma b.   Granular cell tumor c.   Clear cell sarcoma d.   Extraskeletal Ewing sarcoma i.   Primitive neuroectodermal tumor ii. Askin tumor

6. Bone and cartilage forming a.   Fibro-osseous pseudotumor of the digit

7. Miscellaneous a.   Myxoma b.   Alveolar soft part sarcoma c.   Epithelioid sarcoma d.   Malignant mesenchymoma e.   Lymphoma f.   Metastasis


text:
User talk:80.218.108.77

Welcome, 80.218.108.77!

Come introduce yourself in the general reading room or your project in the project reading room. If you have any questions, you can ask in the assistance reading room or contact me personally. Kellen 17:47, 13 July 2005 (UTC)
 * Please also check out the Cookbook policy page and the Cookbook talk pages.
 * Also be careful not to destroy pages with existing recipes. The Cookbook:Coconut chutney recipe is different than the Cookbook:Coconut Chutney recipe, and though the naming is bad, both recipes should be preserved until there is some discussion by other contributors.

title: User talk:80.218.108.77


text:
Diagnostic Radiology/Musculoskeletal Imaging/Soft Tissue Lesions

1. Adipose tissue a. Lipoma i. Intramuscular ii. Intermuscular b. Liposarcoma

2. Vascular and lymphatic a. Hemangioma b. Lymphangioma c. Angiosarcoma/lymphangiosarcoma

3. Fibrous and fibrohistiocytic a. Fibromatoses i. Palmar (Dupuytren contracture) ii. Plantar iii. Intraabdominal (Gardner syndrome) iiii. Extraabdominal (aggressive) b. Fibrosarcoma c. Malignant fibrous histiocytoma

4. Muscle a. Leiomyosarcoma b. Rhabdomyosarcoma

5. Peripheral nerve a. Neurofibroma b. Schwannoma c. Malignant peripheral nerve sheath tumor d. Morton neuroma

6. Synovial a. Localized giant cell tumor of tendon sheath (nodular tenosynovitis) b. Ganglion c. Synovial sarcoma

7. Bone and cartilage forming a. Myositis ossificans b. Extraskeletal osteosarcoma c. Extraskeletal chondrosarcoma


text:
Diagnostic Radiology/Musculoskeletal Imaging/Trauma

A. General principles

1. Biomechanics of fractures a.   Relationship of force and deformation b.   Mechanisms of direct and indirect loading c.   Relevant anatomy and terminology

2. Biomechanics of soft tissue injuries

3. Open fractures a.  Mechanism b.   Classification c.   Implications for treatment

4. Gunshot wounds

5. Stress injuries a.   Mechanisms b.   Pathophysiology c.   Epidemiology d.   Imaging diagnosis e.   Implications for treatment

6. Thermal trauma a.   Burns b.   Cold injury

7.  Traumatic myonecrosis

8. Radiation Changes to Bone

B. Trauma in adults

1. Hand a.   Volar plate fracture b.   Gamekeeper thumb c.   Bennett fracture d.   Carpometacarpal dislocation

2. Wrist a.   Scaphoid fracture b.  Perilunate injuries c.   Chronic carpal instability i. Dorsal intercalated segment instability ii. Volar intercalated segment instability iii. Scapholunate Instability iv. Scapholunate advanced collapse d. Triangular Fibrocartilage Complex (TFCC) Tears and Ulnocarpal Impaction e.   Distal radioulnar joint injury f.   Carpal tunnel syndrome

3. Forearm and elbow a.   Galeazzi fracture/dislocation b.   Monteggia fracture/dislocation

4. Shoulder a.   Rotator cuff tear b.   Labral injury c.   Adhesive capsulitis

5.   Clavicle a.   Acromioclavicular joint b.   Posterior sternoclavicular dislocation c.   Post-traumatic osteolysis

6. Thoracic cage

7. Spine a.   Spondylolysis b.   Spondylolisthesis

8. Pelvis and hip a.   Acetabular fracture b.   Hip dislocation c.   Femoral neck fracture

9. Knee a.   Meniscal injury i. Meniscal Cysts ii. Lateral Meniscus Pathology b.   Ligament injury i. ACL Reconstruction ii. Medial Collateral Ligament Injury c.   Extensor mechanism injury i. Jumper's Knee d.   Articular cartilage injury e.   Segond fracture f.   Tibial plateau fracture g.   Osteochondral defect h. Muscle Injury i. Popliteus Muscle Injury

l0. Ankle a.   Mechanisms of injury b.   Ligament injury c.   Peroneal Tendon Injury

11. Foot a.   Calcaneal fracture b.   Lisfranc fracture-dislocation

C. Trauma in children

1. Biomechanics of immature skeleton

2. Growth plate injuries

3. Hand, wrist, and forearm a.   Torus fracture b.   Greenstick fracture c.   Plastic bowing

4. Pediatric Elbow: Common Traumatic Injuries

5. Shoulder

6. Spine

7. Hip a.   Slipped capital femoral epiphysis

8. Knee a.   Osteochondritis dissecans b.   Cortical desmoid

9. Tibia, ankle, and foot a.   Toddler fracture b.    Triplane fracture

10. Battered child a.  Reporting statutes b.   Metaphyseal corner fracture D. Fracture healing

1. Pathophysiology

2. Biomechanics

3. Time course

4. Treatment a.   Casting b.   Hardware

5. Complications a.   Malunion b.   Nonunion c.   Premature physeal closure

E. Post-surgical imaging

1. Indications

2. Principles of treatment

3. Complications

4. Joint replacement

5. Bone grafting

6. Spinal stabilization

7. Limb salvage procedures


text:
User:CoyneT~enwikibooks

Me

 * My name is Coyne Tibbets. I live in Orlando, Florida, USA, where I work as a software architect.

Wiki Memberships

 * Wikipedia user page
 * Wiktionary user page
 * Meta user page

Project Memberships
None yet.

My Other Pages
None yet.

title: User:CoyneT~enwikibooks


text:
Diagnostic Radiology/Musculoskeletal Imaging/Metabolic Basic

Osteoporosis
1. Disuse 2. Related to aging (postmenopausal, senile) 3. Idiopathic juvenile 4. Transient 5. Reflex sympathetic dystrophy

Osteomalacia
1. Dietary 2. Gastrointestinal malabsorption a.   Liver disease b.   Anticonvulsant therapy 3. Tumor induced 4. Renal osteodystrophy 5. Vitamin D dependent rickets 6. Milk-alkali syndrome

Parathyroid disorder
1. Primary hyperparathyroidism a.   Subperiosteal resorption b.   Brown tumor 2. Secondary hyperparathyroidism

Pituitary disorder
1. Gigantism 2. Acromegaly

Intoxication, poisoning
1. Heavy metal (lead) 2. Fluorine 3. Hypervitaminosis A  4.  Hypervitaminosis D

Complication of drug use
1. Prostaglandin (periostitis)

Osteonecrosis
1. Causes 2. Bone infarction 3. Legg-Calve-Perthes disease 4. Freiberg infraction 5. Kienböck's disease 6. Kohler disease 7. Spontaneous osteonecrosis of the knee

Hematologic disorder
1. Sickle cell disease or variant 2. Thalassemia or variant 3. Iron deficiency anemia 4. Hemophilia 5. Idiopathic myelofibrosis 6. Extramedullary hematopoiesis 7. Fatty marrow reconversion

Miscellaneous
1. Hemochromatosis 2. Alkaptonuria 3. Amyloidosis 4. Paget's disease 5. Calcification/ossification secondary to venous stasis 6. Calcification/ossification secondary to paraplegia 7. Hypertrophic osteoarthropathy a.   Primary (pachydermoperiostosis) b.   Secondary (pulmonary, etc.) 8. Infantile cortical hyperostosis (Caffey disease)


text:
Diagnostic Radiology/Musculoskeletal Imaging/Metabolic Advanced

Parathyroid disorders
1. Hypoparathyroidism 2. Pseudohypoparathyroidism 3. Pseudopseudohypoparathyroidism

Thyroid disorders
1. Cretinism, hypothyroidism 2. Hyperthyroidism 3. Thyroid acropachy

Hematologic disorders
1. Erythroblastosis 2. Fanconi syndrome 3. Spherocytosis 4. Thrombocytopenia/absent radius syndrome 5. Polycythemia vera 6. Aplastic anemia 7. Drug-induced myelosuppression 8. Radiation induced marrow changes

Miscellaneous
1. Scurvy 2. Hypophosphatasia 3. Cushing syndrome 4. Mastocytosis 5. Wilson disease 6. Cerebral Palsy 7. Muscular dystrophy 8. Other neuromuscular disorders


text:
Diagnostic Radiology/Musculoskeletal Imaging/Joint Disorders

A. Normal anatomy

1. Types of joints a. Fibrous b. Cartilaginous c. Synovial 2. Intervertebral discs 3. Entheses

B. General features that should be evaluated for each specific disorder

1. Distribution of involvement 2. Soft tissue changes 3. Joint space width 4. Bone density 5. Osteophytes 6. Subchondral lesions 7. Osseous erosions 8. Proliferative new bone 9. Joint deformity 10. Calcification 11. Intra-articular bodies 12. Osteochondral Defect C. Specific diseases

1. Osteoarthritis a. Primary b. Secondary c. Erosive (inflammatory)

2. Inflammatory joint diseases a. Rheumatoid arthritis b. Psoriatic arthritis c. Reactive arthritis d. Ankylosing spondylitis e. Enteropathic spondyloarthropathy f. Juvenile chronic arthritis

3. Septic arthritis a. Bacterial b. Tuberculous

4. Connective tissue disease a. Systemic lupus erythematosus b. Scleroderma c. Dermatomyositis and polymyositis

5. Crystal-associated arthropathies a. Gout b. Calcium pyrophosphate dihydrate (CPPD) crystal deposition disease c. Calcium hydroxyapatite deposition disease

6. Neuropathic osteoarthropathy (neuropathic joint disease) a. Diabetes mellitus b. Syringomyelia

Miscellaneous Disorders
 * 1) Osteochodroses (e.g. Kienbock's)
 * 2) Jaccoud arthropathy
 * 3) Arthropathy associated with acquired immune deficiency syndrome
 * 4) Hemophilic arthropathy
 * 5) Pigmented villonodular synovitis
 * 6) Synovial chondromatosis
 * 7) Lipoma arborescens
 * 8) Osteitis condensans ilii
 * 9) Degenerative disc disease
 * 10) Diffuse idiopathic skeletal hyperostosis
 * 11) Tumoral calcinosis
 * 12) Sarcoidosis


text:
Blender 3D: Noob to Pro/Advanced Tutorials/Python Scripting/Creating a GUI for your script

Often, your script will need to get information from the user, such as parameter settings, before performing its action. You can do this in two different ways: either present a modal popup that the user has to deal with before doing anything else, or alternatively you can take over the entire Scripts Window with a custom display that the user can freely switch to and from while doing other things.

A Modal GUI
The simplest way to add a GUI to your script is to pop up a simple menu with some items to choose from. Let's add an option to our Tetrahedron Maker script to generate the tetrahedron upside-down. Displaying a menu is as simple as calling Blender.Draw.PupMenu and passing it a string containing the menu items separated by “|” characters. Put a “%t” at the end of the item that defines the menu title: The value returned from the call will be the index of the selected menu item (starting from 1, ignoring the menu title), or -1 to indicate that no selection was made.

When you execute the above line, it displays this:

We will use the menu selection to negate a scale factor which will be applied to the Z coordinate of the vertices of the tetrahedron. But only the last vertex has a nonzero Z coordinate, so this is the only one that needs a change in its computation. So the body of our script now looks like this:

A Modeless GUI
It is very easy to create a GUI for your script, and that way make it easy to change aspects of it for everyone.

The command to create a Graphical User Interface (GUI) is:

Blender.Draw.Register(draw,event,button)

This command registers the functions:
 * draw - to draw the GUI
 * event - to action mouse and key presses
 * button - to action GUI button presses

However, this command will NOT work by itself !!!. You first need to define these 3 functions.

First we will import Blender's library of built in functions: import Blender

Next, we will define the draw function. def draw: Inside this function we will draw the GUI. Here is an example of a drawing function we can use. It will clear the current window. Blender.BGL.glClear(Blender.BGL.GL_COLOR_BUFFER_BIT) And the next command will draw a button. Note that the first number in the command, '1' identifies the button as button 1. We will refer to this button later. Blender.Draw.Toggle("Clear origin",1,10,20,100,20,0,"Tooltip")

Next, we will define the event function. The code of a key pressed on the keyboard is passed into the function as the variable evt. def event(evt,val): Now we will test to see if the escape key is pressed: if evt == Blender.Draw.ESCKEY: If it is pressed, exit the script, and return from the function: Blender.Draw.Exit return

Next, we will define the button function. This function will perform an action if the button is pressed. def button(evt): Now test the variable evt which holds the button number that we previously identified. if evt == 1: If it is pressed, we will move the selected object in the 3d window back to the centre and redraw the screen: Blender.Scene.GetCurrent.getActiveObject.loc = (0,0,0) Blender.Window.Redraw

Lastly, we can create the Graphical User Interface by typing the command:

Blender.Draw.Register(draw,event,button)

That's it !!! To enter the script yourself, type the following into the Text Editor window in Blender, and then press alt p to execute the script. Here's the entire script. Everything after the hash # is a comment and can be left out.

Noob Note: When I tried to run that script it came up with an error: Attribute Error: 'Scene' object has no attribute 'getActiveObject'. I changed "Blender.Scene.GetCurrent.getActiveObject.loc = (0,0,0)" to "Blender.Scene.GetCurrent.objects.active.loc = (0,0,0)" and it worked.