text:
French/Grammar/Tenses/Past infinitive

In French, the two forms of the infinitive are present and past. Read on below to learn more about the past infinitive.

Formation
The past infinitive is composed of avoir or être in infinitive form and the past participle of a verb. Note that both avoir and être translate to having in English. This is the same in all composed tenses. The past participle may have an -e or -s added in order to agree with other parts of the sentence. All standard agreement rules that composed tenses follow apply to the past infinitive as well. To make the past infinitive negative, add ne pas in front of avoir or être.
 * avoir parlé - having spoken
 * être allé(e)(s) - having gone
 * Je suis content(e) d'avoir été là. - I am happy of having been there.
 * Je suis content(e) de les avoir vu(e)s. - I am happy of having seen them.
 * Je suis content(e) de ne pas avoir été là. - I am happy of not having been there.

Usage
The past infinitive is always used only after prepositions, such as de, après, or sans. To express a similar idea without a preposition, the composed present participle is used.
 * Je suis parti(e) sans avoir entendu la fille. - I left without having heard the girl.
 * Je suis parti(e) après avoir entendu la fille. - I left after having heard the girl.
 * Je suis parti(e) ayant entendu la fille. - I left having heard the girl.

Francés/Gramática/El verbo/Tiempos/L'infinitif passé

title: French/Grammar/Tenses/Past infinitive


text:
User talk:Zak~enwikibooks

Falsche Freunde
Hallo, Zak! Schön, dass Du das Projekt um eine obersorbisch-niedersorbische Seite erweitert hast, sehr spannend! Ich glaube, Du wärest der Richtige, um die noch benötigten obersorbischen und niedersorbischen Übersetzungen zu besorgen. --Daniel Bunčić 09:54, 7 March 2006 (UTC)
 * Ich hab mal paar Übersetzungen erledigt. Falls ich was übersehen habe, einfach darauf hinweisen und ich schau´s mir mal an. Ein Artikel über Obersorbisch und Niedersorbisch war mir jetzt erstmal zu viel. :D --Zak 16:07, 7 March 2006 (UTC)
 * Super, danke! Du solltest jetzt nur noch auf der obersorbischen und niedersorbischen Diskussionsseite vermerken, dass Du die Übersetzungen gemacht hast, damit dort wirklich nur noch benötigte Übersetzungen aufgelistet sind. (Vielleicht ist es sogar sinnvoll, ausnahmsweise mal bestehenden Text einfach zu löschen, um die Seite lesbarer zu machen.) Liebe Grüße! --Daniel Bunčić 16:16, 7 March 2006 (UTC)
 * ok, hab alles rausgestrichen, was ich schon übersetzt habe. Jetzt müsst ihr wieder neue Sachen auflisten, die ich erledigen soll. :D Naja die Artikel müssen ja noch gemacht werden. --Zak 20:39, 7 March 2006 (UTC)
 * Danke! Ja, Arbeit ist noch genug, aber ich hoffe mal, dass sich da noch mehr Menschen finden, die mithelfen. Apropos Menschen finden, hast Du schon gewählt? :-)
 * :-) Wir danken für Ihre Stimme! --Daniel Bunčić 19:49, 8 March 2006 (UTC)
 * Na wer wird denn jetzt mit dem siezen anfangen? ;-) --Zak 00:16, 9 March 2006 (UTC)

Help with German Wikibook
Hello I was wondering if you like to help with the development of the German Wikibook, it need much help and more activity, and since you area native German speaker, would you like to help?

--German Men92 17:47, 25 March 2006 (UTC)

Your account will be renamed
Hello,

The developer team at Wikimedia is making some changes to how accounts work, as part of our on-going efforts to provide new and better tools for our users like cross-wiki notifications. These changes will mean you have the same account name everywhere. This will let us give you new features that will help you edit and discuss better, and allow more flexible user permissions for tools. One of the side-effects of this is that user accounts will now have to be unique across all 900 Wikimedia wikis. See the announcement for more information.

Unfortunately, your account clashes with another account also called Zak. To make sure that both of you can use all Wikimedia projects in future, we have reserved the name Zak~enwikibooks that only you will have. If you like it, you don't have to do anything. If you do not like it, you can pick out a different name.

Your account will still work as before, and you will be credited for all your edits made so far, but you will have to use the new account name when you log in.

Sorry for the inconvenience.

Yours, Keegan Peterzell Community Liaison, Wikimedia Foundation 23:55, 17 March 2015 (UTC)

Renamed
 This account has been renamed as part of single-user login finalisation. If you own this account you can |log in using your previous username and password for more information. If you do not like this account's new name, you can choose your own using this form after logging in: . -- Keegan (WMF) (talk) 05:40, 19 April 2015 (UTC)

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

title: User talk:Zak~enwikibooks


text:
Template:Booland

vi:Tiêu bản:Booland

title: Template:Booland


text:
Straw Bale Construction/Resources

Related Resources
Here you can find technical reports to help you convince your friends and building inspectors, contacts to help you and give you advice and support, and some registries of straw bale buildings so you can see what others have done before you.

Content

 * 1) Technical Studies, Reports and Tests studies of Thermal Properties, Fire safety, Construction Strength, Moisture Issues, links to some Building Codes and a few bits and pieces
 * 2) Worldwide organisations and contacts contains a comprehensive list of contact from around the world so you can find someone near you, and you can use one of the email lists to ask for help and advice.
 * 3) Straw Bale Building Registries contain many examples of Straw Bale buildings in different climates and regions.
 * 4) Resources on the internet are many and varied, this is a collection of links to sites with useful information for straw bale builders.

title: Straw Bale Construction/Resources


text:
Wikibooks talk:Naming policy/Archive 2

Colon convention and interwiki links
What if someone creates a "cookbook" wiki, and someone adds "cookbook" to Interwiki map? Does this means that all Cookbook links on Wikibooks, like this link Cookbook:Recipes, start failing? That is, do interwiki links conflict with our colon convention? --Kernigh 20:37, 8 November 2005 (UTC)

 * Raises a good point, but i can't imagine anybody naming a new wiki something that doesnt have the wiki-prefix attached. I can see a "wikicooks" or something like that spring up, or a "wikicookbooks" or something. All of the new books that I have been working on all use the forward-slash convention anyway, i think that's the best way to go. --Whiteknight T C E 20:49, 8 November 2005 (UTC)

Our current Interwiki map is bloated. I can do Cookbook and cat. What if someone copies "Cookbook" from the default PmWiki InterMap? (I was surprised to encounter a "cookbook:" wiki, but at least there might not much interest in linking to PmWiki recipes from MediaWiki wikis.) --Kernigh 06:19, 14 December 2005 (UTC)

Colon Convention Usefulness
Could someone explain to me the use of colon convention? I personally think it makes more work for writers, isn't a practice used in other Wikis, and causes a lot of trouble with the MediaWiki software. I like the idea of removing the acceptance of colon convention from this policy entirely. To me, slash notation is a lot cleaner and there's a lot more experience with it by many. If this seems acceptable, I would hope there'd be an effort to refit all existing books, especially Cookbook. Colon notation seems rather obsolete. -Matt 21:56, 13 December 2005 (UTC)
 * I agree wholeheartedly. there are no benefits to the colon convention, and there are benefits to the slash convention. -- 22:32, 13 December 2005 (UTC)
 * I'd like for the section to be removed from the policy then (if more people support it). The real problem is getting all the old books fixed up, but I really think getting this policy moved to "enforced" first is a step in that direction. Some Wikibooks' organization is atrocious (some books have even gone as far as having several of their pages be root right off of wikibooks.org) and I think that to get this site some more respect we need to get it more organized. -Matt 23:30, 13 December 2005 (UTC)

 * The current reason for colon convention seems to be to avoid renaming several existing pages, including the Cookbook pages. However, I do prefer slash convention for books that I edit, and I did mention the conflict with interwiki links in the previous thread. But my one reason for supporting colon convention is that I currently use it in the category and template namespaces (especially as Guide to X11:stub does not match any submodule "Guide to X11/stub"). --Kernigh 06:23, 14 December 2005 (UTC)

 * That is a good point. We could keep the colon convention around for use in templates, because in templates, everything is already in the Template: namespace. -- 15:11, 14 December 2005 (UTC)

 * I agree that Template should stay around (should have specified that since I never wanted it gone to begin) since it is a proper use of the convention. One thing we may want to add to this policy is that the colon convention should only be used by things like templates, but to keep the templates within a structure of their own based on the book. The Guide to X11 is close to an example of what I'd like. It's not just "Template:Xinerama" or something like that but "Template:Guide to X11/Xinerama." It might not be a bad idea to keep the templates structured this way. Is there a problem with that implementation? -Matt 15:33, 14 December 2005 (UTC)

 * With respect to the Cookbook, one reason for using the colon convention is that the book is supposedly supposed to get its own namespace (indicated by "namespace:") and leaving it as-is would relieve any updating of links. When this happens is of course completely up to wikimedia administrators and developers so who knows. Also, unlike other books, the Cookbook has much less structure, so I think most pages would end up just being "Cookbook/Recipe Name" anyway... Kellen T 14:49, 16 December 2005 (UTC)

 * With the cookbook, i can understand it. Cookbook isn't exactly a "book" in the sense that you can't coherently read it in order. Giving Cookbook a namespace helps to keep all the unrelated material together in one place. However, i don't think that we should just give an entire namespace to every little new book that comes along. Few books are going to have the depth and scope that the cookbook has. -- 15:39, 16 December 2005 (UTC)

 * I read somewhere that someone planned for a "Cookbook" namespace, but so far it has somehow never been created. --Kernigh 23:24, 18 December 2005 (UTC)
 * The problem is that only those with developer access to the wiki's PHP can add a namespace, so it's a slow process. Heck, I asked to enable .ico uploading a while back and I betcha that's still not done either... GarrettTalk 23:45, 18 December 2005 (UTC)

 * I have made changes to reflect the recent discussions. Hopefully this will help out the organization here. -Matt 18:33, 26 December 2005 (UTC)
 * Generally, good. Slash convention is much more helpful. -- LV (Dark Mark) 16:00, 28 December 2005 (UTC)

As a FYI, the Cookbook namespace is currently up, and has been, from atleast December 20. Gentgeen 13:04, 2 January 2006 (UTC)

I changed Naming policy so that colon convention would be allowed for Cookbook and Categories, in addition to Templates.

