text:
Louis de Broglie

Louis Victor Pierre Raymond, 7th Duc de Broglie (, also,   or ; 15 August 1892 – 19 March 1987) was a French aristocrat and physicist who made groundbreaking contributions to quantum theory. In his 1924 PhD thesis, he postulated the wave nature of electrons and suggested that all matter has wave properties. This concept is known as the de Broglie hypothesis, an example of wave–particle duality, and forms a central part of the theory of quantum mechanics.

De Broglie won the Nobel Prize for Physics in 1929, after the wave-like behaviour of matter was first experimentally demonstrated in 1927.

The 1925 pilot-wave model, and the wave-like behaviour of particles discovered by de Broglie was used by Erwin Schrödinger in his formulation of wave mechanics. The pilot-wave model and interpretation was then abandoned, in favor of the quantum formalism, until 1952 when it was rediscovered and enhanced by David Bohm.

Louis de Broglie was the sixteenth member elected to occupy seat 1 of the Académie française in 1944, and served as Perpetual Secretary of the French Academy of Sciences. De Broglie became the first high-level scientist to call for establishment of a multi-national laboratory, a proposal that led to the establishment of the European Organization for Nuclear Research (CERN).

Origin and education

Louis de Broglie belonged to the famous aristocratic family of Broglie, whose representatives for several centuries occupied important military and political posts in France. The father of the future physicist, Louis-Alphonse-Victor, 5th duc de Broglie, was married to Pauline d’Armaille, the granddaughter of the Napoleonic General Philippe Paul, comte de Ségur and his wife, the biographer, Marie Célestine Amélie d'Armaillé. They had five children; in addition to Louis, these were: Albertina (1872–1946), subsequently the Marquise de Luppé; Maurice (1875–1960), subsequently a famous experimental physicist; Philip (1881–1890), who died two years before the birth of Louis, and Pauline, Comtesse de Pange (1888–1972), subsequently a famous writer. Louis was born in Dieppe, Seine-Maritime. As the youngest child in the family, Louis grew up in relative loneliness, read a lot, and was fond of history, especially political. From early childhood, he had a good memory and could accurately read an excerpt from a theatrical production or give a complete list of ministers of the Third Republic of France. For this, he was predicted to become a great statesman in the future.

De Broglie had intended a career in humanities, and received his first degree (licence ès lettres) in history. Afterwards he turned his attention toward mathematics and physics and received a degree (licence ès sciences) in physics. With the outbreak of the First World War in 1914, he offered his services to the army in the development of radio communications.

Military service
After graduation, Louis de Broglie joined the engineering forces to undergo compulsory service. It began at Fort Mont Valérien, but soon, on the initiative of his brother, he was seconded to the Wireless Communications Service and worked on the Eiffel Tower, where the radio transmitter was located. Louis de Broglie remained in military service throughout the First World War, dealing with purely technical issues. In particular, together with Léon Brillouin and brother Maurice, he participated in establishing wireless communications with submarines. Louis de Broglie was demobilized in August 1919 with the rank of adjudant. Later, the scientist regretted that he had to spend about six years away from the fundamental problems of science that interested him.

Scientific and pedagogical career
His 1924 thesis Recherches sur la théorie des quanta (Research on the Theory of the Quanta) introduced his theory of electron waves. This included the wave–particle duality theory of matter, based on the work of Max Planck and Albert Einstein on light. This research culminated in the de Broglie hypothesis stating that any moving particle or object had an associated wave. De Broglie thus created a new field in physics, the mécanique ondulatoire, or wave mechanics, uniting the physics of energy (wave) and matter (particle). He won the Nobel Prize in Physics in 1929 "for his discovery of the wave nature of electrons".

In his later career, de Broglie worked to develop a causal explanation of wave mechanics, in opposition to the wholly probabilistic models which dominate quantum mechanical theory; it was refined by David Bohm in the 1950s. The theory has since been known as the De Broglie–Bohm theory.

In addition to strictly scientific work, de Broglie thought and wrote about the philosophy of science, including the value of modern scientific discoveries. In 1930 he founded the book series Actualités scientifiques et industrielles published by Éditions Hermann.

De Broglie became a member of the Académie des sciences in 1933, and was the academy's perpetual secretary from 1942. He was asked to join Le Conseil de l'Union Catholique des Scientifiques Francais, but declined because he was non-religious. In 1941, he was made a member of the National Council of Vichy France. On 12 October 1944, he was elected to the Académie Française, replacing mathematician Émile Picard. Because of the deaths and imprisonments of Académie members during the occupation and other effects of the war, the Académie was unable to meet the quorum of twenty members for his election; due to the exceptional circumstances, however, his unanimous election by the seventeen members present was accepted. In an event unique in the history of the Académie, he was received as a member by his own brother Maurice, who had been elected in 1934. UNESCO awarded him the first Kalinga Prize in 1952 for his work in popularizing scientific knowledge, and he was elected a Foreign Member of the Royal Society on 23 April 1953.

Louis became the 7th duc de Broglie in 1960 upon the death without heir of his elder brother, Maurice, 6th duc de Broglie, also a physicist.

In 1961, he received the title of Knight of the Grand Cross in the Légion d'honneur. De Broglie was awarded a post as counselor to the French High Commission of Atomic Energy in 1945 for his efforts to bring industry and science closer together. He established a center for applied mechanics at the Henri Poincaré Institute, where research into optics, cybernetics, and atomic energy were carried out. He inspired the formation of the International Academy of Quantum Molecular Science and was an early member.

Louis never married. When he died on 19 March 1987 in Louveciennes at the age of 94, he was succeeded as duke by a distant cousin, Victor-François, 8th duc de Broglie. His funeral was held 23 March 1987 at the Church of Saint-Pierre-de-Neuilly.

Physics of X-ray and photoelectric effect
The first works of Louis de Broglie (early 1920s) were performed in the laboratory of his older brother Maurice and dealt with the features of the photoelectric effect and the properties of x-rays. These publications examined the absorption of X-rays and described this phenomenon using the Bohr theory, applied quantum principles to the interpretation of photoelectron spectra, and gave a systematic classification of X-ray spectra. The studies of X-ray spectra were important for elucidating the structure of the internal electron shells of atoms (optical spectra are determined by the outer shells). Thus, the results of experiments conducted together with Alexandre Dauvillier, revealed the shortcomings of the existing schemes for the distribution of electrons in atoms; these difficulties were eliminated by Edmund Stoner. Another result was the elucidation of the insufficiency of the Sommerfeld formula for determining the position of lines in X-ray spectra; this discrepancy was eliminated after the discovery of the electron spin. In 1925 and 1926, Leningrad physicist Orest Khvolson nominated the de Broglie brothers for the Nobel Prize for their work in the field of X-rays.

Matter and wave–particle duality
Studying the nature of X-ray radiation and discussing its properties with his brother Maurice, who considered these rays to be some kind of combination of waves and particles, contributed to Louis de Broglie's awareness of the need to build a theory linking particle and wave representations. In addition, he was familiar with the works (1919–1922) of Marcel Brillouin, which proposed a hydrodynamic model of an atom and attempted to relate it to the results of Bohr's theory. The starting point in the work of Louis de Broglie was the idea of Einstein about the quanta of light. In his first article on this subject, published in 1922, the French scientist considered blackbody radiation as a gas of light quanta and, using classical statistical mechanics, derived the Wien radiation law in the framework of such a representation. In his next publication, he tried to reconcile the concept of light quanta with the phenomena of interference and diffraction and came to the conclusion that it was necessary to associate a certain periodicity with quanta. In this case, light quanta were interpreted by him as relativistic particles of very small mass.

It remained to extend the wave considerations to any massive particles, and in the summer of 1923 a decisive breakthrough occurred. De Broglie outlined his ideas in a short note "Waves and quanta" (Ondes et quanta, presented at a meeting of the Paris Academy of Sciences on September 10, 1923), which marked the beginning of the creation of wave mechanics. In this paper and his subsequent PhD thesis, the scientist suggested that a moving particle with energy E and velocity v is characterized by some internal periodic process with a frequency $$E/h$$ (later known as Compton frequency), where $$h$$ is Planck's constant. To reconcile these considerations, based on the quantum principle, with the ideas of special relativity, de Broglie associated wave he called a "phase wave" with a moving body, which propagates with the phase velocity $$c^2/v$$. Such a wave, which later received the name matter wave, or de Broglie wave, in the process of body movement remains in phase with the internal periodic process. Having then examined the motion of an electron in a closed orbit, the scientist showed that the requirement for phase matching directly leads to the quantum Bohr-Sommerfeld condition, that is, to quantize the angular momentum. In the next two notes (reported at the meetings on September 24 and October 8, respectively), de Broglie came to the conclusion that the particle velocity is equal to the group velocity of phase waves, and the particle moves along the normal to surfaces of equal phase. In the general case, the trajectory of a particle can be determined using Fermat's principle (for waves) or the principle of least action (for particles), which indicates a connection between geometric optics and classical mechanics.

