text:
Applied Programming/Testing

Static, dynamic, and passive testing
There are many approaches available in software testing. Reviews, walkthrough, or inspections are referred to as static testing, whereas executing programmed code with a given set of test cases is referred to as dynamic testing.

Static testing is often implicit, like proofreading, plus when programming tools/text editors check source code structure or compilers (pre-compilers) check syntax and data flow as static program analysis. Dynamic testing takes place when the program itself is running. Dynamic testing may begin before the program is 100% complete in order to test particular sections of code and are applied to discrete functions or modules. Typical techniques for these are either using stubs/drivers or execution from a debugger environment.

Static testing involves verification, whereas dynamic testing also involves validation.

Passive testing means verifying the system behavior without any interaction with the software product. Contrary to active testing, testers do not provide any test data but look at system logs and traces. They mine for patterns and specific behavior in order to make some kind of decisions. This is related to offline runtime verification and log analysis.

Exploratory approach
Exploratory testing is an approach to software testing that is concisely described as simultaneous learning, test design, and test execution. Cem Kaner, who coined the term in 1984, defines exploratory testing as "a style of software testing that emphasizes the personal freedom and responsibility of the individual tester to continually optimize the quality of his/her work by treating test-related learning, test design, test execution, and test result interpretation as mutually supportive activities that run in parallel throughout the project."

The "box" approach
Software testing methods are traditionally divided into white- and black-box testing. These two approaches are used to describe the point of view that the tester takes when designing test cases. A hybrid approach called grey-box testing may also be applied to software testing methodology. With the concept of grey-box testing—which develops tests from specific design elements—gaining prominence, this "arbitrary distinction" between black- and white-box testing has faded somewhat.

White-box testing

White-box testing (also known as clear box testing, glass box testing, transparent box testing, and structural testing) verifies the internal structures or workings of a program, as opposed to the functionality exposed to the end-user. In white-box testing, an internal perspective of the system (the source code), as well as programming skills, are used to design test cases. The tester chooses inputs to exercise paths through the code and determine the appropriate outputs. This is analogous to testing nodes in a circuit, e.g., in-circuit testing (ICT).

While white-box testing can be applied at the unit, integration, and system levels of the software testing process, it is usually done at the unit level. It can test paths within a unit, paths between units during integration, and between subsystems during a system–level test. Though this method of test design can uncover many errors or problems, it might not detect unimplemented parts of the specification or missing requirements.

Techniques used in white-box testing include:

 * API testing – testing of the application using public and private APIs (application programming interfaces)
 * Code coverage – creating tests to satisfy some criteria of code coverage (e.g., the test designer can create tests to cause all statements in the program to be executed at least once)
 * Fault injection methods – intentionally introducing faults to gauge the efficacy of testing strategies
 * Mutation testing methods
 * Static testing methods

Code coverage tools can evaluate the completeness of a test suite that was created with any method, including black-box testing. This allows the software team to examine parts of a system that are rarely tested and ensures that the most important function points have been tested. Code coverage as a software metric can be reported as a percentage for:

 * Function coverage, which reports on functions executed
 * Statement coverage, which reports on the number of lines executed to complete the test
 * Decision coverage, which reports on whether both the True and the False branch of a given test has been executed

100% statement coverage ensures that all code paths or branches (in terms of control flow) are executed at least once. This is helpful in ensuring correct functionality, but not sufficient since the same code may process different inputs correctly or incorrectly. Pseudo-tested functions and methods are those that are covered but not specified (it is possible to remove their body without breaking any test case).

Black-box testing

Black-box testing (also known as functional testing) treats the software as a "black box," examining functionality without any knowledge of internal implementation, without seeing the source code. The testers are only aware of what the software is supposed to do, not how it does it. Black-box testing methods include: equivalence partitioning, boundary value analysis, all-pairs testing, state transition tables, decision table testing, fuzz testing, model-based testing, use case testing, exploratory testing, and specification-based testing.

Specification-based testing aims to test the functionality of software according to the applicable requirements. This level of testing usually requires thorough test cases to be provided to the tester, who then can simply verify that for a given input, the output value (or behavior), either "is" or "is not" the same as the expected value specified in the test case. Test cases are built around specifications and requirements, i.e., what the application is supposed to do. It uses external descriptions of the software, including specifications, requirements, and designs to derive test cases. These tests can be functional or non-functional, though usually functional.

Specification-based testing may be necessary to assure correct functionality, but it is insufficient to guard against complex or high-risk situations.

One advantage of the black box technique is that no programming knowledge is required. Whatever biases the programmers may have had, the tester likely has a different set and may emphasize different areas of functionality. On the other hand, black-box testing has been said to be "like a walk in a dark labyrinth without a flashlight." Because they do not examine the source code, there are situations when a tester writes many test cases to check something that could have been tested by only one test case or leaves some parts of the program untested.

This method of test can be applied to all levels of software testing: unit, integration, system and acceptance. It typically comprises most if not all testing at higher levels, but can also dominate unit testing as well.

Component interface testing

Component interface testing is a variation of black-box testing, with the focus on the data values beyond just the related actions of a subsystem component. The practice of component interface testing can be used to check the handling of data passed between various units, or subsystem components, beyond full integration testing between those units. The data being passed can be considered as "message packets" and the range or data types can be checked, for data generated from one unit, and tested for validity before being passed into another unit. One option for interface testing is to keep a separate log file of data items being passed, often with a timestamp logged to allow analysis of thousands of cases of data passed between units for days or weeks. Tests can include checking the handling of some extreme data values while other interface variables are passed as normal values. Unusual data values in an interface can help explain unexpected performance in the next unit.

Visual testing
The aim of visual testing is to provide developers with the ability to examine what was happening at the point of software failure by presenting the data in such a way that the developer can easily find the information she or he requires, and the information is expressed clearly.

At the core of visual testing is the idea that showing someone a problem (or a test failure), rather than just describing it, greatly increases clarity and understanding. Visual testing, therefore, requires the recording of the entire test process – capturing everything that occurs on the test system in video format. Output videos are supplemented by real-time tester input via picture-in-a-picture webcam and audio commentary from microphones.

Visual testing provides a number of advantages. The quality of communication is increased drastically because testers can show the problem (and the events leading up to it) to the developer as opposed to just describing it and the need to replicate test failures will cease to exist in many cases. The developer will have all the evidence she or he requires of a test failure and can instead focus on the cause of the fault and how it should be fixed.

Ad hoc testing and exploratory testing are important methodologies for checking software integrity, because they require less preparation time to implement, while the important bugs can be found quickly. In ad hoc testing, where testing takes place in an improvised, impromptu way, the ability of the tester(s) to base testing off documented methods and then improvise variations of those tests can result in more rigorous examination of defect fixes. However, unless strict documentation of the procedures are maintained, one of the limits of ad hoc testing is lack of repeatability.

Grey-box testing
Grey-box testing (American spelling: gray-box testing) involves having knowledge of internal data structures and algorithms for purposes of designing tests while executing those tests at the user, or black-box level. The tester will often have access to both "the source code and the executable binary." Grey-box testing may also include reverse engineering (using dynamic code analysis) to determine, for instance, boundary values or error messages. Manipulating input data and formatting output do not qualify as grey-box, as the input and output are clearly outside of the "black box" that we are calling the system under test. This distinction is particularly important when conducting integration testing between two modules of code written by two different developers, where only the interfaces are exposed for the test.

By knowing the underlying concepts of how the software works, the tester makes better-informed testing choices while testing the software from outside. Typically, a grey-box tester will be permitted to set up an isolated testing environment with activities such as seeding a database. The tester can observe the state of the product being tested after performing certain actions such as executing SQL statements against the database and then executing queries to ensure that the expected changes have been reflected. Grey-box testing implements intelligent test scenarios, based on limited information. This will particularly apply to data type handling, exception handling, and so on.

Testing Levels
There are mainly 4 levels of testing in software testing:

1. Unit Testing - This checks if software components are fulfilling functionalities or not. It's the smallest testable portion of system or application which can be compiled, liked, loaded and executed. This kind of testing helps to test each module separately. The aim is to test each part of the software by separating it. It checks that component are fulfilling functionalities or not. This kind of testing is performed by developers.

2. Integration Testing - This checks the data flow from one module to other modules. Integration means combining. For Example, In this testing phase, different software modules are combined and tested as a group to make sure that integrated system is ready for system testing. Integrating testing checks the data flow from one module to other modules. This kind of testing is performed by testers.