Do we want to allow something like "Category:Bookname/Something". Or should it always be "Category:Bookname:Something"? --Kernigh 03:00, 11 January 2006 (UTC)

 * Since cats have no automatic parent I don't think it matters what is used, as long as it's placed within the parent cat and the implied parent cat actually does exist. GarrettTalk 09:24, 11 January 2006 (UTC)

 * Well, I personally prefer something like "Cookbook:Soup/Chicken Noodle", but that's just me. Unsure about the difference for categories though. -- LV (Dark Mark) 21:54, 12 January 2006 (UTC)

 * Actually, it would probably work best to use colon after anything that is not a namespace, for example "Template:Guide to X11:stub" instead of Template:Guide to X11:stub. Otherwise, the would suggest that "Guide to X11" was the namespace, like with  . (I moved "Wikibooks:Template messages:toc" to Template:Template messages. --Kernigh 04:57, 30 January 2006 (UTC)) In fact, if I created "Template:Cookbook:Development", I probably would not be able to use it. --Kernigh 01:10, 18 January 2006 (UTC)

one way that colons work better than slashes
"colon convention? I personally think it makes more work for writers"

I have found one way that colons work better than slashes. Writers often refer to other chapters of the book. Writers spend less effort and are less likely to make mistakes when they use the pipe trick. But the pipe trick only works when titles use colon or the parentheses. (How do I file a bug report to request that the pipe trick be improved, so that it also works when titles contain slashes?) Because of the pipe trick, take less work than using the slash to write . --DavidCary 17:41, 14 January 2006 (UTC)
 * Sweet Potato Electrical Power Embedded System Basics (see the colon?) or
 * Sweet Potato Electrical Power Embedded System Basics (see the parentheses?)
 * Sweet Potato Electrical Power Embedded System Basics (see the slash and the extra typing?)

 * I agree that pipe trick is a great thing. I'm disappointed that it does not work with slash convention links. --Derbeth talk 19:10, 14 January 2006 (UTC)

 * I would also expect that the pipe trick works for subpages. There is already a bug report for this: . But take into account that subpages also provide shortcuts for brevity, e.g. you can use /Subpage/ which resolves into /Subpage/. ManuelGR 03:36, 15 January 2006 (UTC)

 * I didn't know that. That trick will save me some time. Thank you. --DavidCary 00:44, 18 January 2006 (UTC)

Adding book name to the end?
Inside the movie making manual, check out the category "Category:Writing movies": It's difficult to quickly scan through this page and only read the page titles ("Certification", "Downloading Scripts", "Logline"...), since the linked articles don't begin with this title. Couldn't we add the book name to the end of a book and shorten it, as in "Certification (mmm)", "Downloading Script (mmm)" and so on? Or is there a technical way around this problem, like displaying the alt-name of the category-tag from the linked page? Thanks for any help! Cramer 22:59, 16 January 2006 (UTC)

 * I see. Yes, that's a good argument for the historical "disambiguation convention"  once used in some books (and still used at Wikipedia). Categorization has a few tricks, but don't see any that do exactly what you want. --DavidCary 00:44, 18 January 2006 (UTC)

 * Free Culture uses an opposite format, . --Kernigh 02:13, 18 January 2006 (UTC)

 * Actually, a style like "Certification (mmm)" would make categories easier to read, but it would also make Special:Allpages harder to use. I consider both categories and special pages to be mostly for editors, not readers. I think that slash convention (like Guide to X11/Starting Sessions) is important, because MediaWiki generates a link for readers back to the front page Guide to X11, and many editors otherwise forget to include such a link (consider Civ:The Basics or Energy (GCSE science).) --Kernigh 02:13, 18 January 2006 (UTC)

 * For subpages in categories there is a workaround — setting the sorting key to the title after the slash. But for the Special:Allpages problem for disambiguation pages there is no workaround. By the way, better that Special:Allpages for books, is Special:Prefixindex. See Special:Prefixindex/Ada Programming/, for an example. This would not work for "Chapter (Book)". ManuelGR 20:39, 18 January 2006 (UTC)

 * Well, it's only a partial workaround - the pages are sorted correctly, but displayed incorrectly. I never use Special:Allpages, but if somebody else uses it, I can feel your concerns. I guess the only way around it is to have a different naming space for every book, like wikicities where every new wiki gets their own domain. Could we implement such a thing here? Cramer 18:40, 5 February 2006 (UTC)

Bad Tactics

 * I have no problem with the concept of coming up with a standard for naming modules, and I am in general agreement with the proposed policy. But I strongly object to placement of banners on modules that appear not to presently fit the suggested naming "rule". These banners are essentially a form of vandalism to the book or module. If they are intended to convey a suggestion (that renaming is in order), then they belong on the discussion page of the module where any information intebnded for contributors is placed. What was one of the real pluses of working at Wikibooks, was the lack of editors with nothing better to do than run around imposing their idea of what is correct on contributing editors work. This phase has apparently ended here. - marsh 19:13, 22 January 2006 (UTC)

 * I don't understand you. It is a common Wikipedia rule to place cleanup messages at front of page, not discussion page. Discussion pages are rarely visited and the purpose of cleanup-NC is to encourage book visitor to help change its naming convention. The template was ment for orphaned books without active contributors, where it's not easy to get help from book authors. --Derbeth talk 21:56, 22 January 2006 (UTC)

 * The problem is that we can't do the changes outself. The police allows for some freedom and it is up the authors and contributors of the book to decide how to structure the book. Also: rename is often uses where we only suspect the page to belong to some paricular book. Take Melon for example. It can't stand on it's own (Wikibooks is not Wikipedia) and it is linked from Nutrition and Edible Plants and could belong to either book. All we can do is mark the book and hope that the authors and contributors take the hint. --Krischik T 07:16, 23 January 2006 (UTC)

 * Inappropriate POV use of cleanup message box. I think that cleanup message boxes should not be used, even on discussion pages, to attempt to enforce a rejected policy or a proposed policy.  The proposed consistent naming policy appears to have lost in previous voting.  Pages should not be marked with official-looking cleanup message boxes to hint to readers that the page is in violation of policy when it is not in violation.  And, especially, a bot should not be used to find and mark such pages as needing "cleanup". KHatcher 13:41, 26 January 2006 (UTC)

 * Excuse me, I'm not a bot, so why do you write about bots inserting cleanup messages? I was marking for cleanup books that had completely wrong naming convention. We were discussing some proposals here, but we all agree that pages shouldn't have titles like "Introduction" and book having chapters "Basic Ecology Contents", "Ecology Introduction", "Ecology: Species and Populations" and "Invasive Species Glossary" are not named properly. There are some generally accepted depreciated naming conventions: "Chaptername" and "Book Chaptername", which shouldn't be used. I think in such cases inserting cleanup message is a right decision. --Derbeth talk 17:44, 26 January 2006 (UTC)

Icelandic Wikibook, naming conventions, etc.
Guid day to ye. I'm still bewildered by what you meant by the "naming conventions". What was the name of the Icelandic Wikibook before it was changed (if it was changed)? - 20:37, 22 January 2006 (UTC) The Great Gavini

Separating enforced and proposed part of the policy
I'm tired of endless discussion of every paragraph of the policy. If we maintain current speed of dispute, we won't prepare complete policy this year. I think that we keep focusing on details with detriment to the whole policy. My suggestion is to divide naming policy into two parts: one we have reached consensus on, and other we are discussing. First will be marked as enforced, second as proposed policy. I would see most of the current article in first part, including title delimiter rules and page structure. As we still have doubts about categories, templates and aliases, these paragraphs will be marked as proposed.

As for me, I would support every consistent policy, regardless which shape it will have. I find current policy mature and well-written, maybe excluding part concerning category naming, but I would accept it. --Derbeth talk 22:30, 22 January 2006 (UTC)

Clear out the votes
I was thinking about clearing the votes. Many of those who have voted have not revised there vote (at least not that I noticed). Yes: seperate the page, clear the votes, start again and hopefully this time we get a consensus.

As for me: I was the first to vote "yes" as I allways thought: "good enough and better then no policy at all". But then came the "nit pickers" who are never satified.

--Krischik T 07:04, 23 January 2006 (UTC)
 * I would support clearing the votes. Go for it? You're the admin. -Matt 02:07, 24 January 2006 (UTC)
 * I decided to archive the top of this talk page, including the old poll. This allows someone to start a new poll. The old poll is in /Archive 1 if someone needs it. --Kernigh 07:47, 24 January 2006 (UTC)

Problems with forcing article titles to be computer filenames
The articles (modules) written for Wikibooks need to have a good title (something your English teacher would have approved as an appropriate title) and also a concise filename (something your computer programming teacher would have approved) for use in programming functions such as linking to the article and showing its hierarchy within the chapter and book. This was easy on Wikipedia, because each article (module) could have a short title (encyclopia articles typically do have short titles) which could also serve as the filename. And the Wikipedia articles do not have to link back to any higher level article, so the automatic Table of Contents box on Wikipedia only needs to show the downward hierarchy of any sections and subsections within the article, but it does not need to show any upward hierarchy. But the Wikipedia page naming method and the Wikipedia auto TOC do not really fit the needs of Wikibooks. For example, suppose that the editor for a book on Windmills would like to invite a respected historian to contribute an article (module, or section of the book) on the topic of history of the traditional American farm windmill. The historian may wish to call his article, "History of the Traditional American Farm Windmill." The historian might not like to have his article forced to be named: Windmills/History/Farms/American or any other article title which looks like a computer file name. He might not accept the invitation to write the article is he is forced to use some computer convention in naming his work. Forcing the current proposed Wikibook:Naming Policy may make it harder for book editors to recruit the best people to write the articles. --KHatcher 16:02, 27 January 2006 (UTC)