This theory set the basis of wave mechanics. It was supported by Einstein, confirmed by the electron diffraction experiments of G P Thomson and Davisson and Germer, and generalized by the work of Erwin Schrödinger.

From a philosophical viewpoint, this theory of matter-waves has contributed greatly to the ruin of the atomism of the past. Originally, de Broglie thought that real wave (i.e., having a direct physical interpretation) was associated with particles. In fact, the wave aspect of matter was formalized by a wavefunction defined by the Schrödinger equation, which is a pure mathematical entity having a probabilistic interpretation, without the support of real physical elements. This wavefunction gives an appearance of wave behavior to matter, without making real physical waves appear. However, until the end of his life de Broglie returned to a direct and real physical interpretation of matter-waves, following the work of David Bohm.

Conjecture of an internal clock of the electron
In his 1924 thesis, de Broglie conjectured that the electron has an internal clock that constitutes part of the mechanism by which a pilot wave guides a particle. Subsequently, David Hestenes has proposed a link to the zitterbewegung that was suggested by Schrödinger.

While attempts at verifying the internal clock hypothesis and measuring clock frequency are so far not conclusive, recent experimental data is at least compatible with de Broglie's conjecture.

Non-nullity and variability of mass
According to de Broglie, the neutrino and the photon have rest masses that are non-zero, though very low. That a photon is not quite massless is imposed by the coherence of his theory. Incidentally, this rejection of the hypothesis of a massless photon enabled him to doubt the hypothesis of the expansion of the universe.

In addition, he believed that the true mass of particles is not constant, but variable, and that each particle can be represented as a thermodynamic machine equivalent to a cyclic integral of action.

Generalization of the principle of least action
In the second part of his 1924 thesis, de Broglie used the equivalence of the mechanical principle of least action with Fermat's optical principle: "Fermat's principle applied to phase waves is identical to Maupertuis' principle applied to the moving body; the possible dynamic trajectories of the moving body are identical to the possible rays of the wave." This latter equivalence had been pointed out by William Rowan Hamilton a century earlier, and published by him around 1830, for the case of light.

Duality of the laws of nature
Far from claiming to make "the contradiction disappear" which Max Born thought could be achieved with a statistical approach, de Broglie extended wave–particle duality to all particles (and to crystals which revealed the effects of diffraction) and extended the principle of duality to the laws of nature.

His last work made a single system of laws from the two large systems of thermodynamics and of mechanics: "When Boltzmann and his continuators developed their statistical interpretation of Thermodynamics, one could have considered Thermodynamics to be a complicated branch of Dynamics. But, with my actual ideas, it's Dynamics that appear to be a simplified branch of Thermodynamics. I think that, of all the ideas that I've introduced in quantum theory in these past years, it's that idea that is, by far, the most important and the most profound." That idea seems to match the continuous–discontinuous duality, since its dynamics could be the limit of its thermodynamics when transitions to continuous limits are postulated. It is also close to that of Gottfried Wilhelm Leibniz, who posited the necessity of "architectonic principles" to complete the system of mechanical laws.

However, according to him, there is less duality, in the sense of opposition, than synthesis (one is the limit of the other) and the effort of synthesis is constant according to him, like in his first formula, in which the first member pertains to mechanics and the second to optics:
 * $$ m c^2 = h \nu $$

Neutrino theory of light
This theory, which dates from 1934, introduces the idea that the photon is equivalent to the fusion of two Dirac neutrinos. It is not currently accepted by the majority of physicists.

Hidden thermodynamics
De Broglie's final idea was the hidden thermodynamics of isolated particles. It is an attempt to bring together the three furthest principles of physics: the principles of Fermat, Maupertuis, and Carnot.

In this work, action becomes a sort of opposite to entropy, through an equation that relates the only two universal dimensions of the form:
 * $${\text{action}\over h} = -{\text{entropy}\over k}$$

As a consequence of its great impact, this theory brings back the uncertainty principle to distances around extrema of action, distances corresponding to reductions in entropy.

Honors and awards

 * 1929 Nobel Prize in Physics
 * 1929 Henri Poincaré Medal
 * 1932 Albert I of Monaco Prize
 * 1938 Max Planck Medal
 * 1938 Fellow, Royal Swedish Academy of Sciences
 * 1939 International Member, American Philosophical Society
 * 1944 Fellow, Académie française
 * 1948 International Member, United States National Academy of Sciences
 * 1952 Kalinga Prize
 * 1953 Fellow, Royal Society
 * 1958 International Honorary Member of the American Academy of Arts and Sciences

Publications

 * Recherches sur la théorie des quanta (Researches on the quantum theory), Thesis, Paris, 1924, Ann. de Physique (10) 3, 22 (1925).
 * Introduction à la physique des rayons X et gamma (Introduction to physics of X-rays and Gamma-rays), with Maurice de Broglie, Gauthier-Villars, 1928.
 * Rapport au 5ème Conseil de Physique Solvay (Report for the 5th Solvay Physics Congress), Brussels, 1927.
 * Matière et lumière (Matter and Light), Paris: Albin Michel, 1937.
 * La Physique nouvelle et les quanta (New Physics and Quanta), Flammarion, 1937.
 * Continu et discontinu en physique moderne (Continuous and discontinuous in Modern Physics), Paris: Albin Michel, 1941.
 * Ondes, corpuscules, mécanique ondulatoire (Waves, Corpuscles, Wave Mechanics), Paris: Albin Michel, 1945.
 * Physique et microphysique (Physics and Microphysics), Albin Michel, 1947.
 * Vie et œuvre de Paul Langevin (The life and works of Paul Langevin), French Academy of Sciences, 1947.
 * Optique électronique et corpusculaire (Electronic and Corpuscular Optics), Herman, 1950.
 * Savants et découvertes (Scientists and discoveries), Paris, Albin Michel, 1951.
 * Une tentative d'interprétation causale et non linéaire de la mécanique ondulatoire: la théorie de la double solution. Paris: Gauthier-Villars, 1956.
 * English translation: Non-linear Wave Mechanics: A Causal Interpretation. Amsterdam: Elsevier, 1960.
 * Nouvelles perspectives en microphysique (New prospects in Microphysics), Albin Michel, 1956.
 * Sur les sentiers de la science (On the Paths of Science), Paris: Albin Michel, 1960.
 * Introduction à la nouvelle théorie des particules de M. Jean-Pierre Vigier et de ses collaborateurs, Paris: Gauthier-Villars, 1961. Paris: Albin Michel, 1960.
 * English translation: Introduction to the Vigier Theory of elementary particles, Amsterdam: Elsevier, 1963.
 * Étude critique des bases de l'interprétation actuelle de la mécanique ondulatoire, Paris: Gauthier-Villars, 1963.
 * English translation: The Current Interpretation of Wave Mechanics: A Critical Study, Amsterdam, Elsevier, 1964.
 * Certitudes et incertitudes de la science (Certitudes and Incertitudes of Science). Paris: Albin Michel, 1966.
 * with Louis Armand, Pierre Henri Simon and others. Albert Einstein. Paris: Hachette, 1966.
 * English translation: Einstein. Peebles Press, 1979.
 * Recherches d'un demi-siècle (Research of a half-century), Albin Michel, 1976.
 * Les incertitudes d'Heisenberg et l'interprétation probabiliste de la mécanique ondulatoire (Heisenberg uncertainty and wave mechanics probabilistic interpretation), Gauthier-Villars, 1982.
 * English translation: Einstein. Peebles Press, 1979.
 * Recherches d'un demi-siècle (Research of a half-century), Albin Michel, 1976.
 * Les incertitudes d'Heisenberg et l'interprétation probabiliste de la mécanique ondulatoire (Heisenberg uncertainty and wave mechanics probabilistic interpretation), Gauthier-Villars, 1982.

title: Louis de Broglie


text:
Wikipedia talk:Check your facts

Supporters of this rule include: Larry Sanger, Damian Yerrick, tbc, Taw, LDC, webkid (Generally speaking, checking in books is better than cheking in Internet), and Hyacinth

Opponents include: Satan, The Cunctator, and 24 (only check what you yourself doubt--not what you don't. If you don't doubt it, you won't remember to check it in the first place ;-0)

Proposal to consolidate advice on writing better articles
At present there are many articles in the Wikipedia namespace that seek to give guidance on how to write better articles. I propose consolidating these into a much smaller number. On User:Jongarrettuk/Better writing guide I propose how these could be consolidated. The proposal is not to change advice, just to consolidate it. If I have inadvertently moved what you consider to be good advice that is currently in the Wikipedia namespace, please re-add it. I'm hope that the proposal to merge all these articles, in principle, will be welcomed. Of course, it may be preferred to have 2, 3 or 4 inter-connected articles than just one and would welcome advice on how this could be done. (In particular, perhaps all the guidance on layout should be spun off into one consolidated article on layout.) I'm also aware that putting lots of different bits of advice together may throw up anomalies or bits that people now disagree with (including bits that I myself disagree with:) ). I ask for support for the consolidation. Once the consolidation has happened, the advice can be changed in the normal way. Please feel free to improve on the current draft consolidation, but don't remove or add advice that is not currently on the Wikipedia namespace. If all goes well, I'll add a new Guide to writing better articles page on the 19th, though maybe some bits of the new article will need to be phased in over a longer period. I'll also take care to preserve all the archived discussion in one place. jguk 20:01, 11 Nov 2004 (UTC)