3. System Testing - This evaluates both functional and non-functional needs for the testing. System testing is performed on a complete, integrated system. It allows checking system's compliance as per the requirements. It tests the overall interaction of components. It involves load, performance, reliability and security testing. System testing most often the final test to verify that the system meets the specification. It evaluates both functional and non-functional need for the testing.

4. Acceptance Testing - This checks the requirements of a specification or contract are met as per its delivery. Acceptance testing is a test conducted to find if the requirements of a specification or contract are met as per its delivery. Acceptance testing is basically done by the user or customer. However, other stockholders can be involved in this process.

Testing Techniques and Tactics
There are 5 important software testing techniques and tactics:

1. Boundary Value Analysis (BVA) - It's based on testing at the boundaries between partitions. It includes maximum, minimum, inside or outside boundaries, typical values and error values. It is generally seen that a large number of errors occur at the boundaries of the defined input values rather than the center. It is also known as BVA and gives a selection of test cases which exercise bounding values. This black box testing technique complements equivalence partitioning. This software testing technique base on the principle that, if a system works well for these particular values then it will work perfectly well for all values which comes between the two boundary values

Guidelines for Boundary Value Analysis:
 * If an input condition is restricted between values x and y, then the test cases should be designed with values x and y as well as values which are above and below x and y.
 * If an input condition is a large number of values, the test case should be developed which need to exercise the minimum and maximum numbers. Here, values above and below the minimum and maximum values are also tested.
 * Apply guidelines 1 and 2 to output conditions. It gives an output which reflects the minimum and the maximum values expected. It also tests the below or above values.

2. Equivalence Class Partitioning - This allows you to divide set of test condition into a partition which should be considered the same. This software testing method divides the input domain of a program into classes of data from which test cases should be designed. The concept behind this technique is that test case of a representative value of each class is equal to a test of any other value of the same class. It allows you to Identify valid as well as invalid equivalence classes.

3. Decision Table Based Testing - It's also known as to Cause-Effect table. This software testing technique is used for functions which respond to a combination of inputs or events. For example, a submit button should be enabled if the user has entered all required fields. The first task is to identify functionalities where the output depends on a combination of inputs. If there are large input set of combinations, then divide it into smaller subsets which are helpful for managing a decision table. For every function, you need to create a table and list down all types of combinations of inputs and its respective outputs. This helps to identify a condition that is overlooked by the tester.

Following are steps to create a decision table:
 * Enlist the input in rows.
 * Enter all the rules in the column.
 * Fill the table with the different combination of inputs.
 * In the last row, note down the output against the input combination.

4. State Transition - This technique changes in input conditions change the state of the Application Under Test (AUT). This testing technique allows the tester to test the behavior of an AUT. The tester can perform this action by entering various input conditions in a sequence. In State transition technique, the testing team provides positive as well as negative input test values for evaluating the system behavior.

Guideline for State Transition:
 * State transition should be used when a testing team is testing the application for a limited set of input values.
 * The technique should be used when the testing team wants to test sequence of events which happen in the application under test.

5. Error Guessing - It's a software testing technique based on guessing the error which can prevail in the code. The technique is heavily based on the experience where the test analysts use their experience to guess the problematic part of the testing application. Hence, the test analysts must be skilled and experienced for better error guessing. The technique counts a list of possible errors or error-prone situations. Then tester writes a test case to expose those errors. To design test cases based on this software testing technique, the analyst can use the past experiences to identify the conditions.

Guideline for Error Guessing:
 * The test should use the previous experience of testing similar applications.
 * Understanding of the system under test.
 * Knowledge of typical implementation errors.
 * Remember previously troubled areas.
 * Evaluate Historical data & Test results.

Benefits and Limitations
Here are the benefits or advantages of using unit testing:
 * Validate your work - By writing a test, you double-check what you did. Unit testing finds problems early in the development cycle. This includes both bugs in the programmer's implementation and flaws or missing parts of the specification for the unit. The process of writing a thorough set of tests forces the author to think through inputs, outputs, and error conditions, and thus more crisply define the unit's desired behavior.
 * Separate concerns in your code - Unit testing your code requires you make it testable. Making code testable often means declaring dependencies upfront. This kind of structuring of the code usually leads to a cleaner design and better separation of concerns. With code that is not tested, it's easier to miss implicit dependencies and classes silently taking on multiple responsibilities.
 * An always up-to-date documentation - While documentation will get out of date, unless you update it, tests that run and pass with the code will not get out of date. If you write clean tests, these tests can serve as evergreen documentation for the code. Unit testing provides a sort of living documentation of the system. Developers looking to learn what functionality is provided by a unit, and how to use it, can look at the unit tests to gain a basic understanding of the unit's interface (API).
 * Fewer regressions - Unit tests do a remarkable job of catching regressions as long as they are in the codebase.
 * A safety net for refactoring - While unit tests can catch regressions for small changes, they shine with large refactoring. On codebases with high test coverage and good tests, refactoring is much higher confidence work. Unit testing allows the programmer to refactor code or upgrade system libraries at a later date, and make sure the module still works correctly (e.g., in regression testing). The procedure is to write test cases for all functions and methods so that whenever a change causes a fault, it can be quickly identified. Unit tests detect changes which may break a design contract.

Here are the limitations or disadvantages of using unit testing:
 * With unit testing, you have to increase the amount of code that needs to be written. You usually have to write one or more unit tests depending on how complex things are. It is suggested to have at least three so you don’t just get a yes and a no that contradicts each other. For every line of code written, programmers often need 3 to 5 lines of test code. This obviously takes time and its investment may not be worth the effort. While the test code should be fairly simple, this testing method is still more work and more code which means more hours and more cost.
 * Unit testing cannot and will not catch all errors in a program. There is no way it can test every execution path or find integration errors and full system issues. Unit testing should be done in conjunction with other software testing activities, as they can only show the presence or absence of particular errors; they cannot prove a complete absence of errors. To guarantee correct behavior for every execution path and every possible input, and ensure the absence of errors, other techniques are required, namely the application of formal methods to proving that a software component has no unexpected behavior.
 * Unit tests have to be realistic. You want the unit you’re testing to act as it will as part of the full system. If this doesn’t happen, the test value and accuracy are compromised.

Test-driven Development
Test-Driven Development (TDD) uses tests as a way to design code by creating the test first before any actual production code is written. You then try to make the test pass by creating production code that fulfills the test. This is usually a five-step process:

 * Write a test (some also call this a specification).
 * Run the test and show that it fails. (red)
 * Write the smallest amount of production code possible that meets the needs of the test.
 * Run the test until it passes. (green)
 * Refactor.

This process is sometimes called red-green-refactor. Red symbolizes fail and green represent ''pass. [ ]''

Key Terms
Acceptance Testing - Checks the requirements of a specification or contract are met as per its delivery.

Alpha Testing - Tests performed near the end of development focused on simulating real user experience.

Assertion - A predicate…connected to a point in the program, that always should evaluate to true at that point in code execution.

Beta Testing - Performed by "real users" of the software application in "real environment"

Buddy Testing - Two buddies mutually work on identifying defects in the same module. Mostly one buddy will be from development team and another person will be from testing team. Buddy testing helps the testers develop better test cases and development team can also make design changes early. This testing usually happens after Unit Testing completion

Coverage - A measure used to describe the degree to which the source code of a program is executed when a particular test suite runs.

Integration Testing - Checks the data flow from one module to other modules.

Manual Testing - Type of software testing in which test cases are executed manually by a tester without using any automated tools.

Pytest - A testing framework that allows users to write test codes using Python programming language.

Pytest Coverage - A coverage plugin for PyTest used for measuring code coverage of Python programs.

Refactoring - To restructure existing code.

Regression Testing - Re-running functional and non-functional tests to ensure that previously developed and tested software still performs after a change

System Testing - Evaluates both functional and non-functional needs for the testing.

Unit Testing - Checks if software components are fulfilling functionalities or not.

title: Applied Programming/Testing


text:
Understanding Air Safety in the Jet Age/Metal Fatigue

Without exception modern airliners rely almost exclusively on metal for their structure. All metals suffer from fatigue to some degree. Fatigue occurs when repeated loading leads to progressive structural damage and the growth of cracks. Once a fatigue crack has started, it will grow slightly with each loading cycle. The crack will continue to grow until it reaches a critical size at which point it will grow rapidly and lead to the complete fracture of the structure. Because of the dangers of fatigue, the concept of a failsafe was introduced. A failsafe is a secondary structure that will carry the load if the primary mechanism fails. Unfortunately it is usually weaker than the primary structure and provides only a short window for the failure to be found if disaster is to be avoided.