Has anyone heard of a high quality book publisher (for printed books) who requires book editors and authors to name their book sections according to a hierarchical format (like a computer file structure) as proposed on the WB:Naming Policy page as follows? Lifeforms/Animals/Insects/Butterfly I think that removing ability of book editors and authors to name their work could make many of them unhappy and likely to look elsewhere for a kinder book publisher. The reason for the current proposed policy (requiring a computer file naming structure as the Wikibook page naming convention) is to show the hierarchical position of the page within the book, and also to help readers quickly navigate to the next higher level section. But there might be a better way to do this than using the page title for this purpose. We need to find a way to meet both objectives: (1) let authors provide best title for the page, and (2) provide a way to show page hierarchy and quick link to the "parent" page. KHatcher

 * http://www.pmwiki.org/wiki/PmWiki/Directives#title - But I guess that's a feature request if we want that in MediaWiki as well --Krischik T 07:20, 26 January 2006 (UTC)

 * The recommended alternative to the name "History of the Traditional American Farm Windmill" is not "Windmills/History/Farms/American" but rather "Windmills/History of the Traditional American Farm Windmill." The former alternative may be offputting to a historian, but the second is considerably less likely to be so.  The proposed policy does not require a hierarchical naming scheme.  In particular, it does not require a name like "Lifeforms/Animals/Insects/Butterfly."  The hierarchical naming scheme is given as one alternative, and not even as the recommended one.  The flat naming scheme is given as the recommended alternative.  In it, the butterfly page becomes "Lifeforms/Butterfly".  If even this seems a bit offputting, remember that this is an example used to illustrate the difference between the flat and hierarchical schemes.  For a real book that follows the recommended nameing scheme, see How To Build A Computer which was listed approvingly as an example in the policy.  For a book I'm writing, Formal Logic, I use a mixed scheme.  It has a three level hierarchy with further organization at the the lowest level following the flat naming scheme.  Although not specifically forseen by the naming policy, this plan complies with it.  See also my comment to your Idea 1 below.  --JMRyan 16:04, 28 January 2006 (UTC)

 * Yes, you are right to point out that the flat naming naming scheme is given as the recommended alternative, and that is likely to be less offputting to authors. I like the idea of having alternatives and recommendations regarding the naming scheme to be available to book editors.  But even the flat naming scheme can be awkward when the book title is long and the section title is long.  I just went to my bookshelf and pulled out a random book, to see how authors might be naming their book sections.
 * The book is "An Introduction to Philosophy: Ideas in Confict" (by Peter Y. Windt).
 * Chapter 11 is titled "Perception and Knowledge of the Physical World" and the first section in that chapter is titled
 * "Rene Descartes: 'Sceptical Doubts about Our Knowledge of the Physical World."
 * So the page name for this section would be long and probably spill over into two lines of text. The flat naming scheme could be made less offputting to authors if the first line (the book name before the divider) were in smaller font that the second line (the title of the section), and if the line break came at a logical place such as just after the divider. -- KHatcher 16:22, 29 January 2006 (UTC)
 * Suppose Wikibooks (or WikiCommons) editor wished to import an existing classics book (with permission, of course) and set it up with all the linkages. If the original book had long titles, as above, it would be handy to have a shorthand version to type as links (within the double brackets).  So a page name that is structured as computer filename would be helpful as a shorthand, such as,  PhilosophyIntro:Perception:Descartes for the above case.  Then the pages would look better if the page filename appeared in small font and the actual article title appeared in prominent font.
 * Now there is the second issue of whether to force authors to use the slash as the divider. Using the slash, rather than colon, triggers the feature of automatically putting the backlink to the higher level module (first part of page name before the slash) just under the page name.  But some book editors may prefer to make their own backlink in their own format, and may not want a duplicate automatic backlink put on the book pages.  I think that editors should be free to do this, as long as they do indeed provide some backlink. -- KHatcher 16:22, 29 January 2006 (UTC)
 * Also I think the slash looks less aesthetic in print, because it does not provide enough visual separation between the words.

Unbundling TWO Proposed Policies - Naming and BackLinking

 * The current proposed policy on Naming policy actually combines two proposals. The first is the naming convention and the second is how the article will be linked back to the parent article (module).  Under the current proposal, lower level page names will be required to include the names of higher level modules within their page name, and to separate the multiple higher level names using slashes.  Using slashes in the multilevel page name (instead of colon or dash or space) then triggers the function of automatically showing the backlinks (in small font) just below the page name on each page.  This automatic backlinking feature then either forces the book editor to accept this method of showing backlinking on the pages, or it produces a duplicate backlinking if the book editor has already provided his own system of backlinking and showing page hierarchy.  I notice that User:Marshman already uses his own system of showing page hierarchy and backlinking in his Botany book, and his system looks very nice and looks better than the backlinking system to be forced by the proposed WB:NP. -- KHatcher 16:02, 27 January 2006 (UTC)

Idea 1 - Use page filename and page title

 * One idea is to not try to make the page name serve two different and incompatible objectives at the same time. Instead, separate the two functions by having both a page filename (which shows hierarchy) and a page title (whatever authors want for any new page title).
 * One method of doing this is shown in book on Botany in chapter on Mycoloty, Botany Mycology, where the page name (first line on the page) is allowed to be a computer filename, and the actual page (or chapter) title is written as text in large font.  So the author can select any most appropriate title he wishes.  I would just prefer that the font for the filename be made smaller in comparison with the actual title for the article.  -- KHatcher 16:02, 27 January 2006 (UTC)
 * Another method (as used by Wikipedia) is to let the page name be the article title. Then the page filename would need to be shown in smaller font below the page title, and there would need to be some way for the author to enter the correct title (rather than the page filename) as the first line on the page.  Krischik in his comment (above) offered a possible coding method for doing this.  -- KHatcher 16:02, 27 January 2006 (UTC)

 * The method employed in Botany Mycology does not violate the naming policy, though the page name "Botany Mycology" does. Changing the page name to "Botany/Mycology" to conform with the naming policy would not change the fact that the page employs Idea 1.  In other words, your idea is consistent with the naming policy.  The wiki software provides no support for implementing this idea, but there is nothing, naming policy or otherwise, to prevent you from implementing it by hand as you did in Botany Mycology.  You were concerned above about the offputting name "Windmills/History/Farms/American."  Implementing Idea 1 by hand should soothe the few prospective authors that would be put off by the page name "Windmills/History of the Traditional American Farm Windmill."  --JMRyan 16:22, 28 January 2006 (UTC)

Idea 2 - Improve the auto TOC

 * Second idea (which may even solve two problems in organizing a book):   Improve the automatic table of contents feature on each wikibook page so that it shows the page hierarchy upwards as well as downwards.  Then the reader could click on the higher level section or chapter in the auto TOC to navigate to the "parent" page.

Idea 3 - Status quo with superheadings

 * I prefer the status quo where book authors are still allowed to name their book pages as they think best (and no one sneakily adds a bot-written box on the discussion pages to lure readers to change the "nonconforming" page names into the computer file structure format). Anything to help the book authors (help, not force) to improve the clarity and consistency of page hierarchy and improve quick page navigation within the book will be welcome.  I'd like to make better use of the existing auto TOC feature for this purpose.  Does anyone know how to fix the section numbering within the auto TOC so that the first section is not always numbered as 1.0?  For example, if the page is chapter 4 of the book, I would like for the auto TOC to begin numbering the page subheadings as 4.1 then 4.2 then 4.3 etc.  With ability to control the numbering, I could then show the upward hierarchy for the page in the auto TOC by using some subheadings creatively as superheadings. KHatcher 00:42, 26 January 2006 (UTC)

Idea 4 - Page name using 2 lines and 2 fonts

 * This might be a compromise solution. Using the proposed naming policy (with slashes) sometimes causes long page names which spill over into two lines at top of a page.   The page would look better if this line break occurred at a logical place, such as after the last slash.  That would provide a better visual separation of the book name (on the first line) from the chapter or section name (on the second line).  I suggest making this separation even when the page name is short.  If the first line of the page name (the book title) could be shown in small font, with the second line (the title of the chapter or section) in the existing large font, that might provide a way to meet both objectives.   - KHatcher 14:04, 26 January 2006 (UTC)

I'm strongly sceptical about all these ideas. MediaWiki team is focused on improvements useful for Wikipedia, I don't think they would put much effort on features useful only at a marginal project, which Wikibooks unfortunately is. Even if they started working on it, I won't expect results very soon - should we sit and wait for new MediaWiki version? Moreover, in my opinion there will always be books that won't fit schema of "normal" Wikibooks, having an odd structure which would mess up automatic navigation generating. As for me, we are stick to current naming conventions.

One more thing: what if a module got orphaned? If it was named like "Solution 3" it would be very hard to find it's parent book. If you check orphaned page list, you will see how big this problem is. --Derbeth talk 17:44, 26 January 2006 (UTC)

Examples where filename and title differ
I had a similar problem at Wikisource; the page was called Elements of Style:Form but I wanted the title to be "IV. A Few Matters of Form". I added the title in a manner similar to what Botany does.

Today I adjusted Guide to X11/Building in the same way. At the top of the page:
 * 1) Filename "Guide to X11/Building", which is what I copy and put in double-square-brackets when I want to make a link.
 * 2) Backlink "< Guide to X11" to the front page of the book.
 * 3) Guide to X11 which produces a green box for navigation.
 * 4) Contents automatically inserted by MediaWiki.
 * 5) == Building ==, the title; one can replace it with a longer title without renaming the page.

An older version of the same page only had elements 1 and 2, the minimum needed to label and navigate this book. When I created the page, if I had called it "Guide to X11:Building" instead, the link would be missing, like how Civ:Terminology has no link to Civ. But Botany Mycology is an example of authors providing links without using slash convention. --Kernigh 00:58, 30 January 2006 (UTC)

 * This is a good example, and it shows a professional looking page. It also shows a TOC feature where I have wished for a solution.  Your green box shows that Building is your book's chapter 3, but the automatic TOC shows number 1. Building.  Does anyone know how to make the TOC show the correct chapter, by numbering as 3. Building, with the sections below numbered as 3.1 then 3.2 then 3.3?   -- KHatcher 20:38, 30 January 2006 (UTC)

Idea 5 - Use a Book portal, similar to Wikipedia use of topic portals

 * Wikipedia has several major topic portals to help guide readers to pages which all pertain to a particular topic (Geography, Science, etc.). Might be possible for Wikibooks to also use the portal concept, with Book:Bookname instead of Portal:Geography.  In Wikipedia, each page pertaining to the portal topic then gets a template pointing back to the portal entrance.  Simiilarly, each page on a Wikibook could also get a template (perhaps as the very first code on the page) pointing back to the book mainpage.

Idea 6 - Each book gets own domain name or subwiki, similar to Wikicities projects
See discussion under the subwiki topic (below). Also, on February 5, Cramer asked about giving each book its own domain name, similar to the way that Wikicities gives each project its own domain name. For example, the StarWars wikicity has domain name. This would keep all the pages in a book together within the same domain name, without having to include the book title in every page name.