Huh?
What the *hell* does this mean?

"You should write that P only if it is true that P; contraposing, if it is not true that P, you should not write that P."

 * I concur. Someone that doesn't know to check their facts isn't going to be enlightened by this "logic".  Protect our newbies from this.  Consolidate!  -- A D Monroe III 22:36, 23 Feb 2005 (UTC)

Requests for arbitration/RFC
An important policy discussion has started concerning ways in which our content-related polices, such as NPOV, No original research and Verifiability could be better enforced. I've made a proposal to give the Arbitration Committee the ability to consult Wikipedia users who are knowledgeable in  subject-areas that apply to cases before them. Such consultation is needed due to the fact that the ArbCom does not by itself have the requisite knowledge to easily tell what is NPOV, original research, or a fringe idea in every field. Please read my proposal at Requests for arbitration/RFC and comment. Thank you! --mav 02:48, 7 Jun 2005 (UTC)

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

title: Wikipedia talk:Check your facts


text:
Wikipedia:Line breaks usage

If you add two line breaks (by pressing return twice) to the source text, Wikipedia will create a new paragraph. It is uncontroversial that paragraphs should be used to make articles easy to read. This page, however, refers to single line breaks within article source texts.

Single line breaks in the source text are not translated to single line breaks in the output (if you want a single line break to appear in the rendered article, use a  tag or  template). However, single line breaks in the source do have certain effects: Within a list, a single line break starts either the next item or a new paragraph; within an indentation (which, if marked up with leading colons, is really the definition part of a definition list), a single line break aborts the indentation and starts a new paragraph. Links do not span line breaks (this is intentional, so that authors do not accidentally turn an entire paragraph into a link etc.).

Regardless, some Wikipedians insert single line breaks into the source text of articles for various reasons; others oppose this practice. Readers do not need to care about this controversy since it does not affect the appearance of articles. The two positions are presented below. See the discussion page for the current head count for each position.

Do not use single line breaks
Do not use manually entered hard line breaks within paragraphs when editing articles. Reasons for this include:

of church and state; civil rights issues; pornography and obscenity; political speech and organizations; journalism and its restrictions; involuntary commitment laws; and many more.
 * If you want to indent a paragraph that includes single line breaks, you first have to remove them.
 * If you want to make a list item out of a paragraph that includes single line breaks, you first have to remove them.
 * If you want to turn a phrase that contains a line break into a link, or format it in bold or italics, you have to remove the line break first.
 * Many readers expect line breaks only where there is a logical, semantic break. Line breaks in source text will make them pause and search for such a break, and be frustrated when there is none. Consider this example:
 * The consequences of this Amendment to American society have been profound. First Amendment questions have been raised with regard to the separation
 * The appearance of the article source text becomes different from the appearance of the rendered output; it therefore becomes harder to find a sentence of the rendered output in the source text. Since writers often think in terms of paragraphs, it makes sense to organize the text that way.
 * Single line breaks in source texts may confuse new editors, who may think they are there for a special reason, and avoid editing these paragraphs because they fear they will break something.
 * Single line breaks in source texts may confuse new editors, who may think they are there for a special reason, and avoid editing these paragraphs because they fear they will break something.

Proponents of line breaks within paragraphs claim that they make diffs (the reports showing the differences between two revisions of an article) easier to read. The diff feature highlights the changes within each line break delimited block of text and provides unchanged text for additional context up to the third line break below and above that text. This usually means that it highlights the entire paragraph, and shows one paragraph above and below it for context. The changed characters are separately highlighted from the changed blocks in a different color.

It is hard to see how individual line breaks help in any way in that comparison, since their only effect will be to reduce the amount of context provided when a line is changed. In fact, arbitrarily entered line breaks prevent the software from working correctly: instead of providing the context of a full paragraph, it only shows changes in individual lines of text, respecting not even sentence boundaries.

One undeniable advantage of line breaks within paragraphs is that many Unix editors do not handle long lines well – they can either wrap characters at the screen boundary, wrap words at a fixed length, or not wrap at all. However, by this logic, line breaks would have to be entered at a fixed width, such as 80 characters, something which most proponents of the "use single line breaks" rule do not want and which, as seen above, completely breaks the diff context feature. Just inserting line breaks into some paragraphs will not make them easier to edit with these tools. Arguably, those who use editors which cannot handle long lines properly should just get better ones. Microsoft Notepad has had this functionality since its very first version, Gedit has it, vi supports it with the "set lbr" option, and every major graphical web browser has proper word wrapping even on Unix platforms.

Use single line breaks
Use frequent manually entered hard line breaks within paragraphs when editing the source code of articles, at least at the end of every sentence, but also in other places as needed. Manually entered hard line breaks arguably make the article much easier to edit when the lines of input text are short. (The "source code", "wiki text", or "input text" is what editors see and change in the text box of the "edit this page" form; the displayed text is what is shown to the reader.)

One benefit is that the line breaks make diffs smaller and (arguably) easier to read, and this was especially true before the changes to the styling of diffs made in 2012. In addition, if there is a line break at least at the end of every sentence, editors can easily locate, rearrange, or modify sentences within a long paragraph. Since writers often think in terms of sentences, it makes sense to organize the text that way. This section of the article, for instance, is broken into multiple lines, largely at clause boundaries.

The article on Steaming is one good example on how the diff algorithm fails miserably. The "very minor" changes dated 03:48, January 19, 2006, by user 64.69.92.30 in the revision history, show how the minor changes failed to show up as what they actually are because the minor changes to consecutive paragraphs throw diff totally off base. It would have avoided such a big mess if the paragraphs were broken into one line per sentence, as diff would have found consecutive identical sentences.

Finally, a rebuttal of many of the above points:

 * MediaWiki software does not allow line breaks in the middle of a paragraph indented with ":", but paragraphs that should be indented are generally shorter than other paragraphs.
 * MediaWiki software does not allow line breaks in the middle of a list item, but items in a bulleted list (using "*") or numbered list (using "#") are generally shorter than paragraphs. In fact, it is easier to convert the individual sentences of a properly line-broken paragraph to list items or vice versa.
 * MediaWiki software does not allow line breaks in the middle of a link, but linked phrases generally do not start in one clause and end in another.
 * Many editors insert line breaks into the source code only where there is a logical, semantic break. Consider this example:
 * The consequences of this Amendment to American society have been profound. First Amendment questions have been raised with regard to the separation of church and state; civil rights issues; pornography and obscenity; political speech and organizations; journalism and its restrictions; involuntary commitment laws; and many more.
 * Text is no longer wrapped only at the window edge of the text entry area, but where the author chose to make the linebreak. Thus, there will be a lot of whitespace within a paragraph, which reinforces the semantic breaks.
 * The appearance of the article source text has always been different from the appearance of the rendered output. For example,  contains brackets, but it is rendered as line break, which does not.

title: Wikipedia:Line breaks usage


text:
Wikipedia talk:Line breaks usage