Accidents involving metal fatigue have been happening since the very first jet airliner took to the sky. They all have at least one of the following characteristics: poor design, flawed maintenance or inadequate repairs. Unfortunately the industry as a whole doesn't seem to have learnt and fatigue induced accidents continue with frightening regularity. Therefore vigilant maintenance is the only solution for an aircraft with a metal structure.

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


text:
Module:Color contrast/doc

This module is used primarily by
 * Color contrast ratio
 * ColorToLum / RGBColorToLum
 * Color contrast conformance
 * Ensure AAA contrast ratio
 * Ensure AA contrast ratio
 * Greater color contrast ratio

It is also used for tracking within
 * Module:Navbox
 * Module:Userbox
 * Module:Episode list

and for documentation in
 * Module:College color

Usage
To use this module, you may use one of the above listed templates or invoke the module directly

To compute relative luminescence
 * or

To compute a contrast ratio between two colors
 * or

To determine which of two colors (color2a and color2b) has the greater contrast ratio with a particular color (color1)
 * or

To compute the contrast ratio between the background and text colors specified in a css style string

title: Module:Color contrast/doc


text:
Module:Color contrast

-- -- This module implements -- --  --  --  -- local p = {} local HTMLcolor = mw.loadData( 'Module:Color contrast/colors' )

local function sRGB (v) if (v <= 0.03928) then v = v / 12.92 else v = math.pow((v+0.055)/1.055, 2.4) end return v end

local function rgbdec2lum(R, G, B)	if ( 0 <= R and R < 256 and 0 <= G and G < 256 and 0 <= B and B < 256 ) then return 0.2126 * sRGB(R/255) + 0.7152 * sRGB(G/255) + 0.0722 * sRGB(B/255) else return '' end end

local function hsl2lum(h, s, l)	if ( 0 <= h and h < 360 and 0 <= s and s <= 1 and 0 <= l and l <= 1 ) then local c = (1 - math.abs(2*l - 1))*s local x = c*(1 - math.abs( math.fmod(h/60, 2) - 1) ) local m = l - c/2

local r, g, b = m, m, m		if( 0 <= h and h < 60 ) then r = r + c			g = g + x		elseif( 60 <= h and h < 120 ) then r = r + x			g = g + c		elseif( 120 <= h and h < 180 ) then g = g + c			b = b + x		elseif( 180 <= h and h < 240 ) then g = g + x			b = b + c		elseif( 240 <= h and h < 300 ) then r = r + x			b = b + c		elseif( 300 <= h and h < 360 ) then r = r + c			b = b + x		end return rgbdec2lum(255*r, 255*g, 255*b) else return '' end end

local function color2lum(c)

if (c == nil) then return '' end

-- html '#' entity c = c:gsub("#", "#")

-- whitespace c = c:match( '^%s*(.-)[%s;]*$' )

-- unstrip nowiki strip markers c = mw.text.unstripNoWiki(c)

-- lowercase c = c:lower

-- first try to look it up	local L = HTMLcolor[c] if (L ~= nil) then return L	end

-- convert from hsl if mw.ustring.match(c,'^hsl%([%s]*[0-9][0-9%.]*[%s]*,[%s]*[0-9][0-9%.]*%%[%s]*,[%s]*[0-9][0-9%.]*%%[%s]*%)$') then local h, s, l = mw.ustring.match(c,'^hsl%([%s]*([0-9][0-9%.]*)[%s]*,[%s]*([0-9][0-9%.]*)%%[%s]*,[%s]*([0-9][0-9%.]*)%%[%s]*%)$') return hsl2lum(tonumber(h), tonumber(s)/100, tonumber(l)/100) end

-- convert from rgb if mw.ustring.match(c,'^rgb%([%s]*[0-9][0-9]*[%s]*,[%s]*[0-9][0-9]*[%s]*,[%s]*[0-9][0-9]*[%s]*%)$') then local R, G, B = mw.ustring.match(c,'^rgb%([%s]*([0-9][0-9]*)[%s]*,[%s]*([0-9][0-9]*)[%s]*,[%s]*([0-9][0-9]*)[%s]*%)$') return rgbdec2lum(tonumber(R), tonumber(G), tonumber(B)) end

-- convert from rgb percent if mw.ustring.match(c,'^rgb%([%s]*[0-9][0-9%.]*%%[%s]*,[%s]*[0-9][0-9%.]*%%[%s]*,[%s]*[0-9][0-9%.]*%%[%s]*%)$') then local R, G, B = mw.ustring.match(c,'^rgb%([%s]*([0-9][0-9%.]*)%%[%s]*,[%s]*([0-9][0-9%.]*)%%[%s]*,[%s]*([0-9][0-9%.]*)%%[%s]*%)$') return rgbdec2lum(255*tonumber(R)/100, 255*tonumber(G)/100, 255*tonumber(B)/100) end

-- remove leading # (if there is one) and whitespace c = mw.ustring.match(c, '^[%s#]*([a-f0-9]*)[%s]*$')