Where was vote on "deprecated" naming schemes?
The proposed naming policy points out historical conventions which are said to be "deprecated" (which means disapproved and belittled). But I've looked at current talk page and the one archived talk page, and do not see any discussion or consensus about this. Where is it? The archived talk page shows the losing vote for the proposed naming policy, with its push to force consistency in page naming. This losing vote is one reason it is unwise to be pushing readers to enforce this proposal and punishing book editors for "violating" it, when it is only a proposal which has already lost a vote. I'll change the project page to remove implication that these other naming schemes are presently deprecated (rather than proposed to be deprecated). It this change is incorrect (if there has actually already been consensus to deprecate some naming schemes), then OK with me to revert and put the correct information on the page. -- KHatcher 18:04, 29 January 2006 (UTC)

 * I can't imagine situation where there are 10 different, incompatibile naming conventions allowed at a project. That's completely absurd and would end up with making reading and managing books impossible. If we don't have some standards, don't integrate books together, Wikibooks will turn into unorganised host for completely independent, standalone books with small, closed groups of contributors - because every book would have completely different editorial guidelines. Is that what we want?
 * From list of historical naming conventions especially 'no delimiter convention' is the most detrimental and misleading one, it obfuscates book name and makes using automated tools (like bots, but also finding parent book) almost impossible. Wikipedia convention causes the same problem, also disambiguation convention is not convenient in this category. Why we should care about bots? Suppose we have book "Movie making manual" and their authors decided they want the title "Movie Making Manual". But unfortunately first book author started naming pages with one of conventions mentioned above and they have to rename 50 pages manualy. If they had pages named in slash or colon convention, running bot which would alter every page of this book would be very easy.
 * Would someone support me if I started vote on only one subject - to completely forbid all historical conventions (I mean all except colon and slash one) for newly created books? --Derbeth talk 20:30, 29 January 2006 (UTC)

 * A second vote sounds like a good idea. Well, consistency has advantages, and freedom of choice always comes with the risk of making a poor choice (as well as the opportunity to create a better choice than the conventional choice, or just to be a different flavor).  Would you like to remove the user preferences option for Wikibooks?  Before casting my vote, I'd like to hear more from your perspective about the advantages of consistency.  I know that you do a lot of work to help Wikibooks, and I'd like to hear about how consistency can make your work easier.  -- KHatcher 22:53, 29 January 2006 (UTC)

 * Last comment by Kernigh gave me an excellent example on how book could mess up with naming convention. Look at Botany - there are three different naming styles in the main TOC. In my opinion, our policy should clearly dissuade users from giving books such structure.
 * Why consistency is important? Do you imagine that people wanting to contribute to someone else's book have to learn everything from scratch for every single book? It's not important which naming convention we choose, the thing is that we should have only one or maybe two so that readers and contributors won't be confused with every new book. Yes, authors are very creative, but in my opinion they should concentrate on writing content not inventing new naming systems. --Derbeth talk 15:00, 30 January 2006 (UTC)
 * Yes, I think that you have the right idea here about pointing out advantages and disadvantages of   the two approaches (status quo versus proposal 2).  So below there is a new subheading to help with that comparison.  Wikibooks is a collaborative effort of people with various skills - computer programing, editing, knowledge of specific subjects, etc.  The policies need to find a good middle ground, and so discussion from these different perspectives will be helpful. -- User:KHatcher

 * To correct, that vote is not very significant for current discussion. The votes are across a span of six months and the page content changed quite a bit across the "voting time." The votes pointed out important discussion topics at the time but weren't really maintained by those voting. The votes represented an incorrect view of what the policy was becoming and were stricken. There was no "loss" in my opinion since those votes covered way too many issues and were outdated. -Matt 18:09, 30 January 2006 (UTC)

Clear statement of Proposal 2
Proposal 2, as request by Derbeth (above) is "to completely forbid all historical conventions (I mean all except colon and slash one) for newly created books".

 * New books - only slash is allowed as delimiter for page names. Page names must be in format .  Colon as delimiter is reserved to Cookbook only.
 * Existing books - Any convention can be used, provided that book name is included in every chapter title. No cleanup boxes regarding page naming will be used on any existing books.  Existing books must provide their own backlinks on all pages (except slash convention which automatically provides the backlinks).
 * Enforcement - Polite cleanup request can be put on the discussion page (not the module page) of nonconforming new books.  There is no enforcement for existing books.

Clear statement of Status quo
Book editors may use their discretion in naming pages in a new book and existing books. The WB:NP page will provide guidance to help new book editors make an informed choice. Books must provide their own backlinks (using their own format) on all pages, unless slash convention is used to provide the standard automatic backlinking. A template may be used on pages to provide the backlinking to the book title and chapters. The WB:NP will provide advice and examples of such book templates and custom backlinking. -- KHatcher 22:23, 30 January 2006 (UTC)

Proposal 2 - advantages and disadvantages
Pros:
 * consistent, clear, easy to understand for readers and editors naming policy
 * slash convention provides pre-formatted automatic backlinks to the higher level pages (bookname, chaptername)
 * slash convention provides exclusive possiblity to use fast links to subchapters ( /chapter/ ) and sibling chapters ( ../sibling/ ), saving the time for typing the longer form ( bookname/chapter )
 * colon convention: only one applicable for namespaces (which Cookbook is)

Cons:
 * does not let book authors decide which naming convention is best for them
 * forces book section names to look like computer file names, such as: Windmills/Australian farms
 * if authors want to use a better book section title, such as "History of Windmills on Australian Farms" then the page appears to have two large-font titles
 * slash convention inserts a mandatory (no option to turn it off) second line of text on each page with the pre-formatted backlink, which is unnecessary if pages include their own backlinks or book contents template such as Botany example.
 * slash convention causes multiple redundancy with cluttered appearance at top of each page if authors want to use literary titles for book sections instead of computer file names, and also use their own backlinks (or book contents template) instead of the pre-formatted backlinks. -- KHatcher 16:24, 9 February 2006 (UTC)

Status Quo - advantages and disadvantages
Pros:
 * book auhors have full freedom

Cons:
 * two completely different books may link to the same chapter without knowing it (like Contents)
 * makes automatics tasks (use of bots to fix errors) hard
 * may confuse readers and contributors (if a contributor sees two books with completely different naming conventions)
 * two different naming convention in one book are allowed

I think that if good advice is provided at WB:NP, nearly all new books' editors will decide to use the slash convention or the colon convention. But the books' editors will be able to use a different custom page naming scheme if they believe that better suits the book purpose. -- KHatcher 22:23, 30 January 2006 (UTC)

 * I really see no benefits of the colon convention over the slash convention (given that slashes allow for better navigation). Let's require all new books to use the slash convention of  (and if they wish , , etc). It allows for a lot of editor freedom, and has the benefit of clearly segregating each book so that you're never confused as to what book you're reading.

 * Then encourage existing books over to this convention. No doubt, at some stage, we'll then be left in time with a small rump of books that haven't changed over to the slash convention. We can look at forcing the final resistance over then, Jguk 16:23, 10 February 2006 (UTC)

In defense of a slash
(I started writing this comment before the pros and cons heading above was added. I would have written in in a more pro v. con style had I seen it earlier.)

Wikibooks faces a significant organizational challenge that sets us apart from our sister wikis. We write books, not self-contained articles. Because of this, we need some mechanism for organizing our individual modules pages into discrete books. The wiki software provides only very meager facilities for this. We have to do most of the work by adopting some sort of convention or other. The slash naming convention provides three important organizing elements. Whether we adopt the slash convention or some other, adopting any convention will require enforcing some rules. If it is not an enforced policy, then it is not an adopted convention.

1. The slash naming convention helps authors avoid stepping on each other’s page names. For example, book I am working on, Formal Logic, has a page (Formal Logic/Sets) giving a quick and dirty introduction to set theory terminology used in the rest of Formal Logic. There are also set theory chapters of Discrete mathematics, Topology, Puzzles, Beginning Mathematics, and perhaps others. Any number of additional books might want a brief introduction on set theory such as in Formal Logic but geared to their own book. As another example, a chapter on mushrooms might show up in books on botany (the book Botany has a chapter on the broader topic of fungi), cooking, gardening, Super Mario, illegal drugs, or or books to which finding edible mushrooms is relevant (hobbies, survivalism, pig-breeding). The slash convention allows all these current and perhaps future pages co-exist peacefully. This is especially important when a book is mapped out with red-linked future pages. The author is guaranteed he won't be surprised by a name clash when gets around to adding a page to match the red link.
 * These are good points. They are not solely advantages of the the slash convention, however.  They are achieved by all the historical conventions which do use the book name (or its abbreviation) somewhere in the page name.  -- KHatcher 10:35, 31 January 2006 (Note: The post of 10:35, 31 January 2006, was made from IP address 128.192.18.97 while the user was not logged in.)
 * You are not exactly right. Two naming conventions: slash and colon are naturally preferred. One reason is that you can find them in Wikipedia (colon is used in namespaces and slash in subpages). We don't want to embarrass people coming from Wikipedia to Wikibooks by introducing strange naming conventions. Another thing privileging slash and colon conventions are MediaWiki links. You can use "pipe trick" with colon convention:  Cookbook:onions  and another trick with slash convention: <tt> /Subchapter/ ../Sibling chapter/ </tt>. This is impossible with all other conventions. I think these two facts show real advantage colon and slash convention have over other conventions. --Derbeth talk 17:17, 31 January 2006 (UTC)

2. The slash naming convention places a page within a book and lets the reader know where in the book you are. The reader readily sees that he is at this subpage of that chapter of such-and-such a book. At present, for example, it is ambiguous whether Wikibooks has a set theory book. There is a Set Theory link from the Mathematics bookshelf. But Set Theory is a redirect to Topology/Set Theory which may be its own book or may be a chapter of Topology, it’s actually ambiguous which it is. The subpages of Topology/Set Theory have names like Set Theory:Axioms which adds to the confusion. And who knows what book Set Theory:Review review belongs to? It is one of our approximately 1000 orphaned pages. It is entirely unclear whether Set Theory:Review was intended as belonging to Topology/Set Theory. Without an enforced consistent convention which places pages within a book and which lets the reader know where in the book you are, we end up with a big mess.
 * These are good points. They are not solely advantages of the slash convention, however.  They are achieved by all of the historical naming conventions for which the editors do provide backlinks to show position of the page within the book.  It is not necessary to require duplicate methods to show position of the page within the book, both backlinks and the page naming scheme. -- KHatcher 10:35, 31 January 2006