Don't-use people
Supporters of the rule "Don't use (single, manually entered) line breaks" include:

 * Justfred - "Don't put in arbitrary line breaks where they don't belong."
 * Rotem Dan (very strongly, I think the markup text should look as close as possible to the text displayed, this eases on finding a specific point in the text by looking at the rendred paragraphs.)
 * Eloquence, [use line breaks] makes no sense (see below)
 * Martin (after swinging back and forth, I think I'm generally against this now)
 * Tannin Extra line breaks make editing painful.
 * Zoe (also very strongly.)
 * Hephaestos [single, manually entered line breaks] leave minor changes floating completely out of context with the rest of the material.
 * Patrick Changing text into list elements or indenting it becomes cumbersome, the line breaks have to be removed.
 * John Owens hates cleaning up when a line break ends up in the middle of a would-be wikilink. (But I'll usually leave them be if they're at least at ends of sentences instead of every 80 characters or less.)
 * Camembert (if line breaks are added, the result is awful to read in the edit window, makes some editing trickier, and if anything makes the diff function less useful, not more, because diffs are shown out of context, making them harder to find in the article)
 * Oliver P. (Yes, what he said. And what Martin said below. I can't come up with anything original, sorry.)
 * bdesham -- yes, what Camembert said. I'd like to add that I find this really, really, really, really annoying.
 * ABCD – what bdesham said
 * Vsmith Never used 'em or gave this a thought 'til someone griped at me. Seems a holdover from archaic pre-hrml time? Plus I agree with all those above.
 * Bcat (talk | email) 17:22, 17 July 2005 (UTC)
 * EldKatt (Talk) I don't think small diff pages (the only major argument I can see) is worth the price of out-of-context diff pages and a generally hard-to-read source. A paragraph is a paragraph, and I like my paragraphs looking like paragraphs. The idea of having all sentences aligned makes particularly little sense to me.
 * Ben Arnold I've never seen anyone do this random-line-breaks-in-a-paragraph thing, but I'm sure it would be tidied up by the next editor if they did. Seems really weird and difficult to use/read.
 * ElAmericano Per everybody.
 * This sounds nice in theory but is impractical in long articles. More importantly, it's highly dangerous to rely on peculiar software features. Xiner (talk, email) 01:01, 3 March 2007 (UTC)
 * DRAGON Elemental (EXACTLY what Camembert said. It makes editing harder, and breaks context diffs - so it's a no-brainer!)  —Preceding undated comment added 11:50, 5 April 2011 (UTC).

 * 5CR1PT (talk) And I would also argue that it makes Wikipedia more future-proof and (a tiny bit more) format-agnostic for cross uses via solutions like Pandoc. And one never knows, maybe one day Mediawiki parser will be moved to the more user-friendly Markdown markup language? :)

Use people
Supporters of the rule "Use (single, manually entered) line breaks" include:
 * tbc
 * Damian Yerrick
 * LDC
 * Bryan Derksen
 * Eclecticology
 * Kowloonese (strongly; it is silly to spend timing doing what the browser does for you, i.e. the formatting. So my main concern left is the quality of the "diff" result.)
 * "it is silly to spend timing doing what the browser does for you" sounds like an argument against this rule, not for it --Camembert
 * The browser does the HTML layout for you. It doesn't do the wikitext diffs for you. This argument is about the wikitext, not the result after converting to HTML and normalizing whitespace per HTML rules. --Damian Yerrick (talk | stalk) 03:16, 3 March 2007 (UTC)
 * Rossami (I recognize the potential format problems, but judicious use of linebreaks can make downloading the diff pages much faster. I routinely work on dial-up and this is a big problem for me.)
 * zeno (there is no problem at all for using line breaks in normal paragraphs, e.g. after the end of a sentence - of course I could be convinced of the "Don't use" rule - atm I am just not convinced)
 * Error -- I use a line per sentence when adding text. Not in :, or * (like here). But people like to group them back when I'm not looking.
 * Nyenyec - I'm color blind and for me no line breaks make it extremely hard to find the changed sections in a large paragraph. Therefore I use a line per sentence when I write.
 * User:EdwardOConnor
 * Martin Geisler I consider the lack of support for linebreaks in lists a serious defect in the Mediawiki parser --- the long lines makes the text harder to read. (PhpWiki has had support for this in a long time.)
 * DavidCary 20:25, 29 November 2005 (UTC) : I also use a line per sentence when adding text, like User:Error. See below.
 * rossb (talk) : it makes the diffs so much easier to check.
 * Dave3457 Line breaks help the reader absorb the information. Sometimes a new paragraph is not appropriate but you still want to communicate that the present sentence is a new line of thought. If the diff software doesn't deal with them then why not get it to? That being said they should not be over done. Also they should always be at the end of a sentence and the next sentence should start on a new line in the edit window. —Preceding undated comment added 08:15, 17 February 2010 (UTC).
 * I agree with most of the people in this section. Line breaks not only make the diffs easier to check and less likely to be "confused," they also reduce clutter in the edit window. Jeh (talk) 00:28, 13 October 2012 (UTC)
 * Aymatth2 (talk) 14:15, 5 November 2013 (UTC) Three reasons:
 * When I start an article I often rearrange text until I am satisfied with the sequence. My mouse coordination is not great. If each sentence is on a line or lines by itself I find it easier to select a sentence, then cut it and paste it somewhere else.
 * I prefer not to overcite. Two or three sentences may have a cite like at the end of the last. Before moving one of these sentences somewhere else, I have to copy the cite to the end of it too, which is easier with line breaks at the end of each sentence.
 * Diffs are easier to understand
 * Batternut: Judicious sentence-ending line breaks eases dealing with big paragraphs - diffs are better and editing is easier. The arguments against such usage are very weak: indenting a paragraph - almost never necessary; convert to list item - bad style, rarely useful; whitespace in the text entry area a waste of space and distracting - not with judicious sentence-ending line breaks; appearance of the source differs from rendered - it's wildly different anyway; may confuse new editors - just weasel words!
 * 7dare (talk) 10:49, 29 January 2019 (UTC): Strongly, they allow for a certain point in the source to be found much more easily if each line in the source begins at the beginning of a sentence. It avoids making the source into an intimidating monolithic block.
 * Ita140188 (talk) Source code is much clearer, especially when there are references at the end of each sentence. Diffs are also clearer --Ita140188 (talk) 18:58, 19 February 2019 (UTC)
 * Sirjohnperrot: A straightforward means of improving readability and typographical appearance when used appropriately for sentence ending.Sirjohnperrot (talk) 19:53, 18 June 2020 (UTC)
 * : Makes parsing changes in diffs easier, since each sentence (or clause) in the old version is matched with the corresponding sentence in the new version. Especially helpful when paragraphs are very long and/or contain many references, since users will not have to scroll past huge blocks of unrelated wiki-markup. Especially helpful when paragraphs are long and diffs are minor and hard to spot, such as changing punctuation marks. Per WP:CREEP, it should be up to users' discretion whether or not to use. —Sangdeboeuf (talk) 04:29, 8 July 2021 (UTC) edited 08:30, 2 December 2021 (UTC)

Other people
Supporters of neither rule, both rules, agnostics, etc:
 * doom I reluctantly agree that avoiding embedded linebreaks in paragraphs is probably the right way to do it with the wikipedia software, it would be better if the software did not impose the need to be finicky about details like this.

Now, I agree fully with this guideline and all (even though I keep forgetting to practice it :), but I do have one possible objection/question; isn't a soft line break one of those line breaks inserted automatically by word wrapping and a hard line break one of those line breaks inserted by hitting the enter/return key? If that's indeed the case, we want to use hard line breaks and not soft line breaks. If it isn't the case, then never mind. Bryan Derksen
 * Maybe the word "soft" should be removed from the rule; many people (myself included) may not have a clear view of the difference between soft and hard breaks. This is really about nice formatting in general.  One principle in that would be to avoid excessively long paragraphs; if that's done the "diff"'s will fall into place.  Eclecticology

(Justfred) Force users to edit their text in a specific way because the diff function doesn't support sentances, only paragraphs? And use the fact that the formatter ignores single soft line breaks? This seems wrong to me. A paragraph is a paragraph. Don't put in arbitrary line breaks where they don't belong. For that matter, I'd like it if the formatter understood single-linebreak-separated lists without needing br tags. I'd prefer if it were as close to WYSIWYG as possible. --justfred
 * I guess this is just a recommendation. The user can write any way they want to if they don't care about the extra burden on the systems and other users.  It is a courtesy not a mandate.  The diff function needs to work harder and slow down the server if it needs to process a long paragraph versus a short sentence.  Other users can read the diff report easier if the context is narrowed down to just one sentence.  The download time of the diff page is faster if the diff blocks are smaller by eliminating all the unchanged sentences around the changes. Yes, I agree that if the diff function is smart enough, we can do away with this workaround.  But given the situation, this is a good compromise.  -- 63.192.137.21

--

This policy is perhaps obsolete now Wikipedia has spiffy side-by-side diff output. -- Tarquin 12:47 Jul 30, 2002 (PDT)

 * What it all comes down to is "write short paragraphs for ease of online reading", but that sound point is pretty well hidden in all the verbiage, ironically. Ortolan88

No, that wasn't the intent of the rule at all. What we wanted to encourage is frequent hard breaks in the source text (that is, the text in the edit box), which make no difference at all in how the article is displayed, but make it easier to edit in many ways: First, some editors (particularly in the Unix world) don't handle long lines well. It makes diffs faster and smaller and easier to read, even with the new features. And it makes it easier to find sentences within a paragraph, and to rearrange sentences. --LDC

It makes editing extremely tedious and the text becomes difficult to read unless your edit box width happens to be set to the same size as the person who edited the text before you. Often when the text is edited, the extra bits are added without adjusting the lengths of the rest of the lines. This leads to some lines being much longer than other, and this is really difficult to read. It's only a problem for editors, but that is important enough to me. Don't you think? Of course you could ask everyone when adding a few words to re-edit the entire paragraph so as to maintain the arbitrary maximum line size typically of 80 chars. But this is tedious. Note that while a few editors don't deal well with long lines all editors deal badly with this kind of short line as used here: it ends up taking a whole bunch of extra space and you end up with a bunch of wasted white space on the right hand side. This happens to me with LDC's edit above - and wasted space is bad UI design. That's why we should write like, well, normal people. This is one of those instances where just because you can do something, doesn't mean that you should. Martin 00:27 5 Jun 2003 (UTC)

 * As an example - the above response is mis-indented (it should be at a single level of indentation, as a reply to LDC. However, fixing this is hideously tedious, and it's the single manual line-breaks that make it so. I could solve the problem by indenting LDC's comment instead.... but that's got the same problem. Remind me again how manual line breaks make pages easier to edit? Martin

I have also found several instances in articles where a line break is put in the middle of an internal link; this breaks the link. - Hephaestos|§ 18:58, 21 Mar 2004 (UTC)

one line per sentence
I also use a line per sentence when adding text, like User:Error. But I avoid adding line breaks in the middle of a sentence. My best excuse is that it helps me edit for improved readability -- it makes long sentences (which always hurt readability) stick out like a sore thumb. Also it helps me entirely avoid the Full_stop controversy. Probably the real reason I do it is a relic habit from old wiki software whose "diff" made it difficult to find minor changes in a long paragraph. But what irks me is people who clutter up Recent Changes, making no change other than adding or deleting these invisible-to-the-reader linebreaks (or other whitespace). --DavidCary 20:25, 29 November 2005 (UTC)

This makes it easier to follow the Guide_to_writing_better_articles guideline. --DavidCary 08:01, 20 January 2006 (UTC)

This ballot is problemetic. I support one line per sentence but I am against random line breaks in the middle of a sentence or paragraph. My vote does not fit anywhere precisely, so I voted for use line breaks. I bet many who voted may have to face similar dilema. IMO, this voting result is not representative of what people really think. Kowloonese 20:03, 2 February 2006 (UTC)

Proposed conversion into a redirect
This page seems to cover the subject in rambling and unnecessary detail. I propose replacing the page with a redirect to How to edit a page. Please let me have your thoughts. jguk 11:34, 31 Oct 2004 (UTC)

Userbox
Would somebody care to make Userboxes for these choices? --Error 03:17, 11 March 2006 (UTC)

==  vs ==

I understand that the  tag is invalid XHTML, but it is converted to   upon rendering by MediaWiki. So it's really an aesthetic difference, and in my opinion,  looks much cleaner. (For example, m:Help:Editing ( [#Most_frequent_wiki_markup_explained permanent link] ) uses it in one of its wikitext examples.) Is there any consensus on Wikipedia as to which one is preferred? Thanks. —dto (talk contribs)  06:40, 2 November 2006 (UTC)

etc. STUPID 213.112.137.148 13:16, 17 March 2007 (UTC)
 * Lol, do some reading will you. In XHTML you need to close tags which are supposed to be self-closed for the code to pass validation. Just like isn't valid without a subsequent, you need to write ,

 * But dto's point is that MediaWiki converts the HTML 4  to the XHTML   when preparing the page for rendering. So it really doesn't matter what you enter, just as the difference between   and   does not matter. --Damian Yerrick (talk | stalk) 16:21, 17 March 2007 (UTC)

Which should we use? or ?

Let's examine this step by step:

1: Writing the XHTML code  without a blank is even against the recommendations of the World Wide Web Consortium, instead it should be written as   since then HTML parsers can understand it too. HTML parsers will simply regard  as a "br" with an unknown parameter "/", while they will regard "br/" as an unknown tag name. So we should definitely not teach people to write, but possibly.

2: The "HTML" codes we use here at Wikipedia are not XHTML markup nor are they HTML markup, instead they are "HTML wikimarkup", since MediaWiki processes them just like wikimarkup.

3: Wikipedia mainly uses wikimarkup. The reasons for that is simple: Most people that edit Wikipedia are people who never have made a web page, so they know nothing about HTML, XHTML or CSS. So for them (and even for us old webmaster geeks) it is easier to use wikimarkup.

4: So far I have seen the documentation for MediaWiki talks about "HTML in wikitext" and never mentions "XHTML in wikitext". Also up until recently all documentation listed  as the code for forced line breaks. But some months ago some XHTML enthusiasts went around and edited a lot of the help pages to show the  or even the.

So which should we use? or ?

Well, let's first ask another question: Which markup should we use for bold text?

I think we all know that the wikimarkup  is the recommended one. Mainly because it is simpler to use, especially for the majority of editors that don't know HTML and CSS.

The same goes for  vs. The HTML wikimarkup  is easier for the majority of editors to use, and it is shorter.

Sure, we have a "teaching opportunity" to teach people to use the, but there is a very high risk that they instead will use the   and that would be a bad thing. And believe it or not, many beginners have problems telling " " and " " apart. So they might even try to use the ...

So again, the  is easier for the majority of editors to use, and it is shorter.

--David Göthberg (talk) 23:19, 14 March 2008 (UTC)

Consolidation?
Please note that this page has been nominated to be consolidated with the primary Manual of Style page. Please join the discussion at the MOS talk page in order to discus the possibility of merging this page with the MOS. Thank you. — V = IR (Talk • Contribs) 14:08, 27 March 2010 (UTC)

MoS naming style
There is currently an ongoing discussion about the future of this and others MoS naming style. Please consider the issues raised in the discussion and vote if you wish GnevinAWB (talk) 20:52, 25 April 2010 (UTC)

Move
Don& → Manual of Style (line breaks) — Consolidating naming per Wikipedia_talk:Manual_of_Style Gnevin (talk) 16:24, 24 May 2010 (UTC)

Oppose: This appears not to be a style guideline, but rather a page consisting of two opposing essays.—DCGeist (talk) 22:31, 25 May 2010 (UTC)
 * Remove from the MOS? Gnevin (talk) 12:32, 26 May 2010 (UTC)
 * I've marked as essay, no serious edits in over 2 years Gnevin (talk) 13:53, 26 May 2010 (UTC)

Visual Editor
I think it is worth mentioning something about the Visual editor, because it will likely make it largely unnecessary to use the wiki code. So, there would be less reason to worry about it. Helder 12:28, 4 June 2012 (UTC)

Line breaks. br variants discussion elsewhere
Please see Help talk:Line-break handling

It is a detailed discussion with participation from editors, developers, admins, etc.. '''Most people in that thread want  used, not . See also: KISS principle'''.

See also MOS:SIMPLIFY: "Other things being equal, keep markup simple. This makes wikitext easier to understand and edit, and the results seen by the reader more predictable. Use HTML and CSS markup sparingly." --Timeshifter (talk) 08:41, 11 February 2023 (UTC)

title: Wikipedia talk:Line breaks usage


text:
Wikipedia talk:Writing better articles/Avoid making your articles orphans

Supporters of this rule include: Clasqm, Larry Sanger, Damian Yerrick, Josh Grosse, 24

Opponents include: AxelBoldt (a chain of links is desirable, but orphans really don't pose a problem, since most people use the search engine anyway) and David Cannon.

My opinion: It's a good guideline, but shouldn't be taken as a hard-and-fast rule; doing so may result in more spurious links, in cases where related articles are sparse. Categories help too. Derrick Coetzee 23:44, 11 Oct 2004 (UTC)

 * At present there are many articles in the Wikipedia namespace that seek to give guidance on how to write better articles. I propose consolidating these into a much smaller number. On User:Jongarrettuk/Better writing guide I propose how these could be consolidated. The proposal is not to change advice, just to consolidate it. If I have inadvertently moved what you consider to be good advice that is currently in the Wikipedia namespace, please re-add it. I'm hope that the proposal to merge all these articles, in principle, will be welcomed. Of course, it may be preferred to have 2, 3 or 4 inter-connected articles than just one and would welcome advice on how this could be done. (In particular, perhaps all the guidance on layout should be spun off into one consolidated article on layout.) I'm also aware that putting lots of different bits of advice together may throw up anomalies or bits that people now disagree with (including bits that I myself disagree with:) ). I ask for support for the consolidation. Once the consolidation has happened, the advice can be changed in the normal way. Please feel free to improve on the current draft consolidation, but don't remove or add advice that is not currently on the Wikipedia namespace. If all goes well, I'll add a new Guide to writing better articles page on the 19th, though maybe some bits of the new article will need to be phased in over a longer period. I'll also take care to preserve all the archived discussion in one place. jguk 19:36, 11 Nov 2004 (UTC)


text:
Wikipedia talk:Writing better articles/Use other languages sparingly

Supporters of this rule include:
 * MichaelTinkler,
 * JHK (Ok non-English titles I can think of are pietas, hubris, and possibly basileus and strategos),
 * 24 (those are now considered English)

Opponents include:
 * Anders Torlind (nota bene only in cases where not supplying foreign article names violates the "Useful for readers" rule. Example: People searching for the Swedish kings are very likely to be Swedes, and so a redirect from the swedish name--or to it, doesn't matter--would be appropriate)
 * Eclecticology (By making the original title the principal entry, with appropriate redirects, you can avoid ambiguities. e.g. Camus' novel "L'Étranger" has two common translations of the title.
 * The bellman
 * There can often be more than one correct translation of a word/phrase eg. Bokmål - Standard Norwegian, book language, Dano-norwegian. This makes linking harder, and also means that one wikipedia article could mention dano-norwegian, whilst another could mention standard norwegian, and the average reader reader wouldnt have a clue that the two were the same
 * Sometimes an english translation could cover two seperate concepts in the native language and lead to ambiguity.
 * Often due to historical legacy and other reasons, the accepted english "translation" is not in fact a translation. eg. Bokmål translates as book language, however the most common english "translation" is Dano-norwegian.

Acronyms with Foregin Language Etymology
I discovered that Omegatron is changing Latin phrases and acronyms he comes across in wikipedia to English expressions. He interprets the Use Foregin Languages Sparingly subsection as support for this. I, personally, am of a different opinion concerning the acronyms that are sprung from a Latin phrase (such as i.e.) because they are so widespread, and have been so for such long time, that they are part of the English language. This policy does not cover these special cases at all, are they covered somewhere else? If not, I would like to see a discussion on this issue (and maybe, if consensus can be reached, a policy). --Probell 20:51, 4 September 2005 (UTC)

tagging foreign words with lang property
In addition, you might want to use HTML to mark other languages as being other languages. For example, in Mozilla, if you right-click nota bene and choose Properties, you can see that it's in Latin because I have marked it up as. (Or would that be a bad thing on Wikipedia?) --Damian Yerrick

 * Not entirely unreasonable. The lang attribute is probably most useful for two things: speech interfaces for blind users which could (in theory, at least) make an attempt at switching to appropriate pronunciation; and selecting the correct glyphs for characters that can differ between languages (for instance, selecting the Japanese or Chinese form of a kanji/hanzi character, which sometimes share the same Unicode code point despite differing somewhat in form). Brion VIBBER

 * Good idea, but your suggestion failed to get support for the past two years simply because it is too cumbersome to write. However, if wiki programmers would supply a macro to allow easy entry, then it may be adopted.  For example,   can generate   automatically.  Kowloonese 20:42, 11 Nov 2004 (UTC)

Format for terms in other languages
(from the village pump)

I haven't been able to find an answer yet. When it's important to provide translation of words in another language (German: Sprache), what is the standard?

 * As far as I know, there's no official standard, but "Englishword (Other: Foreignword)" is a widely used de facto standard. I'd suggest using that unless it's awkward in the particular context.  Less standardized is how to deal with foreign words that are not in a Latin-type character set, where it might be helpful to provide both the original word and a Latin-alphabet transliteration.  One method of doing this is "Athens (Greek: Αθήνα, Athina)".  A CS person would do "Athens (Greek: Αθήνα (Athina))", but nested parentheses are generally a no-no in writing. --Delirium 07:28, Feb 8, 2004 (UTC)
 * But brackets work fine there: "Athens (Greek: Αθήνα [Athina])" Jor 15:53, 8 Feb 2004 (UTC)

 * Thanks, that's the format that I've been using. Except what is the rationale for hyperlinking the language name. To me, it ruins the flow and is an unnecessary link (unless the language is one that most ppl don't know about).Bwood 15:17, 8 Feb 2004 (UTC)

Proposal to consolidate advice on writing better articles
At present there are many articles in the Wikipedia namespace that seek to give guidance on how to write better articles. I propose consolidating these into a much smaller number. On User:Jongarrettuk/Better writing guide I propose how these could be consolidated. The proposal is not to change advice, just to consolidate it. If I have inadvertently moved what you consider to be good advice that is currently in the Wikipedia namespace, please re-add it. I'm hope that the proposal to merge all these articles, in principle, will be welcomed. Of course, it may be preferred to have 2, 3 or 4 inter-connected articles than just one and would welcome advice on how this could be done. (In particular, perhaps all the guidance on layout should be spun off into one consolidated article on layout.) I'm also aware that putting lots of different bits of advice together may throw up anomalies or bits that people now disagree with (including bits that I myself disagree with:) ). I ask for support for the consolidation. Once the consolidation has happened, the advice can be changed in the normal way. Please feel free to improve on the current draft consolidation, but don't remove or add advice that is not currently on the Wikipedia namespace. If all goes well, I'll add a new Guide to writing better articles page on the 19th, though maybe some bits of the new article will need to be phased in over a longer period. I'll also take care to preserve all the archived discussion in one place. jguk 19:57, 11 Nov 2004 (UTC)


text:
Wikipedia:Contribute what you know or are willing to learn more about

Two of Wikipedia's rules to consider. Both of these guidelines are controversial.

Contribute what you know or are willing to learn more about
Contribute what you know or are willing to learn about. One of the things that makes the Wikipedia great is that anybody can contribute, however this creates a problem to whether the information posted is true, but another thing that makes it great is that it encourages Wikipedians to stretch their interests and learn about new things, so that they can add to the 'pedia. A third great thing is that it's so easy to create new articles and to learn to wikify articles.

Some users see the ease in which new articles can be created as problematic. Many users know something about a subject, but few have exhaustive knowledge of the subject they are writing about. That leads to users creating stubs (very short articles) that need to be extended by someone with more knowledge before the article can be useful to anyone. This irritates some because it leaves a lot of unfinished work in Wikipedia.

Other users have diametrically opposite views of stubs, that an iterative style of development can indeed be beneficial. They feel that the problem described above isn't a problem but a part of the normal wiki process, that a not-so-good article is better     than no article at all.

Always make articles as complete as possible
(an alternative phrasing)

Whenever you create a new article, always try to make it as complete and comprehensive as possible. However, an article that is seriously incomplete but a useful start is welcome, too. But first check so that the article you are about to create doesn't already exist in Wikipedia. Or maybe your new information would be better placed in an already existing article? If you are a newcomer to Wikipedia, concentrate on adding content; do not worry too much about formatting. If anything your edits should cause other editors to get involved by reverting and or further re-editing the article (see BOLD, revert, discuss cycle).


text:
Wikipedia talk:Contribute what you know or are willing to learn more about

Contribute what you know or are willing to learn about
Supporters of this rule include:
 * JHK,
 * Danny,
 * AxelBoldt,
 * KJ Supports it with reservations. Even a stub is better than a non-existant page in a lot of cases. If you can say trevalla is a kind of Australian fish' that tells someone more about the subject than they probably knew before. ~KJ
 * Eclecticology
 * Wapcaplet supports, mostly. Perfect stubs are better than nothing.
 * GrahamN thinks it is a good guiding principle, but it shouldn't be a called a "rule".
 * The Anome
 * Toby Bartels
 * Martin (as a suggestion - we think this is most efficient... but if you want to be inefficient, then that's fine!)
 * irismeister 18:55, 2004 Feb 19 (UTC)

Opponents include:
 * 24 (if you think it should be there, that's useful to others, so write that seemingly useless stub--that's a bit more information than they had before.)

Always make articles as complete as possible
For reference, the original version was:

''One of Wikipedia's rules to consider: Whenever you write a page, always make it as complete and comprehensive as possible. Don't create an article until it is in form ready for publication. If you feel that your article is seriously incomplete and you are urged to publish it please insert boilerplate text from Stub into the article.''

Supporters of this rule include:

 * Kpjas
 * irismeister 18:55, 2004 Feb 19 (UTC) (2 cents - although it increases deletionism, it might encourage serious authors, and possibly reduce the newbies' pyramid's top, deflating author-per-editor ratios :-)
 * [your name here]

Opponents of this rule include:

 * Theresa knott
 * jimfbleak
 * LittleDan
 * Tim Starling
 * Wapcaplet
 * Cyp
 * Anthere
 * Martin
 * Fonzy
 * The Anome
 * Toby Bartels (the version above)
 * [your name here]

Note: on 29 June 2004 I reverted edits by 168.210.50.25 (Megadeath) on 14 June 2004 to last version by 134.58.253.130 as of 25. March 2004. The Megadeath edits were vandalism, which replaced the "Always make articles as complete as possible" section. The 14 Jun 2004 edit by 24.232.197.174 removed the Megadeath vandalism, but didn't restore the "complete as possible" section. Subsequent edits were just another case of vandalism and a reversion to correct it. So I think my revert of 29 June 2004 just finished the task of repairing the Megadeath vandalism of 14 June 2004, and was neutral as far as changing the content of the page. I see there's a debate about the wisdom of the "complete as possible" guideline, and I don't intend this edit to be part of that debate. Jim DeLaHunt

Further Discussion
A possible related rule might be "You don't have to be perfect before you write about something" ... or similar wording. If someone feels this merits a separate rule than by all means set it up.

We all have disconnected bits of random data rattling in our heads. At the same time we may be afraid that that knowledge is not perfect enough to write about. Perfectionism is a particular problem in the education of gifted children. If you don't know all the details about a topic don't let that stop you from writing. Be free to include question marks to show doubts, thus if you write "John James(?) Jones" you are telling me that you are uncertain about the middle name. Somebody else out there in Wikiland will know the answer, and fix it. Eclecticology

"Don't create an article until it is in form ready for publication"

I really do not like this phrase. It will IMO put people off.

In fact I don't think I like this rule at all. What's wrong with someone making an incomplete article? Theresa knott 15:19 17 Jun 2003 (UTC)

 * I agree with Theresa. If we want to attract more people to edit, I think we have to accept that more experienced contributors may have to expand, format and wikify to help newcomers find their feet. However, I think it is reasonable for experienced contributors to try not to impose on their colleagues more than is necessary jimfbleak 15:27 17 Jun 2003 (UTC)

Every small contribution should be welcome. However, if you contribute just a sentence or so, consider not creating a new article, but incorporate it in the most related existing article. - Patrick 15:22 17 Jun 2003 (UTC)

I hate this rule. There is nothing wrong with a stub. LittleDan 15:25 17 Jun 2003 (UTC)

I object to that quoted sentence too. I think more anxious people will misinterpret that to mean that an article has to be polished before it is posted. Editing is, and should remain, a collaborative effort. There is a minimum standard -- in my experience two decent sentences written in comprensible but not necessarily perfect English seems to be enough to avoid complaints. -- Tim Starling 15:28 17 Jun 2003 (UTC)

 * shows many new "articles" which are each just a copy of one line of list of phobias. This does not seem very useful (and indeed does not satisfy the criterion of two sentences). - Patrick 08:32 18 Jun 2003 (UTC)

There needs to be an option. I've had a couple of articles that I built in pieces, and added each part as they were done. (See Daniel Morgan and its article history.) The technique allows me to resolve links, adjust related articles, etc. It also lets others comment or adjust my work as it is being developed.

If we really want this as a rule, I would be happier with a suggested approach of creating a stub that references a /Temp subpage that is built up, then moved over the stub when finished. Lou I 15:39 17 Jun 2003 (UTC)

 * This is left to Wikipedians to decide when they think their articles are fit to be published. No limits set. This is an observation from perusing the ancient pages list.  Articles happen to be reviewed almost instantaneously (as they appear on RC) or they can stay unreviewed with embarrassing errors for months (years?).  Cooperation and collective authorship that are behind the "Always leave something undone" rule were great in the old days when there were 50-100 edits daily not 3000+.  People are reviewing new articles and new edit only "part-time".  This rule is meant for the good of Wikipedia and to maintain good overall quality of Wikipedia texts.  Kpjas 15:40 17 Jun 2003 (UTC)

Surely the more edits there are, the more people there are, therfore the more people reviewing the rc ? Theresa knott 15:45 17 Jun 2003 (UTC)

 * These are our hopes and feelings. Facts seem to contradict this. How come one can find so many poor or outright false articles that lie undetected for a year and a half. I even remember coming across an article with the whole text "hello I am John" and it was quite old. I think we need some research (statistics) to find out if the current editorial process will hold out in the nearest future. Kpjas 16:11 17 Jun 2003 (UTC)

I strongly disagree with this rule. It defeats the whole nature of collaborative editing and the wiki concept in general. To me, it seems that practically all of the benefits of Wikipedia derive from its collaborative, piece-meal nature. Someone writes a stub; someone else adds a couple nuggets of information; someone corrects a bit of spelling; someone more knowledgeable about the subject comes in and in a couple broad strokes hammers out a good outline article; it gets fleshed out by 20 other people. It is more like Jazz, and less like Classical. This rule seems very counterproductive, and likely to scare many new (or even some old) contributors away. -- Wapcaplet 16:00 17 Jun 2003 (UTC)

Suppose I'll support this rule, since there's no point in a discussion page, where everyone agrees, and everyone seems to hate the rule... Just as long as I don't actually have to give any reasons for this ridiculous wonderful rule, as it's impossible to come up with any half sane reason for this crazy rule so divine it transcends Earthly logic! كسيپ Cyp 16:20 17 Jun 2003 (UTC)

No. User:Anthere

 * A rule with even less support than Always leave something undone! Wow! I disagree as well, for essentially the same reasons.
 * Kpjas - note that users of Wikipedia do not use the ancient pages list, and rarely the random page list, so their exposure to junk is considerably less than you fear. For example, PC Magazine said "Surprisingly, our time spent on Wikipedia turned up no junk entries and no defacements". That's the sort of comment that, to me, totally validates the Wikipedia process. Yes, there is vandalism, but soft security makes it harmless. Martin 21:57 17 Jun 2003 (UTC)

 * I don't deny that Wikipedia is wondeful and so far it has been a success as long as editorial process leading to production of reasonable quality encyclopedic content goes. But... "Our goal ... is to create a free encyclopedia--indeed, the largest encyclopedia in history, in both breadth and depth. We also want Wikipedia to become a reliable resource." And there was no analysis (AFAIK) of article quality and trends in it. Surely there are no barriers to improvement of the, let's called them, underdeveloped articles but I notice that most stubs remain stubs. The opposition to this rule to consider is quite understandable, people care about Wikipedia's growth. But please make it clear to newcomers and old hands alike: create stubs responsibly hunt and kill stubs more actively. Kpjas 08:03 18 Jun 2003 (UTC)

 * If you want to analyse Wikipedia quality, do so - start by updating statistics, for example. If you produce good evidence you might convince us of the merits of this guideline. Until then, we are likely to remain skeptical.
 * Creating stubs responsibly is already covered at The perfect stub article and Contribute what you know or are willing to learn about. "hunting and killing" stubs is already covered at find or fix a stub.
 * Ironically, one part of creating stubs responsibly is not creating new articles on subjects that are already covered elsewhere. Martin 09:08 18 Jun 2003 (UTC)
 * done. Martin 09:13 18 Jun 2003 (UTC)

Here's a thought that nobody seems to have considered. Most responsible newbies, when experimenting, will either do so in the sandbox, or in their own page, or will immediately delete their "vandalism". Anyone who creates a page with the text "hello I am John" and fails to blank it, is probably not the sort of person to take any notice of a rule like this anyway.Theresa knott 08:19 18 Jun 2003 (UTC)

I added "more": "Contribute what you know or are willing to learn more about". You can not contribute anything you do not know yet. - Patrick 10:04 18 Jun 2003 (UTC)

I disagree with this. Part of the point of "or are willing to learn [more] about" is that you need know nothing when you decide to contribute. But you are willing to learn about it, and so you do learn about it -- before, of course, actually writing anything. With the "more" in, the whole clause becomes meaningless.

That said, I think that the entire clause is confusing, and so we should really go further than you did and just say Contribute what you know. After all, if you learn about something before you contribute, then you know it when you contribute, don't you? If we want to point out that you might not know anything know, but instead learn about it and then contribute, well, the text explains that. But the title should be short and to the point.

-- Toby Bartels 21:26 19 Jun 2003 (UTC)

I like Wikipedia:Contribute what you know. Martin 23:51 19 Jun 2003 (UTC)

 * I like the phrase " ...or are willing to learn more about". I have started several new articles because I wanted to learn more about a subject.  It was an incentive to me to do some research.  I appreciate Toby's point that by the time I contributed I actually did know something about them, but this seems to miss the point somehow.  GrahamN 12:39 20 Jun 2003 (UTC)

 * Very well ... but do we agree that adding "more" does miss the point -- it misses the point of the phrase "or are willing to learn about". -- Toby Bartels 16:10 1 Jul 2003 (UTC)

 * I do not mind renaming to the short title. One learns by just reading Wikipedia, by preparing a contribution, and by reactions (additions, corrections) on one's contribution. - Patrick 13:09 20 Jun 2003 (UTC)

Idea to lower down stubs
I don't know if this has been proposed before, since I'm new here, but how about a Sandbox namespace for articles? Something like:

 * There is no text on this article.

 * Help Wikipedia by creating a new article or by contributing in the construction of it. blah blah blah.

Where the 2nd link points to /wiki/Sandbox:Title_of_article.

Pros:
 * avoids stubs
 * avoids innacurate and incomplete information
 * in case of media coverage, the media will notice that Wikipedia doesn't list incomplete articles
 * stronger relationships between Wikipedians, since they all discussed the article before publishing it

Cons:
 * infamous stub controversial issues will arise
 * less articles created, since there is no reason to fix the stub because it is not listed in Wikipedia yet
 * media will think that Wikipedia is vague since it lacks hundreds of entries (which are really on "under construction" process)
 * who determines where it is valid to move the article from Sandbox to Wikipedia
 * more work load or memory usage as articles will have to be moved from Sandbox to Wikipedia/Title_of_article, or Sandboxes will have to be deleted

That's what I'm currently doing with Hawk helicopter for the simple reason that there is no need to create a stub for it (see UH-60 Black Hawk) and that I asked a fellow Wikipedian to help me publish it.

What do you all think?

--Maio 14:06, Jan 14, 2004 (UTC)

Attention : revert needed
I added the attention sign to the article. Current text has nothing to do with the topic. Some competent user please revert to original, I dont know how.


text:
Wikipedia:No personal attacks

Do not make personal attacks anywhere on Wikipedia. Comment on content, not on the contributor. Personal attacks harm the Wikipedia community and the collaborative atmosphere needed to create a good encyclopedia. Derogatory comments about other editors may be removed by any editor. Repeated or egregious personal attacks may lead to sanctions including blocks or even bans.

What is considered to be a personal attack?
There is no rule that is objective and not open to interpretation on what constitutes a personal attack as opposed to constructive discussion, but some types of comments are acceptable:
 * Abusive, defamatory, or derogatory phrases based on race, sex, gender identity, sexual orientation, age, religious or political beliefs, disability, ethnicity, nationality, etc. directed against another editor or a group of editors. Disagreement over what constitutes a religion, race, sexual orientation, gender identity, disability or ethnicity is not a legitimate excuse.
 * Using someone's affiliations as an ad hominem means of dismissing or discrediting their views—regardless of whether said affiliations are mainstream. An example could be, "You're a railfan so what would you know about fashion?" Note that it is not a personal attack to question an editor about their possible conflict of interest on a specific article or topic; but beware – speculating on the real-life identity of another editor may constitute outing.
 * Using someone's political affiliations as an ad hominem means of dismissing or discrediting their views, such as accusing them of being left-wing or right-wing, is also forbidden. Editors are allowed to have personal political POV, as long as it does not negatively affect their editing and discussions.
 * Linking to external attacks, harassment, or other material, for the purpose of attacking another editor.
 * Comparing editors to Nazis, terrorists, dictators, or other infamous people.
 * Accusations about personal behavior that lack evidence. Serious accusations require serious evidence, usually in the form of diffs and links.
 * Threats, including, but not limited to:
 * Threats of legal action
 * Threats of violence or other off-wiki action (particularly death threats)
 * Threats or actions which deliberately expose other Wikipedia editors to political, religious or other persecution by a government, their employer, or any others. Violations of this sort may result in a block for an extended period of time, which may be applied immediately by any administrator upon discovery. Admins applying such sanctions should confidentially notify the members of the Arbitration Committee of what they have done and why.
 * Threats to out (give out personal details about) an editor.

These examples are not exhaustive. Insulting or disparaging an editor is a personal attack regardless of the manner in which it is done. When in doubt, comment on the article's content without referring to its contributor at all.

Why personal attacks are harmful
Personal attacks are disruptive. On article talk pages they tend to move the discussion away from the article and towards individuals. Such attacks tend to draw battle lines and make it more difficult for editors to work together.

Contributors often wish to have their viewpoints included in articles. Through reasoned debate, contributors can synthesize these views into a single article, and this creates a better, more neutral article for everyone. Every person who edits an article is part of the same larger community—we are all Wikipedians.

The prohibition against personal attacks applies equally to all Wikipedians. It is as unacceptable to attack a user with a history of foolish or boorish behavior, or one who has been blocked, banned, or otherwise sanctioned, as it is to attack any other user. Wikipedia encourages a civil community: people make mistakes, but they are encouraged to learn from them and change their ways. Personal attacks are contrary to this spirit and damaging to the work of building an encyclopedia.

Avoiding personal attacks
As a matter of polite and effective discourse, arguments should not be personalized; that is, they should be directed at content and actions rather than people.

When there are disagreements about content, referring to other editors is not always a personal attack. A posting that says "Your statement about X is wrong because of information at Y ", or "The paragraph you inserted into the article looks like original research", is not a personal attack. However, "The statement..." or "The paragraph inserted..." is less likely to be misinterpreted as a personal attack because it avoids referring to the other editor in the second person. "The paragraph inserted here [diff] into the article looks like original research" is especially advantageous because the diff cuts down confusion. Similarly, discussion of a user's conduct or history is not in itself a personal attack when done in the appropriate forum for such discussion (for example, the other editor's talk page, or Administrators' noticeboard/Incidents).

Editors should be civil and adhere to good etiquette when describing disagreements. The appropriate response to an inflammatory statement is to address the issues of content rather than to accuse the other person of violating this policy. Accusing someone of making personal attacks without providing a justification for your accusation is also considered a form of personal attack. (See also: Incivility.)

First offenses and isolated incidents
Often the best way to respond to an isolated personal attack is to simply ignore it. Sometimes personal attacks are not meant as attacks at all, and during heated and stressful debates, editors tend to overreact. Additionally, because Wikipedia discussions are in a text-only medium, nuances and emotions are often conveyed poorly, which can easily lead to misunderstanding (see Emotions in virtual communication). While personal attacks are not excused because of these factors, editors are encouraged to disregard angry and ill-mannered postings of others, if it is reasonable to do so, and to continue to focus their efforts on improving and developing the encyclopedia.

If you feel that a response is necessary and desirable, you can leave a polite message on the other user's talk page. Avoid responding on a talk page of an article, as this tends to escalate matters. Likewise, it is important to avoid becoming hostile and confrontational yourself, even in the face of abuse. Although warning templates may be used for this purpose, a customized message relating to the specific situation may be better received. If possible, try to find a compromise or common ground regarding the underlying issues of content, rather than argue about behavior.

Attacks that are particularly offensive or disruptive (such as physical threats, legal threats, or blatantly bigoted insults) should not be ignored. Extraordinary situations that require immediate intervention are rare, but may be reported at Administrators' noticeboard/Incidents.

Discussion of behavior in an appropriate forum (e.g. user's talk page or Wikipedia noticeboard) does not in itself constitute a personal attack.

Recurring attacks
Recurring, non-disruptive personal attacks that do not stop after reasoned requests to cease can be resolved through dispute resolution. In most circumstances, problems with personal attacks can be resolved if editors work together and focus on content, and immediate administrator action is not required.

Removal of personal attacks
Derogatory comments about other editors may be removed by any editor. However, there is no official policy regarding when or whether most personal attacks should be removed, although it has been a topic of substantial debate. Removing unquestionable personal attacks from your own user talk page is rarely a matter of concern. On other talk pages, especially where such text is directed against you, removal should typically be limited to clear-cut cases where it is obvious the text is a true personal attack. The RPA template can be used for this purpose.

Nevertheless, unusual circumstances do exist. The most serious types of personal attacks, such as efforts to reveal nonpublic personal information about Wikipedia editors (outing), go beyond the level of mere invective, and so can and should be removed for the benefit of the community and the project whether or not they are directed at you. In certain cases involving sensitive information, a request for oversight may also be appropriate.

Off-wiki attacks
Wikipedia cannot regulate behavior in media not under the control of the Wikimedia Foundation, but personal attacks made elsewhere create doubt about the good faith of an editor's on-wiki actions. Posting personal attacks or defamation off-Wikipedia is harmful to the community and to an editor's relationship with it, especially when such attacks violate an editor's privacy. Such attacks can be regarded as aggravating factors by administrators and are admissible evidence in the dispute-resolution process, including Arbitration cases.

Consequences of personal attacks
Although editors are encouraged to ignore or respond politely to isolated personal attacks, that should not imply that they are acceptable. A pattern of hostility reduces the likelihood of the community assuming good faith, and can be considered disruptive editing. Users who insist on a confrontational style marked by personal attacks are likely to become involved in the dispute resolution process, and may face serious consequences through arbitration.

In extreme cases, even isolated personal attacks may lead to a block for disruption. Death threats and issues of similar severity may result in a block without warning. Lesser personal attacks often result in a warning, and a request to refactor. If a pattern of lesser personal attacks continues despite the warning, escalating blocks may follow. However, administrators are cautioned that other resolutions are preferable to blocking for less-severe situations when it is unclear if the conduct severely disrupts the project. Recurring attacks are proportionally more likely to be considered disruptive. Blocking for personal attacks should only be done for prevention, not punishment: a block may be warranted if it seems likely that the user will continue using personal attacks.

Wikipedia policies and information pages

 * Attack page
 * Casting aspersions
 * Dispute resolution § Resolving user conduct disputes
 * Harassment
 * Libel

Wikipedia essays

 * Avoid personal remarks
 * WikiBullying
 * Candor
 * Competence is required
 * Do not insult the vandals
 * On privacy, confidentiality and discretion
 * Staying cool when the editing gets hot
 * Gravedancing

Related content

 * Wikimedia Foundation:Non-discrimination policy

title: Wikipedia:No personal attacks


text: Talk:Tantalus

title: Talk:Tantalus