-- split into rgb local cs = mw.text.split(c or , ) if( #cs == 6 ) then local R = 16*tonumber('0x' .. cs[1]) + tonumber('0x' .. cs[2]) local G = 16*tonumber('0x' .. cs[3]) + tonumber('0x' .. cs[4]) local B = 16*tonumber('0x' .. cs[5]) + tonumber('0x' .. cs[6])

return rgbdec2lum(R, G, B)	elseif ( #cs == 3 ) then local R = 16*tonumber('0x' .. cs[1]) + tonumber('0x' .. cs[1]) local G = 16*tonumber('0x' .. cs[2]) + tonumber('0x' .. cs[2]) local B = 16*tonumber('0x' .. cs[3]) + tonumber('0x' .. cs[3])

return rgbdec2lum(R, G, B)	end

-- failure, return blank return '' end

-- This exports the function for use in other modules. -- The colour is passed as a string. function p._lum(color) return color2lum(color) end

function p._greatercontrast(args) local bias = tonumber(args['bias'] or '0') or 0 local css = (args['css'] and args['css'] ~= '') and true or false local v1 = color2lum(args[1] or '') local c2 = args[2] or '#FFFFFF' local v2 = color2lum(c2) local c3 = args[3] or '#000000' local v3 = color2lum(c3) local ratio1 = -1; local ratio2 = -1; if (type(v1) == 'number' and type(v2) == 'number') then ratio1 = (v2 + 0.05)/(v1 + 0.05) ratio1 = (ratio1 < 1) and 1/ratio1 or ratio1 end if (type(v1) == 'number' and type(v3) == 'number') then ratio2 = (v3 + 0.05)/(v1 + 0.05) ratio2 = (ratio2 < 1) and 1/ratio2 or ratio2 end

if css then local c1 = args[1] or '' if mw.ustring.match(c1, '^[A-Fa-f0-9][A-Fa-f0-9][A-Fa-f0-9]$') or			mw.ustring.match(c1, '^[A-Fa-f0-9][A-Fa-f0-9][A-Fa-f0-9][A-Fa-f0-9][A-Fa-f0-9][A-Fa-f0-9]$') then c1 = '#' .. c1		end if mw.ustring.match(c2, '^[A-Fa-f0-9][A-Fa-f0-9][A-Fa-f0-9]$') or			mw.ustring.match(c2, '^[A-Fa-f0-9][A-Fa-f0-9][A-Fa-f0-9][A-Fa-f0-9][A-Fa-f0-9][A-Fa-f0-9]$') then c2 = '#' .. c2		end if mw.ustring.match(v3, '^[A-Fa-f0-9][A-Fa-f0-9][A-Fa-f0-9]$') or			mw.ustring.match(v3, '^[A-Fa-f0-9][A-Fa-f0-9][A-Fa-f0-9][A-Fa-f0-9][A-Fa-f0-9][A-Fa-f0-9]$') then c3 = '#' .. c3		end return 'background-color:' .. c1 .. '; color:' .. ((ratio1 > 0) and (ratio2 > 0) and ((ratio1 + bias > ratio2) and c2 or c3) or '') .. ';'	end

return (ratio1 > 0) and (ratio2 > 0) and ((ratio1 + bias > ratio2) and c2 or c3) or '' end

function p._ratio(args) local v1 = color2lum(args[1]) local v2 = color2lum(args[2]) if (type(v1) == 'number' and type(v2) == 'number') then -- v1 should be the brighter of the two. if v2 > v1 then v1, v2 = v2, v1		end return (v1 + 0.05)/(v2 + 0.05) else return args['error'] or '?' end end

function p._styleratio(args) local style = (args[1] or ''):lower local bg, fg = 'white', 'black' local lum_bg, lum_fg = 1, 0

if args[2] then local lum = color2lum(args[2]) if lum ~= '' then bg, lum_bg = args[2], lum end end if args[3] then local lum = color2lum(args[3]) if lum ~= '' then fg, lum_fg = args[3], lum end end

local slist = mw.text.split(mw.ustring.gsub(mw.ustring.gsub(style or '', '&#[Xx]23;', '#'), '#', '#'), ';') for k = 1,#slist do		local s = slist[k] local k,v = s:match( '^[%s]*([^:]-):([^:]-)[%s;]*$' ) k = k or '' v = v or '' if (k:match('^[%s]*(background)[%s]*$') or k:match('^[%s]*(background%-color)[%s]*$')) then local lum = color2lum(v) if( lum ~= '' ) then bg, lum_bg = v, lum end elseif (k:match('^[%s]*(color)[%s]*$')) then local lum = color2lum(v) if( lum ~= '' ) then bg, lum_fg = v, lum end end end if lum_bg > lum_fg then return (lum_bg + 0.05)/(lum_fg + 0.05) else return (lum_fg + 0.05)/(lum_bg + 0.05) end end

--[[ Use directly or from a wrapper template.

Parameters: -- |1=	— required; A color to check. --]] function p.lum(frame) local color = frame.args[1] or frame:getParent.args[1] return p._lum(color) end

function p.ratio(frame) local args = frame.args[1] and frame.args or frame:getParent.args return p._ratio(args) end

function p.styleratio(frame) local args = frame.args[1] and frame.args or frame:getParent.args return p._styleratio(args) end

function p.greatercontrast(frame) local args = frame.args[1] and frame.args or frame:getParent.args return p._greatercontrast(args) end

return p

title: Module:Color contrast


text:
Module:BaseConvert

local p = {}

local digits = '0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ'

function normalizeFullWidthChars(s) return mw.ustring.gsub(s, '[！-～]', function(s)        return mw.ustring.char(mw.ustring.codepoint(s, 1) - 0xFEE0)     end) end

function _convert(n, base, from, precision, width, default, prefix, suffix) n = '' .. n  -- convert to a string -- strip off any leading '0x' (unless x is a valid digit in the input base) from = tonumber(from) if not from or from < 34 then local c       n, c = n:gsub('^(-?)0[Xx]', '%1') if c > 0 and not from then from = 16 end end

-- check for a negative sign. Do this while the input is still in string form, -- because tonumber doesn't support negative numbers in non-10 bases. local sign = '' local c   n, c = n:gsub('^-', '') if c > 0 then sign = '-' end -- replace any full-width Unicode characters in the string with their ASCII equivalents n = normalizeFullWidthChars(n) -- handle scientific notation with whitespace around the 'e' e.g. '5 e7' n = n:gsub('%s*[eE]%s*', 'e') from = from or 10 local num = tonumber(n, from) base = tonumber(base) precision = tonumber(precision) width = tonumber(width) if not num or not base then return default or n end local i, f = math.modf(num)

local t = {} repeat local d = (i % base) + 1 i = math.floor(i / base) table.insert(t, 1, digits:sub(d, d)) until i == 0 while #t < (width or 0) do       table.insert(t, 1, '0') end local intPart = table.concat(t, '') -- compute the fractional part local tf = {} while f > 0 and #tf < (precision or 10) do       f = f * base i, f = math.modf(f) table.insert(tf, digits:sub(i + 1, i + 1)) end -- add trailing zeros if needed if precision and #tf < precision then for i = 1, precision - #tf do           table.insert(tf, '0') end end

fracPart = table.concat(tf, '') -- remove trailing zeros if not needed if not precision then fracPart = fracPart:gsub('0*$', '') end -- add the radix point if needed if #fracPart > 0 then fracPart = '.' .. fracPart end return (prefix or '') .. sign .. intPart .. fracPart .. (suffix or '') end

function p.convert(frame) -- Allow for invocation via #invoke or directly from another module local args if frame == mw.getCurrentFrame then args = frame.args else args = frame end local n = args.n   local base = args.base local from = args.from local precision = args.precision local width = args.width local default = args.default local prefix = args.prefix local suffix = args.suffix return _convert(n, base, from, precision, width, default, prefix, suffix) end

return p

title: Module:BaseConvert


text:
Module:BaseConvert/doc

Converts numbers to a specified base between 2 and 36, for use in templates such as binary, octal, hexadecimal, etc.

Example usage:

Arguments:
 * n - (required) the number to be converted, as a string. It may be a number instead, if the input base is 10.
 * base - (required) the base to which the number should be converted. May be between 2 and 36, inclusive.
 * from - the base of the input. Defaults to 10 (or 16 if the input has a leading '0x'). Note that bases other than 10 are not supported if the input has a fractional part.
 * precision - number of digits to be rendered after the radix point. Trailing zeros will be added if needed. If not specified, however many digits are needed will be shown, up to 10.
 * width - minimum number of digits to be rendered before the radix point. Leading zeros will be added if needed.
 * default - Value to return if n is empty or non-numeric. Defaults to the value of n.
 * prefix / suffix - wikitext to add before/after the returned result. Will not be added if n is empty or non-numeric. For example, you might use a prefix of  when converting to hex, or a suffix of   when converting to octal.

title: Module:BaseConvert/doc


text:
Module:Color contrast/colors

return { aliceblue           = 0.92880068253475, antiquewhite        = 0.84646951707754, aqua                = 0.7874, aquamarine          = 0.8078549208338, azure               = 0.97265264954166, beige               = 0.8988459998705, bisque              = 0.80732327372979, black               = 0, blanchedalmond      = 0.85084439608156, blue                = 0.0722, blueviolet          = 0.12622014321946, brown               = 0.098224287876511, burlywood           = 0.51559844533893, cadetblue           = 0.29424681085422, chartreuse          = 0.76032025902623, chocolate           = 0.23898526114557, coral               = 0.37017930872924, cornflowerblue      = 0.30318641994179, cornsilk            = 0.93562110372965, crimson             = 0.16042199953026, cyan                = 0.7874, darkblue            = 0.018640801980939, darkcyan            = 0.20329317839046, darkgoldenrod       = 0.27264703559993, darkgray            = 0.39675523072563, darkgreen           = 0.091143429047575, darkgrey            = 0.39675523072563, darkkhaki           = 0.45747326349994, darkmagenta         = 0.07353047651207, darkolivegreen      = 0.12651920884889, darkorange          = 0.40016167026524, darkorchid          = 0.13413142174857, darkred             = 0.054889674531132, darksalmon          = 0.40541471563381, darkseagreen        = 0.43789249325969, darkslateblue       = 0.065792846227988, darkslategray       = 0.067608151928044, darkslategrey       = 0.067608151928044, darkturquoise       = 0.4874606277449, darkviolet          = 0.10999048339343, deeppink            = 0.23866895828276, deepskyblue         = 0.44481603395575, dimgray             = 0.14126329114027, dimgrey             = 0.14126329114027, dodgerblue          = 0.27442536991456, firebrick           = 0.10724525535015, floralwhite         = 0.95922484825004, forestgreen         = 0.18920812076002, fuchsia             = 0.2848, gainsboro           = 0.71569350050648, ghostwhite          = 0.94311261886323, gold                = 0.69860877428159, goldenrod           = 0.41919977809569, gray                = 0.2158605001139, green               = 0.15438342968146, greenyellow         = 0.80609472611453, grey                = 0.2158605001139, honeydew            = 0.96336535554782, hotpink             = 0.34658438169715, indianred           = 0.21406134963884, indigo              = 0.03107561486337, ivory               = 0.99071270600615, khaki               = 0.77012343394121, lavender            = 0.80318750514521, lavenderblush       = 0.90172748631046, lawngreen           = 0.73905893124963, lemonchiffon        = 0.94038992245622, lightblue           = 0.63709141280807, lightcoral          = 0.35522120733135, lightcyan           = 0.94587293494829, lightgoldenrodyellow = 0.93348351018297, lightgray           = 0.65140563741982, lightgreen          = 0.69091979956865, lightgrey           = 0.65140563741982, lightpink           = 0.58566152734898, lightsalmon         = 0.4780675225206, lightseagreen       = 0.35050145117042, lightskyblue        = 0.56195637618331, lightslategray      = 0.23830165007287, lightslategrey      = 0.23830165007287, lightsteelblue      = 0.53983888284666, lightyellow         = 0.98161818392882, lime                = 0.7152, limegreen           = 0.44571042246098, linen               = 0.88357340984379, magenta             = 0.2848, maroon              = 0.045891942324215, mediumaquamarine    = 0.49389703310801, mediumblue          = 0.044077780212328, mediumorchid        = 0.21639251153773, mediumpurple        = 0.22905858091648, mediumseagreen      = 0.34393112338131, mediumslateblue     = 0.20284629471622, mediumspringgreen   = 0.70704308194184, mediumturquoise     = 0.5133827926448, mediumvioletred     = 0.14371899849357, midnightblue        = 0.02071786635086, mintcream           = 0.97834604947588, mistyrose           = 0.82183047859185, moccasin            = 0.80083000991567, navajowhite         = 0.76519682342785, navy                = 0.015585128108224, oldlace             = 0.91900633405549, olive               = 0.20027537200568, olivedrab           = 0.22593150951929, orange              = 0.4817026703631, orangered           = 0.25516243753416, orchid              = 0.31348806761439, palegoldenrod       = 0.78792647887614, palegreen           = 0.77936759006353, paleturquoise       = 0.76436077921714, palevioletred       = 0.28754994117889, papayawhip          = 0.87797100199835, peachpuff           = 0.74905589878251, peru                = 0.30113074877936, pink                = 0.63271070702466, plum                = 0.45734221587969, powderblue          = 0.68254586500605, purple              = 0.061477070432439, rebeccapurple       = 0.07492341159447, red                 = 0.2126, rosybrown           = 0.32319457649407, royalblue           = 0.16663210743188, saddlebrown         = 0.097922285020521, salmon              = 0.36977241527596, sandybrown          = 0.46628543696283, seagreen            = 0.19734199706275, seashell            = 0.92737862206922, sienna              = 0.13697631337098, silver              = 0.52711512570581, skyblue             = 0.55291668518184, slateblue           = 0.14784278062136, slategray           = 0.20896704076536, slategrey           = 0.20896704076536, snow                = 0.96533341834849, springgreen         = 0.73052306068529, steelblue           = 0.20562642207625, tan                 = 0.48237604163921, teal                = 0.16996855778968, thistle             = 0.56818401093733, tomato              = 0.30638612719415, turquoise           = 0.5895536427578, violet              = 0.40315452986676, wheat               = 0.74909702820482, white               = 1, whitesmoke          = 0.91309865179342, yellow              = 0.9278, yellowgreen         = 0.50762957208707, }

title: Module:Color contrast/colors


text:
Module:Color contrast/colors/doc

This module contains the relative luminance of HTML colors. It is used in Module:Color contrast.

title: Module:Color contrast/colors/doc


text:
Module:InfoboxImage

-- Inputs: --   image - Can either be a bare filename (with or without the File:/Image: prefix) or a fully formatted image link --   page - page to display for multipage images (DjVu) --   size - size to display the image --   maxsize - maximum size for image --   sizedefault - default size to display the image if size param is blank --   alt - alt text for image --   title - title text for image --   border - set to yes if border --   center - set to yes, if the image has to be centered --   upright - upright image param --   suppressplaceholder - if yes then checks to see if image is a placeholder and suppresses it --    link - page to visit when clicking on image -- Outputs: --   Formatted image. -- More details available at the "Module:InfoboxImage/doc" page

local i = {};

local placeholder_image = { "Blue - Replace this image female.svg", "Blue - Replace this image male.svg", "Female no free image yet.png", "Flag of None (square).svg", "Flag of None.svg", "Flag of.svg", "Green - Replace this image female.svg", "Green - Replace this image male.svg", "Image is needed female.svg", "Image is needed male.svg", "Location map of None.svg", "Male no free image yet.png", "Missing flag.png", "No flag.svg", "No free portrait.svg", "No portrait (female).svg", "No portrait (male).svg", "Red - Replace this image female.svg", "Red - Replace this image male.svg", "Replace this image female (blue).svg", "Replace this image female.svg", "Replace this image male (blue).svg", "Replace this image male.svg", "Silver - Replace this image female.svg", "Silver - Replace this image male.svg", "Replace this image.svg", "Cricket no pic.png", "CarersLogo.gif", "Diagram Needed.svg", "Example.jpg", "Image placeholder.png", "No male portrait.svg", "Nocover-upload.png", "NoDVDcover copy.png", "Noribbon.svg", "No portrait-BFD-test.svg", "Placeholder barnstar ribbon.png", "Project Trains no image.png", "Image-request.png", "Sin bandera.svg", "Sin escudo.svg", "Replace this image - temple.png", "Replace this image butterfly.png", "Replace this image.svg", "Replace this image1.svg", "Resolution angle.png", "Image-No portrait-text-BFD-test.svg", "Insert image here.svg", "No image available.png", "NO IMAGE YET square.png", "NO IMAGE YET.png", "No Photo Available.svg", "No Screenshot.svg", "No-image-available.jpg", "Null.png", "PictureNeeded.gif", "Place holder.jpg", "Unbenannt.JPG", "UploadACopyrightFreeImage.svg", "UploadAnImage.gif", "UploadAnImage.svg", "UploadAnImageShort.svg", "CarersLogo.gif", "Diagram Needed.svg", "No male portrait.svg", "NoDVDcover copy.png", "Placeholder barnstar ribbon.png", "Project Trains no image.png", "Image-request.png", "Noimage.gif", }

function i.IsPlaceholder(image) -- change underscores to spaces image = mw.ustring.gsub(image, "_", " "); assert(image ~= nil, 'mw.ustring.gsub(image, "_", " ") must not return nil') -- if image starts with [[ then remove that and anything after |   if mw.ustring.sub(image,1,2) == "[[" then        image = mw.ustring.sub(image,3);        image = mw.ustring.gsub(image, "([^|]*)|.*", "%1");        assert(image ~= nil, 'mw.ustring.gsub(image, "([^|]*)|.*", "%1") must not return nil')    end    -- Trim spaces    image = mw.ustring.gsub(image, '^[ ]*(.-)[ ]*$', '%1');    assert(image ~= nil, "mw.ustring.gsub(image, '^[ ]*(.-)[ ]*$', '%1') must not return nil")    -- remove prefix if exists    local allNames = mw.site.namespaces[6].aliases    allNames[#allNames + 1] = mw.site.namespaces[6].name    allNames[#allNames + 1] = mw.site.namespaces[6].canonicalName    for i, name in ipairs(allNames) do        if mw.ustring.lower(mw.ustring.sub(image, 1, mw.ustring.len(name) + 1)) == mw.ustring.lower(name .. ":") then            image = mw.ustring.sub(image, mw.ustring.len(name) + 2);            break        end    end    -- Trim spaces    image = mw.ustring.gsub(image, '^[ ]*(.-)[ ]*$', '%1');    -- capitalise first letter    image = mw.ustring.upper(mw.ustring.sub(image,1,1)) .. mw.ustring.sub(image,2);

for i,j in pairs(placeholder_image) do       if image == j then return true end end return false end

function i.InfoboxImage(frame) local image = frame.args["image"]; if image == "" or image == nil then return ""; end if image == " " then return image; end if frame.args["suppressplaceholder"] ~= "no" then if i.IsPlaceholder(image) == true then return ""; end end

if mw.ustring.lower(mw.ustring.sub(image,1,5)) == "http:" then return ""; end if mw.ustring.lower(mw.ustring.sub(image,1,6)) == "[http:" then return ""; end if mw.ustring.lower(mw.ustring.sub(image,1,7)) == "[[http:" then       return "";    end    if mw.ustring.lower(mw.ustring.sub(image,1,6)) == "https:" then        return "";    end    if mw.ustring.lower(mw.ustring.sub(image,1,7)) == "[https:" then        return "";    end    if mw.ustring.lower(mw.ustring.sub(image,1,8)) == "[[https:" then        return "";    end

if mw.ustring.sub(image,1,2) == "%s*thumb%s*[|%") or mw.ustring.find(image, "|%s*thumbnail%s*[|%]]")) then cat = ""; end return image .. cat; elseif mw.ustring.sub(image,1,2) == "{{" and mw.ustring.sub(image,1,3) ~= "{{{" then return image; elseif mw.ustring.sub(image,1,1) == "<" then return image; elseif mw.ustring.sub(image,1,5) == mw.ustring.char(127).."UNIQ" then -- Found strip marker at begining, so pass don't process at all return image; elseif mw.ustring.sub(image,4,9) == "`UNIQ-" then -- Found strip marker at begining, so pass don't process at all return image; else local result = ""; local page = frame.args["page"]; local size = frame.args["size"]; local maxsize = frame.args["maxsize"]; local sizedefault = frame.args["sizedefault"]; local alt = frame.args["alt"]; local link = frame.args["link"]; local title = frame.args["title"]; local border = frame.args["border"]; local upright = frame.args["upright"] or ""; local thumbtime = frame.args["thumbtime"] or ""; local center= frame.args["center"]; -- remove prefix if exists local allNames = mw.site.namespaces[6].aliases allNames[#allNames + 1] = mw.site.namespaces[6].name allNames[#allNames + 1] = mw.site.namespaces[6].canonicalName for i, name in ipairs(allNames) do           if mw.ustring.lower(mw.ustring.sub(image, 1, mw.ustring.len(name) + 1)) == mw.ustring.lower(name .. ":") then image = mw.ustring.sub(image, mw.ustring.len(name) + 2); break end end if maxsize ~= "" and maxsize ~= nil then -- if no sizedefault then set to maxsize if sizedefault == "" or sizedefault == nil then sizedefault = maxsize end -- check to see if size bigger than maxsize if size ~= "" and size ~= nil then local sizenumber = tonumber(mw.ustring.match(size,"%d*")) or 0; local maxsizenumber = tonumber(mw.ustring.match(maxsize,"%d*")) or 0; if sizenumber>maxsizenumber and maxsizenumber>0 then size = maxsize; end end end -- add px to size if just a number if (tonumber(size) or 0) > 0 then size = size .. "px"; end -- add px to sizedefault if just a number if (tonumber(sizedefault) or 0) > 0 then sizedefault = sizedefault .. "px"; end result = "[[File:" .. image;       if page ~= "" and page ~= nil then            result = result .. "|page=" .. page;        end        if size ~= "" and size ~= nil then            result = result .. "|" .. size;        elseif sizedefault ~= "" and sizedefault ~= nil then            result = result .. "|" .. sizedefault;        else            result = result .. "|frameless";        end        if center == "yes" then            result = result .. "|center"        end        if alt ~= "" and alt ~= nil then            result = result .. "|alt=" .. alt;        end        if link ~= "" and link ~= nil then            result = result .. "|link=" .. link;        end        if border == "yes" then            result = result .. "|border";        end        if upright == "yes" then            result = result .. "|upright";        elseif upright ~= "" then            result = result .. "|upright=" .. upright;        end        if thumbtime ~= "" then            result = result .. "|thumbtime=" .. thumbtime;        end        if title ~= "" and title ~= nil then            result = result .. "|" .. title;        elseif alt ~= "" and alt ~= nil then            result = result .. "|" .. alt;        end        result = result .. "]]"; return result; end end

return i;

title: Module:InfoboxImage


text:
Module:InfoboxImage/doc

Overview
This module is used within infoboxes to process the image parameters and tidy up the formatting of the result.

Parameters
Note: If you specify the maxsize or sizedefault params, then you should include the px after the number.

Parameters displayed in image syntax
All parameters:
 *

When "size" and "maxsize" are defined, the smaller of the two is used (if "px" is omitted it will be added by the module):
 *

When "size" is not defined, "sizedefault" is used, even if larger than "maxsize" (in actual use "px" is required after the number; omitted here to show it is not added by the module):
 *

When "size" and "sizedefault" are not defined, "maxsize" is used (in actual use "px" is required after the number; omitted here to show it is not added by the module):
 *

When "size", "sizedefault", and "maxsize" are not defined, "frameless" is added, which displays the image at the default thumbnail size (220px, but logged in users can change this at Special:Preferences) and is required if using "upright" to scale the default size:
 *

Use of "upright" without a number value, which displays the image at approximately 75% of the user's default size (multiplied by 0.75 then rounded to nearest 10):
 *

When "alt" is used without "title", the alt text is also used as the title:
 *

For more information, see Extended image syntax.

Sample usage

 * image =

title: Module:InfoboxImage/doc


text:
Template:Infobox color/doc

Blank template

Parameters
The following template parameters are supported:

Color/Colour spelling
For articles standardised to British spelling, add the parameter. The word "colour" is case-insensitive.

CMYK values
Note that CMYK values are not included by default as there is no single way to obtain a CMYK quartet from an RGB triplet. Variations in paper and ink processes account for the various combinations of non-invertible matrices and look-up tables used in converting from RGB to CMYK. If you wish to obtain CMYK values for these colors, you will get appropriate conversion values from your graphics application when you define the type of ink and paper you will be printing on.

title: Template:Infobox color/doc


text: Template:ColorToLum

title: Template:ColorToLum


text:
Template:ColorToLum/doc

Converts most legal web colors to a W3C relative luminance value. The color may be specified as either by HTML color name or by HSL or by RGB or by Hex value.

Examples

 * →
 * →
 * →
 * →
 * →

title: Template:ColorToLum/doc


text:
Template:Greater color contrast ratio/doc

This template determines the pair of colors with the larger contrast ratio: color1/color2 or color1/color3. This is useful for selecting a foreground/background color pair. For accessibility, WCAG 2.0 AA guidelines require a contrast ratio of 3 or larger for large text, and 4.5 or larger for normal sized text. When used in the default mode, with color2 and color3 equal to white and black, the selected color pair will always have a contrast ratio greater than 4.58.

Examples

 * → Navy
 * → Navy
 * → Navy
 * → Red
 * → Red
 * → Red
 * → White
 * → White
 * → Black
 * → Black
 * → #005500
 * → #005500
 * → 005500
 * → 005500
 * → CC5500
 * → CC5500
 * → CC5500
 * → CC5500
 * → Not a color
 * → Not a color

Optional parameters
The  parameter should be used with caution to ensure accessibility. As stated above, when used without a bias, and with color2 and color3 equal to white and black, the selected color pair will always have a contrast ratio greater than 4.58. A bias of 1.25, reduces the possible minimum to 4.0, which may not meet accessibility standards.


text:
German/Grammar/Intransitive verbs

Intransitive verbs
Now that we have something for the verbs to talk about, we can introduce verbs. This will allow us to produce the simplest form of a sentence, namely a pronoun (person or thing) + a verb (what the person or thing is doing).

Terminology
The first thing to note is that verbs are more highly inflected in German than in English, meaning that you must modify the ending of the verb according to how it is used. Recall that for verbs, it's customary to say that it must be conjugated, while for other types of words you would say declined. This exists in English but in a very reduced form compared to German, for example we say "He talks" but "They talk", with the added "-s" being the way you conjugate "talk" in English. The factors which affect how a verb is conjugated include tense, mood, person and number. Again, to avoid information overload we will only cover the present tense and indicative mood and leave the others for later sections. So we will be taking about declarative statements of things that are going on at the present time. We've already covered the remaining factors, person and number, in the previous section; note that gender does not affect verb conjugation in German. Verbs are not affected by case, but perhaps it would be more accurate to say the verb determines the case of other words.

Conjugating a verb
We'll start with a relatively simple verb, spielen, "to play". (German dictionaries list verbs in this -en, or infinitive form; the use of the infinitive in actual sentences will be discussed elsewhere.) It is intransitive, meaning it only requires a subject (the thing the verb is talking about) to function. For the subject, we can use (but are by no means limited to) the personal pronouns from the previous section. In German, the verb comes second in a simple statement, which means the subject must go first in a subject + verb sentence.

To conjugate a verb, you must remove the -en ending of the verb to form what is called the stem, and attach the appropriate conjugated ending according to the person and number of the subject. The following table shows which ending to add:

To see how this works, we'll combine this table of endings with the table of pronouns in the previous section to make simple sentences with spielen.

Note that, although the third person sie (meaning "she") and sie (meaning "they") are the same in German, you can tell them apart with the verb ending. Also note that the translations "He/She/It plays" are only meant meant to be guide; in reality, as seen in the previous section, there is no way to reliably translate *er/sie/es" to "he/she/it" without context. Finally, note that in some cases the ending is -en, the same ending as the infinitive. This should be seen as a coincidence; even though they appear and sound the same, so the spielen in wir spielen should be regarded as different than the infinitive spielen.

Variations
In some cases, strictly following the table above would result in combinations that would be difficult to pronounce, so an extra -e- is added to make the word flow over the tongue. Specifically, if the stem ends with -d-, -t-, -m- or -n-, then an -e- is added if there isn't already one in the ending. For example with the verb reden ― "to talk", you would say Du redest, Ihr redet, or Er/Sie/Es redet. This rule is easy to remember since it's based purely on making the words easier to say. Similarly, if the stem ends in an s sound, so with -s-, -ss-, -ß-, or -z- then the -s- in the -st ending is redundant and dropped. So for sitzen - "to sit" you would say Du Sitzt.

For a few verbs the infinitive ends in -rn or -ln instead of -en; in this case you just remove the '-n' to get the stem. The -e- that would normally be included in some endings is dropped for consistency, except for the first person singular (ich) where the ending remains -e. For example, for the verb wandern - "to hike", you would say Ich wandere, Wir wandern, or Du wanderst. Again, once you get used to the sound of German in general, this rule isn't too hard to remember because the extra -e- just sounds unnecessary.

Present tense in German
Since we're using the present tense in this section, it may be a good time to mention the differences between the present tense in German and the present tense in English. As with English, if you're talking about something that's occurring now then you use the present tense in German. This includes the case where the action has been going on for a while and continues to happen, in which case English would use a past tense. Similarly, for events that are about to happen, and when a specific time frame is mentioned, German prefers the present tense while English has the option to use the future tense.
 * Wir reden. ― "We're talking." (Present tense in both German and English.)
 * Wir reden seit zwei Stunden. ― "We've been talking for two hours." (Present tense in German and past tense English.)
 * Wir reden morgen. ― "We'll talk tomorrow." (Present tense in German, future tense in English.)

Another difference is that while English has three ways to express that something is happening in the present, for example "We talk", "We're talking", and "We do talk", in German there is only one method, Wir reden. This can present a challenge when translating German to English because the German sentence may in interpreted in different ways to get different possible versions in English; hopefully context will provide enough information to decide which alternative is the best fit.

Some common intransitive verbs
Here are some common intransitive verbs to practice conjugating. Irregular verbs are not included since they will be covered elsewhere. Some of these may have meanings that are not intransitive.
 * arbeiten ― "to work"
 * kochen ― "to cook"
 * leben ― "to live"
 * spielen ― "to play"
 * reden ― "to talk"

title: German/Grammar/Intransitive verbs


text:
Talk:Small and Medium Enterprises and ICT/SME Adoption of ICT

Yes I am Smile on


text:
User talk:Semi-Brace

Welcome
Was just going to leave a note remarking on a technical detail, but then noticed you hadn't been welcomed properly; wouldn't want to come across as unfriendly; so... Welcome to Wikibooks, Semi-Brace!

 First steps tutorial Wikibooks is for collaborative development of free textbooks.

You do not need technical skills to contribute. You can easily change most books. Please introduce yourself, and let us know what interests you.

If you already contribute at other Wikimedia projects, our Wikimedia Orientation should quickly get you started. (Would you like to provide feedback on this message?)

  Getting help   Made a mistake?   Goodies, tips and tricks
 * Read the Using Wikibooks book for a friendly introduction to the project, or our help pages for more information.
 * You can get friendly help from the community in the user assistance room or our IRC channel.
 * Upload freely licensed files to Wikimedia Commons. You may request permission to upload fair use files locally. Please include author and source information and a non-free use rationale for non-free files.
 * You can restore a previously saved version.
 * Pages should follow the  naming convention.
 * Need to rename a page? Use the move tab (is available once your account is 4 days old - until then, ask for help).
 * To request a page be deleted, add to the top of the page.
 * Was a page you made deleted? Please read the deletion policy, and check the deletion log to find out why. Also check the RFD archives if applicable. You can request undeletion at WB:RFU, or ask the administrator who deleted the page.
 * Please fill in the edit summary and preview your edits before saving.
 * Sign your name on discussion pages by typing ~~~~
 * User scripts can make many tasks easier. Look at the Gadgets tab of my preferences; check off the boxes for the scripts you want, and hit save!

--Pi zero (discuss • contribs) 22:04, 16 February 2021 (UTC)

Interwikis
The technical detail I was going to remark on: en.wb doesn't remove iw's when the information is also available on Wikidata (though we do reconcile the two when possible, whether than means changing our local iw's or Wikidata's). Fwiw. --Pi zero (discuss • contribs) 22:07, 16 February 2021 (UTC)

title: User talk:Semi-Brace


text:
Talk:Women's Writing Before Woolf: A Social Reference

This is a placeholder page for a class project that will be launching on Monday, 22 February 2021. I will rename it and flesh out the TOC before that time.04:24, 17 February 2021 (UTC)


text:
History of video games/Understanding Historical Technology

When studying the history of video games, it is very helpful to have an understanding of historical technology. This chapter intends to catch up readers on relevant developments which were influential in the development gaming technology. Readers with a background in such history may consider reading ahead.

Prior Developments
A number of prior developments would prove influential on the development of video games. This section covers those technologies that either paved the way for game systems, or showed how earlier people perceived automated entertainment - the socio-technological bedrock of the gaming industry.

At the same time, many technologies involved in gaming are much older than one might expect. It's important to note that none of the developments in this section are directly video games themselves, and many of these developments remained unavailable to the common person until the development of mass production.

Prehistory
The use of moving pictures as a form of artwork may date back to the stone age.

Antiquity
People have desired autonomous entertainment since ancient times. This is evidenced by the Ancient Greeks, who are said to have built a theater of automatons in Alexandria. Early concepts of simulated realities can also be seen in Plato's Allegory of the Cave. In particular, Hero of Alexandria describes automated theater systems in Automatopoietica, including moving not only automaton actors in 3D space, but also tricks that would later be used by 3D games, such as using 2D graphics convincingly in a 3D space. The ancient Chinese also employed automation for entertainment at various points in their history, also primarily in mechanical theater.

The Ancient Chinese and the Ancient Greeks were both aware of the natural phenomenon of the Camera Obscura, an important observation which would later lead to more advanced cameras and understanding of optics, both technologies that would later see use in games.

The philosopher Thales of Miletus, one of the seven sages of Greece, was among the first to document electromagnetic phenomenon.

The mathematic concepts, especially those relating to geometry, pioneered by the Greek philosopher Euclid of Alexandria would later be commonly used by game developers. The Greek Philosopher Plato described how triangles could be used to represent 3D shapes, a mathematic concept fundamental to computer 3D graphics, especially by the real time graphics used in video games.

Age of Enlightenment & The First Industrial Revolution
While Video Games are often seen as a relatively new medium, many foundational technologies for gaming were developed just decades or a century or two prior to the development of video games, which is a very short period of time in most historical fields.

The Mechanical Turk of the 1770s showed a desire by people to play games with a machine, though in truth the machine was operated like a puppet by a human hidden beneath the playtable.

From the 1830's to her early death, Augusta Ada King, Countess of Lovelace (Known popularly as simply Ada Lovelace), a skilled mathematician who studied under Augustus De Morgan himself, becomes arguably the first programmer, having written a complex program for the analytical engine designed by Charles Babbage which incorporated now common hallmarks of programming, including nested loops, bugs, debugging techniques, and variables. In addition to her mathematical work, Ada Lovelace received musical training, and it was she who first wrote of using computers to generate music programmatically - A topic of specific importance to the history of video games. Further attempted developments of the machine by Babbage were almost certainly hindered when Ada Lovelace was afflicted by illness, eventually dying young as a result.

Recorded Audio
In the 1877 Thomas Edison would invent the Phonograph, enabling the accurate recording of audio to be played back at a later date.

The War of Currents
During the 1880's the war of the currents highly influenced electric standards. The resulting AC standards would influence television standard refresh rates, and in turn influence standard video game refresh rates.

For more information on the War of the Currents, one can consult the Wikibook Nikola Tesla, though bear in mind this important figure was only a one part of the event.

Joysticks
Depending on the source, Joysticks were either invented during the American Civil War between 1861 and 1865 for use in submarines at the earliest, or invented in 1923 by C. B. Mirick while working for the US Naval Research Laboratory at the latest. Their use as a control scheme for specialized vehicles made them a natural choice for early game systems.

Arcades
Racing Games as an arcade genre date back to as early as 1912.

Broadcast Standards, and all that Jazz
The earlier War of Currents would influence broadcast standards for television, which would influence what frame rates, resolutions, and other standards used by computers and game consoles. Though standardization greatly improved compatibility between devices from different companies, a number of incompatible standards arose across the globe. This lead to massive variations and incompatibilities early on in gaming history, as systems had to be designed for NTSC, PAL, or SECAM depending on their geographic region, and often had to be designed to take a specific voltage and frequency of AC, which alternated between countries. As time went on, digital standards made these early television standards mostly irrelevant, and the introduction of better power supplies which could handle nearly any AC power standard used across the globe also reduced such concerns dramatically.

Other Innovations
After early developments in the 1930's, printed circuit boards see widespread use in World War II munitions. These boards aid standardization, and help pave the way for mass production of consumer electronics.

The Information Age
Though gaming as a medium is proceeded by its foundational technologies, most of these technologies continued to experience significant improvements alongside gaming technology. This means that every decade since the inception of video gaming as a medium, the core technologies supporting gaming have also improved substantially, making the relationship between the two in significant flux.

The nearly concurrent rise of computer industry with the video game industry directly lead to improvements and innovations in both industries. The Wikibook History of Computers covers the general history of computers in more detail. This section discusses these innovations as they relate to gaming.

Transistors, Integrated Circuits, and the Microprocessor
The miniaturization and resulting ability to mass produce advanced yet relatively cheap electronics was a key moment in this history of all consumer electronics applications, but especially video games. There would likely be no significant market for a room sized gaming device which cost exorbitant sums of money every minute to operate and regularly required downtime for vacuum tubes to be replaced by skilled technicians.

In his 1945 article As We May Think for The Atlantic Dr. Vannevar Bush proposes Memex, a concept which would evolve into hypertext, paving the way to the World Wide Web, and by extension, games on the web.

Video Game Era
This section covers common recurring trends seen in technology use and adoption in video game history.

General hardware
In the late 1980's to the early 2000's a trend emerged where marketers would promote their systems by the bit size used by the internal computers of their devices. In general, there is a sliver of truth that larger bit sizes did aid development. However bit size alone has little to do with anything gaming related, especially after 32-bit processors became commonly used. Other factors, such as improved clock speeds, instructions per clock, internal architecture improvements, and perhaps most importantly, dedicated chips for applications such as graphics and audio, are much more responsible for the increased performance seen as time went on. Increased storage capacities of media also helped developers focus more on improving the game, and less on optimizing for hardware.

Hardware paradigms
In a generation there is typically a wide spectrum of power available on individual systems. Most systems fall into a sort of Goldilocks area where they are powerful enough for games of the time, but cheap enough to be viable on the market. However there are a few commonly seen strategies which buck this trend.

A common alternative strategy is to use cheaper underpowered hardware, and hope that the resulting high marketshare from a lower price attracts developers to a platform anyway. Skilled developers can often make up for hardware which is only moderately underpowered, but if the hardware is too underpowered, it creates a sort of chicken and egg problem where consumers don't want even cheap hardware because it lacks compelling games, and third party developers aren't interested in such hardware because it lacks marketshare and is difficult to develop for. An example of this model is the Watara Supervision, which undercut the popular GameBoy on price, but was unable to attract a marketshare with its poor game library.

The inverse strategy, using much more expensive overpowered hardware, is also commonly seen. Modest cases of this are especially true for major game consoles at launch, which often require a razor blade model where the console itself is sold at a loss, and profit is instead made on game sales. However some systems take this model to an extreme, finding a small market niche by offering unparalleled experiences at an unparalleled price. A good example of this strategy is the Neo Geo home console, which was essentially identical to the arcade systems made by SNK at the time.

Especially early on, some companies employed engineers with such skill they were able to do much more than their competitors for much less. A notable example of this is the Apple II home computer, which Steve Wozniak was able to add color capability to using clever tricks while keeping costs much lower than other competing color computers. This relatively cheap home computer with great potential for gaming in color took the market by storm as a result. As time went on, such massive leaps became rarer, but there were some companies which were able to use their massive manufacturing capabilities from other markets to undercut gaming companies by making things in house and eliminating third party middlemen.

Occasionally a device manufacturer attempts a completely different paradigm, often by introducing a new user interface technology, to attract consumers.

Developer Friendliness
Another commonly overlooked technological aspect which has improved with time is developer friendliness. As time has gone on systems have generally gotten easier to develop for, allowing developers to use high level programming languages, standardized APIs, and later standardized game engines to more easily target multiple systems in a generation.

A key point to note is that underpowered systems with well understood architectures tend to not be too impactful on developers, who will often be able to make a game appropriate for the hardware. However a number of systems have released historically with strange technological decisions which theoretically offer much greater performance than other hardware of the time. In these cases developers, especially third party studios, often struggle to actually take advantage of this poorly understood hardware and the benefit is often reduced, lost entirely, or even backfires with implementations that run worse than on much weaker systems. This lessons over time given widespread adoption.

As an example of this phenomenon, many software developers in the 1990's had trouble leveraging systems with multiple CPUs. By the late 2010's utilization of multi-core CPUs was much better. This is aided by improvements in the hardware itself, such as designing CPUs with multiple cores instead of putting two independent CPUs on the same board, as well as software improvements such as game engines supporting multiple threads by default.


text:
Understanding Air Safety in the Jet Age/Hanging on by the Fingertips - British Airways Flight 5390

When British Airways Flight 5390 took off from Birmingham Airport for the short hop to Málaga nobody could have predicted the dramatic events that would follow 15 minutes later. Extraordinary airmanship and courage from the crew would return the BAC One-Eleven, registration GBJRT, to the ground with no loss of life. The captain was 42-year-old Tim Lancaster, who had logged 11,050 flight hours, including 1,075 hours on the BAC One-eleven; the copilot was 39-year-old Alastair Atchison, with 7,500 flight hours, with 1,100 of them on the BAC One-eleven. Atchison would need every hour of that experience to save the 81 passengers and four cabin crew.

After a routine take-off at 08:20, the plane climbed out of Birmingham. With everything normal, both pilots released their shoulder harnesses and Captain Lancaster loosened his lap belt. By 08:33 the plane had climbed through about 17,300 ft and was passing over Oxfordshire. The cabin crew began preparing the meal service. Checking in with the flight crew, Air Steward Nigel Ogden had just entered the cockpit when there was a loud bang as the left windscreen panel, in front of Captain Lancaster, exploded outwards, decompressing the plane and filling the cabin with condensation. With his seat belt loose, Lancaster was propelled out of his seat by the rushing air from the decompression and forced head first out of the flight deck. His knees were caught on the flight controls and his upper torso remained outside the aircraft, exposed to extreme wind and cold. To make matters worse, the autopilot disengaged, causing the plane to descend rapidly. The decompression had also blown the flight deck door onto the control console, blocking the throttle control and causing the aircraft to gain speed as it descended. Adding to the confusion, papers and debris blew into the flight deck from the passenger cabin. Reacting with astonishing speed, Ogden grabbed Lancaster's belt, preventing him from being dragged out of the plane - something that would have both killed the captain and imperilled the plane if his body had impacted the wings or engines. Meanwhile the other two air stewards secured loose objects, reassured passengers, and instructed them to adopt brace position] in anticipation of an emergency landing.

Atchison had taken control immediately after the decompression and continued the emergency descent to reach an altitude with sufficient air pressure. Once low enough, he re-engaged the autopilot and broadcast a distress call, requesting clearance for an immediate approach to the nearest airport, but he was unable to hear the response from air traffic control because of wind noise; the difficulty in establishing two-way communication led to a delay in initiation of emergency procedures.

Ogden was still holding on to Lancaster, but was reaching the limit of his endurance and was developing frostbite. Chief steward John Heward and air steward Simon Rogers took over the task of holding on to the captain. By this time Lancaster had shifted several inches farther outside and his head was repeatedly striking the side of the fuselage. The crew believed him to be dead, but Atchison told the others to continue holding onto him, out of fear that letting go of him might cause him to strike the left wing, engine, or horizontal stabiliser, potentially damaging it.

Eventually, Atchison was able to hear the clearance from air traffic control to make an emergency landing at Southampton Airport. The air stewards managed to free Lancaster's ankles from the flight controls while still keeping hold of him. At 08:55, the aircraft landed at Southampton and the passengers disembarked using boarding steps. Miraculously, Lancaster survived with relatively minor injuries: frostbite, bruising, shock, and fractures to his right arm, left thumb and right wrist. Later Atchison and cabin crew members Susan Gibbins and Nigel Ogden were awarded the Queen's Commendation for Valuable Service in the Air for their actions.

Police found the windscreen panel and many of the 90 bolts securing it near Cholsey, Oxfordshire. Investigators found that when the windscreen was installed 27 hours before the flight, 84 of the bolts used were too small in diameter and the remaining six were the correct diameter but too short. How had such an error occurred? The previous windscreen had also been fitted using incorrect bolts, which were replaced by the shift maintenance manager on a like-for-like basis without reference to maintenance documentation, as the plane was due to depart shortly. The undersized bolts were unable to withstand the air pressure difference between the cabin and the outside atmosphere during flight. The final report was particularly telling. Not only had the shift maintenance manager responsible for installing the incorrect bolts failed to follow British Airways policies but he had not been wearing his normal spectacles, which impacted his ability to read the documentation. The policies compounded the problem by not requiring supervision or checking of work. Without extraordinary luck, and incredible airmanship, 87 people could have lost their lives due to a failure to wear glasses.