3. The slash naming convention provides automatic back-links. This makes it possible to find pages up the hierarchy and, in particular, find the root or main page of the book. Some authors can’t be bothered to adhere to any naming convention, not even a book-specific convention (see, for example, Botany whose page names vary among approximately three conventions). But even these tend to provide back links within their books. So the importance of back-links seems unquestioned.
 * I agree about importance of back-links. Perhaps the policy should be to require backlinks, rather than to require a particular page naming scheme.  Orphan pages are then defined as those which are missing the backlink to the parent module.
 * That the slash convention provides automatic back-links in a standard style would be an advantage for book editors who like that style, but a disadvantage for book editors who would prefer to have a different style of backlinking, such as by using a template on each page to show the book outline. In that case, the slash convention puts duplicate and unnecesssary backlinking information on the page and also puts duplicate information in the page name about position of page within the book. Some book editors may like to have their own graphic design style for the book, and not be forced to use a standard style or to have duplicate information cluttering up the pages.  Yes, there are some novices on Wikibooks who are sloppy about book set up.  It would good to have a way to deal with this, without harming the competent book editors.  -- KHatcher 10:35, 31 January 2006
 * My apologies for not getting back to this until after the vote started. The issue is not just competent v. sloppy authors.  It is also a issue of mature books v. new books.  Books are frequently created as a few red links and evolve into something useful.  The authors will often not fully know where the  book is going, what the graphic design should be, what sorts of navigational help will be best suited for that particular book.  It would be fairly absurd to start a book and comply with a slash convention (becuase you haven't got all that figured out yet—and then rename all the pages in a freewheeling non-complient way when the book matures and they type of alternative navagation assistance becomes settled.  Besides, it the automatic back-link line really obnoxious?  It does not seem any more obnoxious then the "Redirected from ..;.."  link.  --JMRyan 07:15, 15 February 2006 (UTC)

The slash convention provides these organizational features, but perhaps other conventions could do so as well. The kinds of convention we can adopt divide into two sorts: page name conventions and content conventions. (By content convention, I mean requirements concerning actual page content, the stuff that you type in on an edit page. And by adopting a convention, I mean enforcing a policy.)  Among page name conventions, the slash convention is the only one that will provide all three advantages. The colon convention, and perhaps others, can provide the first two advantages. However, only the slash convention provides automatic back links. Further, no content convention can provide us with the first of these features. So any alternative to the slash convention that provides all three organizational features will have to be a mixture of page and content conventions.
 * I think the Wikibooks uses the term "convention" to mean just the most common methods and not enforced. But term accepted "policy" would mean enforced.  -- 128.192.18.97 15:39, 31 January 2006 (UTC)

Imagine what an enforced content convention ensuring back links would look like. Would it simply say that you must provide some back links of some sort? Back links to the main page? Back links up the page hierarchy (assuming that there is a page hierarchy)? What other standards would they have to meet? Would you be prohibited from adding additional back links? If you think automatic back links resulting from the slash convention are obtrusive and big-brotherish, imagine you would feel about an enforced content policy requiring back-links. The same kind of consideration goes for an enforced content policy requiring the content to include information as to book the page belongs to and where in the book the page is.

I submit that enforcing the slash convention is the best, most robust, least obtrusive, and least big-brotherish means we have of organizing pages into books.

It has been objected that the slash convention restricts author options. For, example, I can’t entitle my page “History of the Traditional American Farm Windmill.” But there is no reason an author can’t provide such a title in the content independently of the page name. Botany Mycology does this, (though the page name does not conform to the slash convention). It has been objected that authors want to provide their own back linking scheme, one which may well work better in a particular book than the automatic back links generated by the slash convention. But there is no reason an author can’t provide his own back linking scheme in addition to the slash convention’s automatic back links. Formal Logic and Guide to X11 do this.
 * These points provide a work-around for the slash convention, by letting authors provide a duplicate page title and a duplicate method of backlinks if they have to use the slash convention but don't like how it makes page names look or how it shows the backlinks. Book editors may not want to have book graphic design style with such duplicate information on all the pages. -- KHatcher 10:35, 31 January 2006

Our authors’ flexibility in how they collect, organize, and back link their pages would be even more constrained if we enforced content conventions concerning these matters. And enforce we must, for otherwise we end up with a mess. Indeed, we already have a mess as indicated by our thousand orphaned pages. In Wikipedia, each article is supposed to be self-contained, so orphaned pages are less important. In Wikibooks, an orphaned page is part of a book that is not really part of a book after all—so orphaned pages are a much more serious affair. Perhaps if the wiki software provided better tools for organizing pages into books, we would not have to enforce a naming convention at all. But it doesn’t, and we have to work with the software we have. --JMRyan 22:48, 30 January 2006 (UTC)
 * I would prefer to continue to look for better tools using wiki software to achieve important organizing goals, while continuing to give book editors choice about book graphic design style. Is there another way to deal with the orphaned pages, such as searching for those having no backlinks and putting them all under an "orphaned book pages" folder (book) for a certain period of time until they are repaired?
 * By the way, why are orphaned pages (with no backlinks) such a serious problem on Wikibooks, when all the pages on Wikipedia have no backlinks?  I don't really see a serious problem here, just perhaps a small aesthetic issue of wanting to look different than Wikipedia.  Could someone please explain?  OK, so Wikibooks would have some pages (maybe a lot of pages) which look like Wikipedia pages.  Why is this bad?  It is not bothering me as a book editor or as a reader of Wikibooks.  Why is it bothering you?  Please see Wikibooks talk:Naming policy. -- KHatcher 10:35, 31 January 2006
 * This write-up explains the many advantages slash has over other conventions. Perhaps we can have a smaller subvote regarding the removal of proposal information and deciding on which method to use? -Matt 02:17, 31 January 2006 (UTC)
 * I completely agree with arguments of JMRyan. I think that current shape of Proposal 2 written by KHatcher is mature and ready for small vote - understood by vote only about which delimiter should be used in books and how to treat books having other that official naming convention. --Derbeth talk 13:46, 31 January 2006 (UTC)
 * Note that Proposal 2 does allow the colon convention, which does not provide automatic backlinks. -- KHatcher 10:35, 31 January 2006
 * In the second proposal, colon convention is only allowed for a few specific uses. Colon convention's current uses in many books (such as Programming: ones) would need to be marked as needing cleanup. I think of this as a very important point to note. Allowing colon convention for book pages is not acceptable under this proposal. -Matt 21:56, 31 January 2006 (UTC)

IP address 128.192.18.97 (signed as KHatcher, forgot to login?) wrote: By the way, why are orphaned pages (with no backlinks) such a serious problem on Wikibooks, when all the pages on Wikipedia have no backlinks?

Actually, every Wikipedia article and Wiktionary entry has a backlink called "Main Page". Also, encyclopedia articles and dictionary entries have predictable names; Wikibooks do not. I have to check a bookshelf to search to know if a book is called Letter writing or "Writing a Letter" or "How to write a letter" or "Effective Letters". --Kernigh 16:27, 31 January 2006 (UTC)

 * I'd like to add that one of the reasons why orphaned modules are such a huge problem on Wikibooks as well is that generally a single module doesn't stand on its own within Wikibooks, unlike Wikipedia. A Wikipedia article, even a stub, is self-supporting and doesn't really depend on any other article to help build its content.  That is one of the reasons why writing a Wikipedia article is generally easier to start or write, as you don't have to do nearly so much preparation.  Writing a whole book, on the other hand, takes a considerably higher level of organization and this policy is an attempt to encourage that sort of organization.  In addition, if you find an orphaned module that follows this naming convention policy, you can usually link it more directly to where it belongs, and sometimes content that would otherwise be deleted immediately as random gibberish can be kept because it can be put into context for what it represents.

 * Consider for a moment this page: Riddles: 28  This page would normally be deleted immediately on Wikipedia, but it is just fine on Wikibooks because of the context it has with the module Riddles.  --Rob Horning 16:40, 31 January 2006 (UTC)
 * Just fine with me, too. And it doesn't use the slash or colon convention, it uses a space-colon convention which looks good on the page.   -- KHatcher 18:03, 31 January 2006 (UTC)
 * My apologies for not getting back to this until after the vote started. I think Rob Horning was talking about the content being okay, not the page name.  The content is just a back link plus the single word "Ladder".  Out of context, such a page would just be trash subject to a speedy delete.  But in context, it is the answer to a riddle posed on another page.  How do we know not to mark it for speedy delete?  Two reasons:  (1) it has a (hand placed) back link and (2) the Riddles page has a link to it.  But what if the author forgot to do (2).  Then it is an orphaned page: one cannot get to by following links.  Now suppose someone moves Riddles to The Book of Riddles, thus breaking the back link.  Or suppose the author mistyped the back link and came up with Fiddles instead.  Three bad things happen.  First, someone reading the Riddles book doesn't find the answer to Riddle 28.  Second, someone else comes along a creates Riddles:28 to answer Riddle 28, thus duplicating the effort of the previous author.  Third, someone marks Riddles: 28 for speedy deletion because they don't know that it actually belongs to a book.  For real (not just hypothetical as here) problems of this sort, see Votes for deletion and Votes for deletion.  --JMRyan 14:05, 15 February 2006 (UTC)

 * I changed statement of Proposal 2. In my opinion, we cannot accept situations like Contents. Even old books with "no delimiter" convention should be fixed. Other ones may stay.
 * I see that the discussion has freezed, should we start vote? In my opinion, current shape of naming policy page is hard to understand for newcomers - there are two concurrent proposals with many points, everything is very complicated. I would like to see simple hint: "name pages like Book/Chapter". --Derbeth talk 11:53, 8 February 2006 (UTC)

 * The "Clear statement of Proposal 2" in Talk differs greatly from what is said on the content page. I support what's on the content page, especially only allowing slash for new pages (and not colon). I thought there was significant discussion here explaining how colon really should only be used like it is outlined on the content page. I think clean-up tags could go on talk pages only, but enforcing the naming policy on old books is a must. Here's what I think:
 * Slash only for new book content
 * Colon allowed on new pages for categories, templates, and Cookbook
 * Clean-up tags can go on both new and existing books, in the talk pages
 * Naming policy enforced on both new and existing pages
 * The "status quo" idea seemed decently defeated here and the "Clear statement of Proposal 2" seems to be bringing in too much openness. I thought that what I just outlined above was largely the concensus, unless I'm missing discussion somewhere. I would vote "no" on the "clear statement" because I don't think it's what's right for organizing the large mess of improperly named pages all over here. -Matt 17:35, 8 February 2006 (UTC)

 * Ok, I made another change to restrict use of colon convention. But I don't agree with your attitude to existing books. Book authors have better things to do than correcting naming conventions. I think that we should leave it as it is and make enforcement a separate vote. Please understand, that we need any naming convention. Current proposal is less restrictive than yours, but it has chanse for wider support. We can always make another votes to change details - like enforcements for old books. Another thing is naming of categories and templates. This issue is completely unimportant for me and I would like to exclude it completely from this proposal to avoid endless discussions and think about it when we have some basic set of rules ready and accepted. We need minimal but clear set of rules now. I would like to break status quo as soon as possible. If you take such restrictive approach, we won't get consensus soon. --Derbeth talk 19:53, 8 February 2006 (UTC)
 * Sounds reasonable to me. I think a lot of the recent bot talk was connected to fixing old colon convention pages so I didn't think authors would have to do too much to get their naming correct. I would support what you say above assuming the details can be figured out later. I think old books that didn't conform would tarnish things, but we can definitely focus on just getting new page guidelines up and running for now. I'd go for a vote. -Matt 23:59, 8 February 2006 (UTC)

 * If you haven't noticed it: vote has begun. See Policy/Vote/Naming policy. --Derbeth talk 09:17, 13 February 2006 (UTC)

Need to include book folder name in all page names? or use small subwiki?
A book such as Study Guide to the Science of Botany has both a book folder name (Botany, at very top of the page) and an actual book title, Study Guide to the Science of Botany. Inherent in Proposal 2 is the requirement to include the book folder name as the first portion of every page name. Why is this needed if the page already includes a backlink to the main page of the book?

User:Kernigh's comment (above) about Wikipedia pages all have backlink to "Main Page" is fortunate because it sparks an idea. Yes, and every Wikibooks module also has a similar backlink called "Main Page" back to Wikibooks, as shown in the navigation box along the left column. Kernigh's observation sparks another idea to solve our problems, perhaps using the navigation box. I notice that Wikicities has a way for each project there to have its own Main Page and URL  Also Wikipedia provides a sub-wiki for each language. Is there any potential to provide something like a subwiki for each book on Wikibooks? This idea is way beyond my poor computer skills, so I hope you can comment on its feasibility. If it succeeded, we would not need to include the book folder name as part of each page name as a work-around to keeping the pages within the correct book, since they would automatically be within the correct subwiki as they were created. Sorry if this is just wild idea, but I think we need to try think broadly and creatively about a solution to help everyone. -- KHatcher 18:03, 31 January 2006 (UTC)
 * I don't think its technically possible, we host hunderds of books. Apart from technical problems, what do you think is easier for a newcomer: note that pages are named like "Book/Chapter" or that each book has its subwiki? --Derbeth talk 18:41, 31 January 2006 (UTC)
 * It was technically possible on Wikipedia, though, for the languages. When Wikipedia had this similar problem, they could have set policy that all pages names have two parts to keep pages together, so articles would be named, for example, "English/History of Windmills".  That would not look so good.  Wikipedia made the better choice, and it is not hard for authors to work within the language subwiki, instead of typing "Language/ArticleTitle" on every page. -- KHatcher 21:04, 31 January 2006 (UTC)
 * Haven't you noticed you need separate account for every language edition of Wikipedia, you can't use templates in one wiki in another etc. In fact distinct language editions of Wikipedia can be treated as separate projects. --Derbeth talk 21:18, 31 January 2006 (UTC)
 * This problem may be fixed, BTW. A common account system has been formally developed and tested, but trying to get it up and running is going to be a big pain in the a*** to try and merge all of the Wikimedia accounts.  Expect to hear more about this in the not too distant future.  As for common templates, yeah, that is going to be a problem.  --Rob Horning 18:24, 5 February 2006 (UTC)

 * Giving each book a separate subdomain would mean to break Wikibooks in a thousand of independent projects. This is technically difficult, a redundancy of effort and against maintaining a unified community. On the other hand, it would be easier to request to the developers a different rendering of root page title and subpage title than convince the Wikimedia foundation to provide a different subdomain for every book. And imagine the pain to suffer for starting a new book. If the arguments against subpages are the ugly subpage titles, then there are better ways to improve them than breaking Wikibooks in a thousand of different wikis. ManuelGR 20:59, 5 February 2006 (UTC)
 * Giving books that want to use different naming conventions/navigation system their own namespace is a lot easier, this has already been done for the Cookbook. Once a book has become a namespace its ID can then be called in CSS and the backlink disabled, or any other necessary thematic changes made. However you'd have to convince the devs, not us, they're the ones implementing it on the PHP side of things. Personally I disagree with it unless it's really irreconcilable (as the case of the Cookbook), as the backlink is very small and can be easily overpowered by making the book's own navigation system more noticeable. Hopefully one day there will be a __NOBACKLINK__ command, but until then this is the easiest solution. GarrettTalk 22:20, 5 February 2006 (UTC)

School_of_Library_and_Information_Science
This is a funny one. I discovered it when I fixed a redirect link. Only after the fix it came to me that Human Resource Management does not actualy belong the the School of Library and Information Science at all (you have to click on edit to actually see the problem ;-) ). But it shows clearly that Wikibooks can not live without an enforced naming convention because the change of overlap is just to great. --Krischik T 14:54, 2 February 2006 (UTC)

 * And something like this doesn't happen in university settings either, where you have a required class for an engineering course on technical writing that is taught by the English department, but only engineering students attend? I've even seen dual-listed department classes (English/Engineering in something like this), which would be the equivalent of having a link on a page like this that is then redirected to another page.

 * This is also yet another reason why Wikiversity needs its own space, to deal with issues like this on their own terms and not have to be forced into conventions required by dealing with textbooks. --Rob Horning 19:25, 10 February 2006 (UTC)

title: Wikibooks talk:Naming policy/Archive 2


text:
Straw Bale Construction/Resources/Technical Studies

General

 * English slides from the Danish report
 * Part of "Straw Bale Houses - design and material properties" prepared by Jørgen Munch-Andersen, Birte Møller Andersen and Danish Building and Urban Research. Slide show of Danish results

Acoustics

 * Air-sound-insulation of clay plastered non-loadbearing sb-wall
 * In Danish only, direct translation requests to user:DuLithgow. Part of "Straw Bale Houses - design and material properties" prepared by Jørgen Munch-Andersen, Birte Møller Andersen and Danish Building and Urban Research. Air-sound-insulation of clay plastered non-loadbearing sb-wall

Insulation

 * Thermal Performance of Straw Bale Wall Systems
 * "In this analysis we provide a summary of the results of research that has been done, examine the implications of each to residential thermal comfort, and suggest a reasonable thermal performance value for plastered straw bale walls as a synthesis of the data." Nehemiah Stone, USA, 2003. Thermal Performance of Straw Bale Wall Systems PDF ?Kb. This document is made available by the Ecological Building Network, for which they request a donation.

 * The Rice Hull House
 * "The rice hulls are unique within nature. They contain approximately 20% opaline silica in combination with a large amount of the phenyl propanoid structural polymer called lignin. This abundant agricultural waste has all of the properties one could ever expect of some of the best insulating materials. Recent ASTM testing conducted R&D Services of Cookville, Tennessee, reveals that rice hulls do not flame or smolder very easily ..." Paul A. Olivier, USA, 2004 The Rice Hull House (PDF 225Kb)

Thermal insulation of earthplastered sb-wall, bale lying flat
 * In Danish only, direct translation requests to user:DuLithgow. Part of "Straw Bale Houses - design and material properties" prepared by Jørgen Munch-Andersen, Birte Møller Andersen and Danish Building and Urban Research. Thermal insulation of earthplastered sb-wall, bale lying flat

Thermal insulation of earthplastered sb-wall, bale on edge
 * In Danish only, direct translation requests to user:DuLithgow. Part of "Straw Bale Houses - design and material properties" prepared by Jørgen Munch-Andersen, Birte Møller Andersen and Danish Building and Urban Research. Thermal insulation of earthplastered sb-wall, bale on edge

Thermal insulation of non plastered straw bale, on edge, flat, two different densities
 * In Danish only, direct translation requests to user:DuLithgow. Part of "Straw Bale Houses - design and material properties" prepared by Jørgen Munch-Andersen, Birte Møller Andersen and Danish Building and Urban Research. Thermal insulation of non plastered straw bale, on edge, flat, two different densities

Thermal insulation of mussell shells, three different densities
 * In Danish only, direct translation requests to user:DuLithgow. Part of "Straw Bale Houses - design and material properties" prepared by Jørgen Munch-Andersen, Birte Møller Andersen and Danish Building and Urban Research. Thermal insulation of mussell shells, three different densities

Fire Safety

 * Summary of New Mexico ASTM E-119 Small Scale Fire Tests On Straw Bale Wall Assemblies
 * This American document is a compilation of information regarding testing done by SHB Agra Engineering and Environmental Services Laboratory in Albuquerque, New Mexico in 1993. Small Scale Fire Tests (PDF 262 KB)

 * Straw Bale Fire Safety
 * The ability of plastered and unplastered straw bale walls to resist fire is presented, based on a number of tests and field reports to date. Field and laboratory experience show plastered bale walls to be highly resistant to fire damage, flame spread and combustion. Bob Theis, 2003. Straw Bale Fire Safety (PDF 100 KB)

 * ASTM E84-98 Surface Burning Characteristics report
 * Report prepared for Katrina Hayes by Omega Point Laboratories in 2000 (USA). Surface Burning Characteristics report (PDF 452 KB)

 * Fire test of clay as a surface cover material
 * In Danish only, direct translation requests to user:DuLithgow. Part of "Straw Bale Houses - design and material properties" prepared by Jørgen Munch-Andersen, Birte Møller Andersen and Danish Building and Urban Research. Fire test of clay as a surface cover material

 * 30min fire test of clay plastered non-loadbearing sb-wall
 * In Danish only, direct translation requests to user:DuLithgow. Part of "Straw Bale Houses - design and material properties" prepared by Jørgen Munch-Andersen, Birte Møller Andersen and Danish Building and Urban Research. 30min fire test of clay plastered non-loadbearing sb-wall

Building Codes

 * City of Cortex Straw Bale Code (Colorado, USA)
 * The City of Cortex ordinance which Dion Hollenbeck scanned and converted to html. City of Cortex Straw Bale Code

 * California Straw Bale Code (USA)
 * This code is from 1995 and has some very general requirements for bearing and non-load bearing constructions, there are also notes on fire safety requirements. California Straw Bale Code (PDF 18 KB)

 * Austin Straw Bale Code (Texas, USA)
 * Austin Straw Bale Code (PDF 18 KB)

 * Boulder Straw Bale Code (Colorado, USA)
 * The purpose of this chapter is to establish minimum prescriptive standards of safety for the construction of structures which use baled straw as a load bearing or non-load bearing material. This code was added to existing legislation in 1981. Boulder Straw Bale Code (PDF 16 KB)

 * Tucson/Pima County SB Code (Arizona, USA)
 * Tucson/Pima County SB Code (PDF 22 KB)

Construction Strength

 * A Pilot Study examining the Strength, Compressibility and Serviceability of Rendered Straw Bale Walls for Two Storey Load Bearing Construction.
 * "A pilot study of a wall constructed from straw bales was carried out. The objective was to examine the suitability of such walls for two-storey residential construction. The emphases were placed on the strength, compressibility and serviceability of the rendered straw bale wall. The full-scale wall was tested to failure in laboratory conditions. The result shows that it is feasible to construct a two-storey wall using such system. The test results were compared with the recommendation provided by some of the codes of practice. It was found that the wall has adequate capacity for a two-storey wall construction. Other issues, such as constructability, detailing, and compressibility were also examined in this paper." Michael Faine and Dr. John Zhang, University of Western Sydney, Australia, 2000 Rendered Straw Bale Walls for Two Storey Load Bearing Construction (PDF 507Kb)

 * Compression load testing straw bale walls
 * Peter Walker, Dept. Architecture & Civil Engineering, University of Bath, England, 2004. Compression load testing straw bale walls (PDF )

 * Settling of non-loadbearing and loadbearing sb-walls after two moisture cycles
 * In Danish only, direct translation requests to user:DuLithgow. Part of "Straw Bale Houses - design and material properties" prepared by Jørgen Munch-Andersen, Birte Møller Andersen and Danish Building and Urban Research. [Settling of non-loadbearing and loadbearing sb-walls after two moisture cycles http://www.by-og-byg.dk/download/pdf/423-8d.pdf]

 * Load-bearing straw bale construction
 * One hundred years of experience with load-bearing plastered straw bale structures, along with a number of laboratory tests worldwide, show these wall systems to be capable of supporting substantial service loads. When properly baled, stacked, and detailed, and plastered both sides with cement, lime, or earthen renders, straw bale walls can support at least residential scale loads, and meet typical building code criteria for strength, serviceability, creep, and durability. Bruce King, USA, 2003. Load-bearing straw bale construction (PDF). This document is made available by the Ecological Building Network, for which they request a donation.

 * Structural Testing of Plasters for Straw Bale Construction
 * Over the past hundred years, plastered straw bale construction has shown itself to be strong and durable in both load-bearing and post-and-beam structures. In load-bearing straw bale systems, the relatively strong, stiff plaster plays a significant role as it works together with the ductile straw bale core to function as a stress skin panel, resisting compressive, in-plane and out-ofplane loading. Kelly Lerner and Kevin Donahue, USA, 2003. Structural Testing of Plasters for Straw Bale Construction. This document is made available by the Ecological Building Network, for which they request a donation.

 * Creep in Bale Walls
 * The tests are aimed at determining the vertical creep or settlement of various bale walls loaded vertically for 12 months. In the base group are two stacks of 6 unplastered rice 3- string bales which are tested with uniform low (100plf) and high (400plf) loads. Dan Smith, USA, 2003. Creep in Bale Walls (PDF). This document is made available by the Ecological Building Network, for which they request a donation.

 * Testing of Straw Bale Walls with out of Plane Loads
 * 3-string rice-straw bales (16” x 24” x 4’-0”) laid flat and stacked to create 2’x4’x8’ straw bale walls plastered with 1” stucco, 2” earth plaster or unplastered were loaded out-of-plane as follows: air-pressure was added to a 4’x8’ plastic waterbed bladder placed in a 2” gap between a 4’x8’ 2x10@16” stud wall with 3/4” plywood both sides. Kevin Donahue, USA, 2003. Testing of Straw Bale Walls with out of Plane Loads. This document is made available by the Ecological Building Network, for which they request a donation.

 * In-Plane Cyclic Tests of Plastered Straw Bale Wall Assemblies
 * The construction and testing of six full-scale plastered straw bale wall assemblies is described in this report. The specimens consisted of three cement stucco skinned walls and three earth plaster skinned walls representing varying levels of reinforcement detailing. All walls were tested in-plane under either cyclic or monotonic lateral loadings. Measured behavior is presented in this report, along with recommendations for future work. Cale Ash, Mark Aschheim and David Mar, USA (date unknown). In-Plane Cyclic Tests of Plastered Straw Bale Wall Assemblies. This document is made available by the Ecological Building Network, for which they request a donation.

 * Design Approach for Load-Bearing Strawbale Walls
 * "In addition to presenting background information about loadbearing strawbale wall systems this paper presents the results of a series of tests conducted to gain more insight into the various parameters needed for the design of strawbale structures. These parameters include: dead load behaviour, bale response to over time, shear between straw and stucco, and axial load capacity of the stucco skin. Based on the test results the paper presents a design example for comparison of test values with design values." Kris J. Dick, M.G. (Ron) Britton. For presentation at the AIC 2002 Meeting CSAE/SCGR Program Saskatoon, Saskatchewan July 14 - 17, 2002. Design Approach for Load-Bearing Strawbale Walls

 * The Effects of Plastered Skin Confinement on the Performance of Straw Bale Wall Systems
 * "This project will continue this investigation and will include the results of compressive tests of confined straw bale specimens. It will also include an evaluation of construction details for confining skins, and how further research can clarify which techniques are most beneficial when building straw bale structures." Adrianne Wheeler, David Riley and Thomas Boothby. Pennsylvania State University Summer Research Opportunities Program 2004 The Effects of Plastered Skin Confinement on the Performance of Straw Bale Wall Systems

Moisture

 * Straw Bale House Moisture Research
 * "Researchers and builders do not know how well straw bale walls deal with moisture. What happens if you build with wet straw? Does it dry out over time? Is straw naturally better able to deal with water than building products such as wood? Will house humidity levels affect straw bale walls—especially during long Canadian winters? Would a vapour barrier help? If rain wets the stucco, does the straw underneath get wet? How do you keep the wall dry by a window when there is no drainage plane behind the stucco to carry the water away?" Canada Mortgage and Housing Corporation. The report is from before 2003 Straw Bale House Moisture Research

 * Pilot Study of Moisture Control in Stuccoed Straw Bale Walls
 * This study was made for the Canada Mortgage and Housing Corporation by Bob Platts of Fibrehouse Limited, USA, 1997. Moisture Control in Stuccoed Straw Bale Walls. Pilot Study of Moisture Control in Stuccoed Straw Bale Walls

 * Monitoring the Hygrothermal Performance of Strawbale Walls
 * "A California winery, interested in quality buildings and sustainable action, commissioned the construction of a large strawbale building to be used as a tasting room, barrel storage room, and tank farm on a site adjoining one of their vineyards. They offered access to this unique building for a comprehensive enclosure wall monitoring program." John Straube and Chris Schumacher, USA, 2003. Monitoring the Hygrothermal Performance of Strawbale Walls (PDF). This document is made available by the Ecological Building Network, for which they request a donation.

 * How Straw Decomposes: Implications for Straw Bale Construction
 * "Straw is a natural fiber that can last many thousands of years under certain conditions. Intact straw has been found in dry Egyptian tombs and buried in layers of frozen glacial ice. However, under typical conditions straw will slowly degrade as do all natural fiber materials like wood, paper, cotton fabric, etc." Matthew D. Summers, Sherry L. Blunk and Bryan M. Jenkins, USA, 2003. How Straw Decomposes (PDF). This document is made available by the Ecological Building Network, for which they request a donation.

 * Moisture properties of straw and plaster/straw assemblies
 * "This report is a draft summary of the results of the moisture property testing of a range of plaster types that might be installed over strawbale walls. It reviews the literature for previous data, describes the test protocols, and summarizes the results." John Straube, USA (date unknown). Moisture properties of straw and plaster/straw assemblies. This document is made available by the Ecological Building Network, for which they request a donation.

 * Water vapour transmission properties of clay plaster with various surface treatments / additives
 * In Danish only, direct translation requests to user:DuLithgow. Part of "Straw Bale Houses - design and material properties" prepared by Jørgen Munch-Andersen, Birte Møller Andersen and Danish Building and Urban Research. [Water vapour transmission properties of clay plaster with various surface treatments / additives http://www.by-og-byg.dk/download/pdf/423-8a.pdf]

Water vapour transmission properties of straw
 * In Danish only, direct translation requests to user:DuLithgow. Part of "Straw Bale Houses - design and material properties" prepared by Jørgen Munch-Andersen, Birte Møller Andersen and Danish Building and Urban Research. [Water vapour transmission properties of straw http://www.by-og-byg.dk/download/pdf/423-8b.pdf]

Moisture accumulation of sb-walls plastered with clay plaster on the inside (warm side) and clay plaster or lime plaster on the outside (cold side)
 * In Danish only, direct translation requests to user:DuLithgow. Part of "Straw Bale Houses - design and material properties" prepared by Jørgen Munch-Andersen, Birte Møller Andersen and Danish Building and Urban Research. [moisture accumulation of sb-walls plastered with clay plaster on the inside (warm side) and clay plaster or lime plaster on the outside (cold side) http://www.by-og-byg.dk/download/pdf/423-8c.pdf]

 * Humidity in straw bale walls and its effect on the decomposition of straw
 * Jakub Wihan explores the physics of moisture in walls in relation to the degradation of straw. He considers practical experience through case studies of straw bale houses and compares simple design calculations with computer simulation. The conclusions are compared to knowledge from 27 cases by professional straw bale builders to give guidelines for future work. Humidity in straw bale walls and its effect on the decomposition of straw

Studies in other languages
French

 * Utilisation de la Paille en Parois de Maisons Individuelles a Ossature Bois
 * "Le programme de recherche comporte le suivi technique de la construction, l'expérimentation du comportement thermique des logements et de l'humidité au sein des parois, ainsi que la détermination en laboratoire des caractéristiques des matériaux et la validation technique de ces procédés constructifs." Alain Grelat, 2004

Utilisation de la Paille en Parois de Maisons Individuelles a Ossature Bois (PDF 824Kb)

Danish

 * Halmhuse - Udformning og materialeegenskaber
 * "Laster, Længderetning, Tværretning, Halmhuse og dagslys, Varmeakkumulering, Fugtakkumulering, Lufttæthed og dampspærre, Forebyggelse af svampeangreb, Tage, Varmeisolering, Brand, Tagdækning, Skivevirkning, Terrændæk, Vinduer, Fundamenter, Ydervægge, Fugt, Trækonstruktion, Rundtømmerløsning, Skjult konstruktion, Rammekonstruktion,     Muslingeskaller, Varmeisolering for halmvægge." Jørgen Munch-Andersen og Birte Møller Andersen, 2004

Halmhuse - Udformning og materialeegenskaber (PDF 3.0MB)

German

 * Mikrobielle Empfindlichkeit von Bau-Strohballen
 * "Im Zuge des zunehmenden Umweltbewußtseins der Bevölkerung hat sich auch ein umweltbewußtes Wohnen verbreitet. Viele legen mehr Wert auf ein gesundes Raumklima da sie begreifen, dass sie einen Großteil ihres Leben in ihren Wohnungen zubringen. Zudem hat es in der letzten Zeit eine Reihe von Umweltskandalen gegeben die zu einem Umdenken geführt haben. Die Folge war eine Hinwendung zu Bauprodukten die sowohl gesundheits- als auch umweltschonend sind. Diese Entwicklung wurde und wird auch von der Bundesregierung gefördert (Gütesiegel Natureplus). Zur diesen Produkten gehören vor allem auch Dämmstoffe aus nachwachsenden Rohstoffen. In diesem Bereich wurde in den letzten 10 Jahren viel Forschungsarbeit geleistet u diese Materialien konkurrenzfähig gegenüber konventionellen Dämmstoffen zu machen." Hansjörg Wieland, 2004

Mikrobielle Empfindlichkeit von Bau-Strohballen (PDF 408KB)


text:
Straw Bale Construction/Resources/Worldwide Contacts

Worldwide organisations and contacts
If you have a contact to add please click edit and use this template:
 * New Contact
 * Contact: FirstName LastName, Organisation, Address. Telephone: +1 23 3456789. Email: some@somewhere.org Website: http://somewhere.org

The Americas

 * California
 * Contact: California Straw Building Association, The Tides Center, P.O. Box 1293, Angels Camp, CA 95222-1293. USA. Telephone: +1 209 7857077. Website: http://www.strawbuilding.org/

 * Contact: The Last Straw blog, Email: admin@buildearth.org Website: http://tls.buildearth.org

 * Contact: Buildearth.org, Email: admin@buildearth.org Website: http://www.buildearth.org

 * Colorado
 * Contact: The Last Straw Journal, PO Box 22706 Lincoln Nebraska 68542-2706 USA. USA. Telephone: +1 402 4835135. Email: thelaststraw@thelaststraw.org Website: http://www.the.thelaststraw.org

 * Contact: Colorado strawbale association, 2010 Hermosa Dr. Boulder, Colorado 80304. Telephone: +1 303 4446027 Email: costrawbale@yahoo.com Website: http://www.coloradostrawbale.org

 * Nebraska
 * Contact: Straw Bale Association of Nebraska and the MidAmerica Straw Bale Association. Email: jc10508@navix.net Website: http://www.strawhomes.com/sban

 * Ontario
 * Contact: Ontario Straw Bale Building Coalition, Hank and Anita Carr, 2025 Ventnor Road, RR3, Spencerville ON, K0E 1X0, Canada. Website: http://www.strawbalebuilding.ca/ Telephone: +1-87-STRAWBALE Email: info@strawbalebuilding.ca Email discussion list: http://groups.yahoo.com/group/practical-sbc/

 * Texas
 * Contact: Straw Bale Association of Texas, P.O. Box 4211 Austin, TX 78763-4211. USA. Telephone: +1 512-3026766 Website: http://www.greenbuilder.com/sbat/

Europe
(Listed alphabetically under their English spelling)
 * European Strawbale Network (Europäisches Strohballen-Netzwerk)
 * Website: http://www.baubiologie.at/europe/

 * Austria (Republik Österreich)
 * Contact: Herbert Gruber, A-3720 Baierdorf 6. Österreichisches Strohballen-Netzwerk (Austrian Straw Bale Network). Website: http://www.baubiologie.at/asbn/

 * Belgium (Koninkrijk België)
 * Contact: Geert Goffin (Gigi), Casa Calida, Grootmeers 14, 3700 Tongeren, email: info [at] casacalida [dot] be Website: www.casacalida.be
 * Contact: Herwig van Soom, Kouterstraat 7, B-3052 Blanden. Email: orcaherwig [at] skynet [dot] be
 * Czech Republic (Česká republika)
 * Contact: Jan (Jenik) Hollan. Email: jhollan [at] amper [dot] ped [dot] muni [dot] cz

 * Denmark (Danmark)
 * Contact: Lars Keller, Friland 12 B, 8410 Roende. Email: larskeller [at] livinghouses [dot] net

 * Estonia
 * Contact: Kermo Jürmann, Tallinn. Email: kermo [at] ehituslahendused dot] ee Website:http://www.ehituslahendused.ee/strawbalebuilding, http://www.ehituslahendused.ee/strawbalebuilding/estonia.htm

 * France
 * Contact: Coralie & André de Bouter, La Maison en Paille, Le Trezidoux, 16290 Champmillon. Telephone: +33 545 662768. Email: accueil [at] lamaisonenpaille [dot] com Website: http://www.lamaisonenpaille.com/ and Contact: Philippe Liboureau, "Les Compaillons". Website:   http://compaillons.fr Webforum: http://compaillons.naturalforum.net

 * Germany (Bundesrepublik Deutschland)
 * Contact: Dirk Scharmer, Fachverband Strohballenbau Deutschland, Sieben Linden 1, D-38486 Bandau. Email: info [at] fasba [dot] de Website: http://www.fasba.de/

 * Germany
 * Contact: Sven Eweleit, anderssehn, Seiler Str.16, 30171 Hannover. Telephone: +49 511 33644780. Email: info [at] anderssehn [dot] de Website: http://anderssehn.de

 * Holland (Netherland)
 * Strobouwacademie, contact via website: http://www.strobouwacademie.nl +31-(0)35-5238900
 * Contact: Michel Post, VIBA werkgroep strobouw. Email: info [at] purplex [dot] nl Website: http://www.strobouw.nl

 * Hungary (Magyar Köztársaság)
 * Contact: Attila Meszaros. Email: tilla [dot] szalmahaz [dot] hu Website: http://www.szalmahaz.hu Phone: +36 20 9772258

 * Italy
 * Contact: EDILPAGLIA - Italian Association Straw Bale Building, via delle Vigne 12, 51016 Montecatini Terme (pt) Website: http://www.edilpaglia.it
 * Contact: Centro di Permacultura LA BOA - Stefano Soldati, via Boa, 29 30020 Pramaggiore (VE) Website: http://www.laboa.org

 * Italy/ Southern Tyrol
 * Contact: Margareth Schwarz, via d.corse 6, o-Rennweg, I-39012 Meran. Telephone: +39 473 230023 or +39 348 3634054. Faximilie: +39 473 230035. Email: arch.schwarz [at] rolmail [dot] net

 * Norway (Norge)
 * Contact: Piet Jensen, Norsk jord- og halmbyggeforening, Værnhus, 1540 Vestby. Telephone: +47 64 952246 Email: njh [at] halmhus [dot] no Website: http://halmhus.virkelighet.net/

 * Romania (România)
 * Contact: Catalina Grigore, Ritmului 16, Bucuresti. Email: catalina [at] eco-habitat [dot] ro Website: http://www.eco-habitat.ro/

 * Slovenia (Republika Slovenija)
 * Contact: Habjanic Stojan, Slowenien, Biogradnja s.p.., Brezovci 72/a, Sl-9201, Puconci. Email: stojan.oikia[at] siol [dot] net

 * Spain (Espana)
 * Contact: Rikki Nitzkin-Lleida, Spanish Strawbale Network. Email: rikkinitzkin [at] earthlink [dot] net Website: http://www.casasdepaja.org Discussion email lists: casasdepaja [at] yahoo [dot] es paja [at] amper [dot] ped [dot] muni [dot] cz

 * Sweden (Sverige)
 * Contact: Ulf Henningsson, Rosenvingegatan 1, 431 63 MÖLNDAL. Telephone: +46 31 27 60 70. Email: ulf-lennart [at] rocketmail [dot] com Website: http://www.naturligt-byggeri.org/

 * Switzerland
 * Werner Schmidt, Fabrikareal Nr 119, 7180 Trun. Email: atelier_schmidt [at] bluewin [dot] ch

 * Turkey (Türkiye Cumhuriyeti)
 * Contact: Demet Irkli Eryldiz. Email: irkli [at] mmf [dot] gazi [dot] edu [dot] tr [This email is not active and requires updating]

 * United Kingdom (Wales, Ireland, Scotland and England)
 * Contact: Straw Bale Building Association (WISE), Hollinroyd Farm, Butts Lane, Todmorden, OL14 8RJ. Telephone: +44 1442 825421 or +44 1706 814696. Email: info@strawbalebuildingassociation.org.uk Website: http://www.strawbalebuildingassociation.org.uk/

South Pacific

 * Australia & New Zealand
 * Contact: Andrew Webb, Australasian Straw Bale Building Association. Website: http://www.ausbale.org/. Telephone: +61 7 54852720. Email: admin@ausbale.org

 * New Zealand
 * Contact: Ian Redfern. Email: ian@adobesouth.co.nz

 * Contact: Graeme North. Email: ecodesign@xtra.co.nz

Email Lists

 * Strawbale Construction Discussion List
 * This discussion email list is hosted by the US based Renewable Energy Policy Project (REPP). list webpage list archive pre 2003 archive

 * Straw Bale Social Club
 * When the CREST hosted list disappeared (it is now hosted by REPP) this list was set up to fill the gap. Their welcome message describes it as "a discussion forum ostensibly created to share experiences and thoughts about building with straw and earth, but it's really just a place where the strawbale community can talk about common interests, often not having to do with building at all." Mailing list website and archive

 * Practical Straw Bale Construction
 * Focused on the how-to of straw bale construction and associated systems and technologies in Ontario, Canada and around the world. Mailing list website and archive

 * European strawbale building discussions
 * "Discussions, announcements, enquiries, etc., about building with strawbales in Europe. Straw is generally a waste product, therefore building with strawbales has very low environmental impact, uses locally available materials, is cheap, and is a very fun sociable way to build!" list website list archive

 * The Global Straw Building Network
 * "A private forum restricted to organizations involved in the promotion of straw as a building material. (If you are a member of such a group which is not yet represented in GSBN, email GSBN@lists.greenbuilder.com with SUBSCRIBE in the SUBJECT line. Your request will be forwarded to a moderator for consideration.)" public list archive


text:
Straw Bale Construction/Resources/Registries

Straw Bale Building Registries
International Straw Bale Building Registry Greenbuilder.com, The Last Straw Journal, The Straw Bale Association of Texas, and the Development Center for Appropriate Technology, along with a number of regional strawbale organizations, are working together to build a database of buildings constructed using straw bale. [Visit the registry]

United Kingdom Database of Strawbale Buildings in the U.K. Maintained by Chug, email: chug@strawbale-building.co.uk

International Registry using Google Maps Contributions from self-builders, architects and organisations around the world with clickable icons linking to the owner's websites [Visit the registry]


text:
User:Connection

Visit me at w:User:Connection.

title: User:Connection


text:
SanDisk Sansa MP3 Players

Table of Contents

 * m200 series
 * e200 series
 * e200r series
 * c100 series
 * e100 series
 * Connect
 * Express series
 * View series
 * Clip series
 * Shaker series

About
Currently, the m200 series has a pretty good manual on here. If you've got a player from one of the other series, check the m200 series for tips that might work for your player as well. Then come back and write a version of that trick customized for your player!

The SanDisk Sansa m200 series is a series of flash based MP3 players, including one with 4GB capacity. It's currently the only MP3 player besides the IPod nano to have 4GB flash capacity. The Sansa e200 series is the first MP3 player line to have a model with 8GB flash drive, and is a real iPod killer (video capacity, nice design).

For more info about the SanDisk Sansa series, refer to the SanDisk Sansa page.

Alternatives to the Sansa players
Flash based players with 2 gigabytes or more:
 * Iriver Clix
 * Samsung YEPP YP-D1
 * Samsung YP-Z5A
 * Samsung F2
 * Samsung U2
 * Apple Ipod Nano
 * iAUDIO i5
 * Jens of Sweden MP-500

Other sort of relevant Wikibooks

 * Linux Guide/Audacity to MP3
 * ITunes

title: SanDisk Sansa MP3 Players