text:
Programming Languages/Semantics Specification

The Semantics of Programming Languages
Semantics, roughly, are meanings given for groups of symbols: ab+c, "ab"+"c", mult(5,4).

For example, to express the syntax of adding 5 with 4, we can say: Put a "+" sign in between the 5 and 4, yielding " ". However, we must also define the semantics of 5+4. If we use arithmetic semantics, 5+4 would be a representation/equivalent(=) of 9.

In computer science, the author of a programming language 'could' either use or create a new definition for '+'. For example, '+' can defined as arithmetic subtraction(-). More commonly however, '+' is defined as a function(takes in a value to output another) for complex numbers, and even strings(an ordered set of symbols) like "123a","aFsd", and "./etc".

Semantics are far from being mere theory or philosophy. Many properties of programming languages can only be determined through rigorous analysis. For example, we'd like to make statements such as "this programming language is secure." But to demonstrate that a programming language is secure requires more than just a discussion of the language's syntax. Without a formal proof of security, systems can be vulnerable to the unanticipated consequences of many separate interacting concerns. One way to make such proofs is by using mathematical models.

Given the semantics of one programming language we have the option of describing other programming languages in terms of that base language. So, one way to specify the semantics of a programming language is to relate it to another language. However, this creates a bootstrapping problem: what to use for the original base language. Programming language researchers have solved the problem by using a mathematical model that was originally invented for logic, but has extensive computational applications: Lambda Calculus.

Lambda Calculus, invented in the 1920s and 30s by Church, Kleene, and others, is one of the simplest to describe Turing Complete languages. It's a language that only has a single value: the function; and only two operations: defining a function and calling a function. To make things even simpler, functions are only allowed to have one parameter.

In the following discussion, gear your mind to thinking about functions that take functions as arguments and return other functions as values. It is a very abstract concept, but, as we'll find, soon we can build up the language through clever definitions into something that looks more like the programming languages we are used to. For example, one of the first tricks we'll explore is how to achieve the same result of allowing multiple parameters even though each function can only take a single parameter.

Building Up Operations
Before we start working with lambda calculus, let's begin with a puzzle in a more standard programming language. Suppose that Java only had the binary "<" operator, and we needed to define functions to give us ">", ">=", and "<=" operators. We also don't have unary operators either, but we still have if-statements.

First, let's look at what we're given:

// < - Returns true if a is less than b public static boolean lessThan(int a, int b) { ... }

Our task is to define greaterThan, greaterThanOrEqualTo, and lessThanOrEqualTo. Remember, for this puzzle, we can only make calls to lessThan, use if-statements, and return boolean values. Think of how you might do this before reading on.

The fist function is not too complicated:

// > - Returns true if a is greater than b public static boolean greaterThan(int a, int b) { return lessThan(b, a); }

This works because whenever we have $$b < a$$ we already know that $$a > b$$. We can use similar reasoning to write implementations for greaterThanOrEqualTo and lessThanOrEqualTo:

// >= - Returns true if a is greater than or equal to b public static boolean greaterThanOrEqualTo(int a, int b) { return not(lessThan(a, b)); } // <= - Returns true if a is less than or equal to b public static boolean lessThanOrEqualTo(int a, int b) { return greaterThanOrEqualTo(b, a); } // ! - Returns the negation of b public static boolean not(boolean b) { if (b) return false; else return true; }

In the definition of greaterThanOrEqualTo we are in effect negating the result of lessThan. Thus, when $$a \not < b$$ we return true, and when $$a < b$$ we return false. But when $$a \not < b$$ we know that $$a\ge b$$; this is a case where we must return true, and we do. Similarly, when $$a < b$$ we know is cannot be the case that $$a\ge b$$, so we correctly return false.

Given these definitions, we can define equalTo and notEqualTo:

// == - Returns true if a equals b public static boolean equalTo(int a, int b) { if (greaterThanOrEqualTo(a, b)) return greaterThanOrEqualTo(b, a); else return false; } // != - Returns true if a does not equal b public static boolean notEqualTo(int a, int b) { return not(equalTo(a, b)); }

We are now starting to think in ways that will let us build up operations in lambda calculus. Not only will we have to invent < and ==, we'll also need to invent numbers, booleans, all operations on numbers, all relational operations, linked-lists, if expressions, looping constructs and even a model for output and other side effects.

The Built-in Operations of Lambda Calculus
Here is the grammar of the complete lambda calculus language:

expr ::= "λ" id "." expr        abstraction, anonymous function definition expr ::= expr expr              application, calling a function expr ::= id                     variable use expr ::= "(" expr ")"           grouping

We'll also introduce another notation to allow us to create short-hands:

definition ::= "let" id "=" expr

After such a "let" is made, the identifier should be expanded to be the expression on the right-hand side. We'll also include another form of parenthesis, which are no different than the curved parenthesis already defined:

expr ::= "[" expr "]"

Because the language doesn't have much punctuation lots of parenthesis are going to be used, so by allowing two different types of parenthesis readability is improved (because you can better visually match where a grouping starts and ends).

Finally, identifiers can be any sequence of characters provided they aren't already tokens that mean something else:

id ::= $$\langle$$any printable, non-whitespace characters except []=.;, "let", and "λ"$$\rangle$$

So, unlike most programming languages, in lambda calculus "0", "+", "%" and "15" are all valid identifiers, just as "i", "x", "y1", "remainder" and "theReturnValue" are all identifiers in more common programming languages.

We will use ";" for line comments.

Abstraction: Defining a Function
We'll begin specifying lambda calculus rules by comparison to a hypothetical Java-like language. The abstraction rule, expr ::= "λ" id "." expr allows us to create new functions. The lambda "λ" symbol marks a new function is being defined, and the identifier that follows it is the name of its parameter. The expression after the dot "." is an expression that may refer to the parameter and any other variables in scope. Note that the functions do not have names in lambda calculus. If we want to name them we'll need to use the "let" form to just create a short-hand.

It seems that we can't define much of anything at all so far. The first function that might occur to you is the identity function: λx. x That is, for any x you supply this function, you'll get x back. Instead of constantly writing  each time we want to use the identity function, we can create a short-hand let identity = λx. x and then refer to  instead, which would be the same as referring to the syntactically heavier.

In Java, the same definition would look more like this: public static Function identity(Function x) { return x; } Because the only values or types in lambda calculus are functions, both the argument and the return value are of a hypothetical "Function" type.

Application: Calling a Function
The application rule expr ::= expr expr allows us to apply (or to "call") functions. Suppose that "f" were a function and "a" was its argument. To apply f to a, we simply juxtapose them together: f a Because parenthesis just provide groupings, and because f and a are already terminal elements, all of the following are equivalent to the above: f(a) (f a) ((f) a) ((f) (a)) (f)a Supposing that f was an instance of Function in our hypothetical Java-like language. We might write function application like this: f.apply(a) which would mean "apply f to a."

The β-reduction
The actual semantics of application is the substitution rule (also called the β-reduction rule). When f is a lambda function and a is some value, and they are juxtaposed, an application occurs. Suppose that fs parameter were named x and some expression expr used x. Then f a would be the same as (λx. expr) a An application states to replace all occurences of x with a. We would write this substitution as: expr [a/x]

Given our identity function from before, we can apply it to elements. So, identity a is the same as (λx. x) a which is the same as x [a/x] which, after the substitution becomes a Also, identity identity this is the same as saying: (λx. x) (λx. x) which is the same as x [(λx. x)/x] which, after the substitution becomes (λx. x) or, that is to say, the identity function itself.

Precedence order

 * Left to right

Multiple Arguments and Lexical Scope
Currently it doesn't seem like lambda calculus can do much more than create the identity function and apply it to itself. In order get further in the language, we need to start thinking of the abstraction operation as a true operation in its own right. For example, instead of defining the identity function, let's define a function that creates the identity function: λy. λx. x Which should be interpreted as "given any y, return the identity function".

Previously in our lambda function bodies, we've only returned the parameter. The above example shows that we also have another choice: return the parameter of a function we're defined in. For example, what would the following mean? λy. λx. y This function should be interpreted as "given any y, returns a function that, given any x, always returns y." In other words, it creates a constant function, which we represent in mathematics as a horizontal line on a graph. (The identity function on a graph would instead be a line at a 45 degree angle, running through the origin.) This section shows how this new option can allow you to express rich concepts. In particular, this section shows how you can simulate functions that take multiple arguments.

One way you might think of simulating functions that take multiple arguments by starting from functions that only take a single argument is to combine all of the arguments into a unit (just as a complex number contains two floating-point numbers) and passing that unit. Such a technique can be described as a tuple technique: as long as you can pass an argument that is actually a collection of multiple values it's really no different than passing in those multiple values in the first place.

You could use the tuple technique, but lambda calculus doesn't have any tuple types in it: The only type is a function that takes in a single argument. But recall the two functions above, that use  and. Because the function  function creates the   function the   function can use either of   and.

One way to think of the problem is to focus on a particular example. So, suppose you want to define a new function that takes in arguments,  , and   and does some computation involving those values. You can think of this function as a machine. The limitation is that in lambda calculus these machines can only take in a single value. But there aren't any strict limitations on what can be returned. So, think first about a machine that can only take in : because it doesn't know   or   it can't do the desired computation. But because it knows, it can return a new machine that also knows. Because that machine also takes in a parameter, we can let that be. Thus, you now have a machine that knows  and , but not. So, this machine should in turn create a machine that know  and   and takes in a parameter. Once that machine is given  it will be able to compute with all three values.

To make this concept clearer, suppose you want to create a machine that can do addition. That is, some kind of function that might read as, "given any n and m, returns the sum of n + m." We can achieve such an effect if we create a more primitive function first: create-adder. We won't yet implement create-adder, but we'll assume it exists with a specification like this: ; create-adder: given n, returns a function that adds n to its argument let create-adder = λn. (details left out for the moment) Assuming create-adder exists, it's trivial to define addition: let + = λn.λm. ((create-adder n) m) First, don't let the "+" trip you up. That's just a symbol like any other identifier. We could have just as well made the short-hand for this function be "plus" or "add" instead of "+". So, what is the "+" function itself?

The way to read "+" is: "given any n, return a function that, given any m, returns n + m." Assuming that 5 and 4 are defined to be values (we'll show how we can do this soon), "+" can be used to add them: ((+ 5) 4) Here, first "+" is applied to 5, and that result is applied to 4. Because at a high-level "+" is thought of as taking two arguments, it can be easier to understand if we remove some of the parenthesis: (+ 5 4) which still means the same thing: apply "+" to 5, and then apply that result to 4 (and would still mean that in this case if we remove all of the parenthesis). This way of calling the function is also the same as a prefix notation.

But how exactly does the "+" function return "n + m"? The body is this: ((create-adder n) m) Here, create-adder is passed n. By definition, it will return a function that, given any number, will return the sum of n plus that number. We then immediately apply that function to m, resulting in the sum of n + m.

This trick is known as Currying and is how we'll accomplish multiple arguments, even though the language itself only technically allows single argument functions.

Creating Richer Functions
Now that we can see some way to add multiple arguments to a language where functions only take a single argument we can explore other extensions. In order to create more programming constructs we'll not only need to make control-flow statements, we'll also need to make new values.

The only values we've fully constructed have been: (1) the identity function; (2) a function that returns the identity function; and (3) a function that returns a constant function.

Boolean Values and Conditionals
The first values we'll create are the booleans  and. We could start by just defining  to be the identity function and then letting   be the function that returns the identity function, but then we might find it hard to make these definitions be useful.

Instead, we should ask first, before defining  and , What do we want to do with   and   supposing that we had them?

One desirable property is that we could perform an  somehow. We could think of  as a three-argument function, that takes a boolean value, a "then" value, and then an "else" value: if cond A B Note that if is not a keyword, it is just symbols we're using. We want to define it such that when "cond" is  if cond A B reduces to A and when "cond" is   then if cond A B reduces to B

To get to this point, we can just think of  as a function that has two parameters, a t parameter and an f parameter, and returns t: let true = λt. λf. t

And we can think of  as a function that has two parameters, a t parameter and an f parameter, and returns f: let false = λt. λf. f

Given that, it's simple to define : let if = λcond. λA. λB. cond A B

Here, the boolean itself (named ) is doing all of the heavy lifting: The boolean is passed both A and B. If the boolean is true, it should return A, and if the boolean is false, it should return B. Given our careful definitions of   and   this is what will happen.

[TODO: Revise this: For the moment, we should assume some form of lazy evaluation so that the then and else values don't both get evaluated (which could cause an infinite loop)]

Logical Operations
Now that we have suitable definitions for true and false, and even an if construct, we can define other boolean operations quite simply. This recalls the previous exercise we did in Java with lessThan and the other relational functions:

not: logical not operation of a boolean value let not = λb. if b    false true You may have noticed by now that the "if" is not actually needed, because we could have cut it out and passed the values on directly to the boolean: let not = λb. b false true It just a matter of style that we use if, as a way to improve readability.

and: logical and of two booleans if b is true, it returns c, otherwise it returns false, thus, it only returns true when b and c are both true let and = λb. λc. if b    c     false

or: logical or operation: returns false only when both b and c are false let or = λb. λc. if b    true c

xor: logical exclusive-or operation: returns true when b and c are different, false otherwise let xor = λb. λc. if b    (not c)     c

bool-eq: boolean equality: returns true if b has the same value as c let bool-eq = λb. λc. if b    c     (not c)

note that beq could also be written as not (xor b c)

Integers
Church numbers -- For all n>=0: The n'th Church number takes in a "zero" value z and applies a given "successor" function s to that zero value n times. In algebraic terms, 0 = z (i.e., no applications of s to z are made) and 1 = s(z), 2 = s(s(z)), 3 = s(s(s(z))), ... and so on let 0 = λs. λz. z let 1 = λs. λz. s z

successor function: apply the successor to the given numeral one more time let succ = λn. λs. λz. s (n s z)

is-zero?: return true if the number passed in equals zero. This is accomplished by having the zero function be "true" and the successor function be a function that always returns "false". Thus, true will only be the result when the successor is applied zero times. let is-zero? = λn. n (λx. false) true

a cute version that uses Currying is: { n (and false) true } which might be easier to understand addition: returns the sum of n and m let + = λn. λm. n succ m

[TODO: I've also seen this longer form and I'm not sure why it's used:] let + = λs. λz. m s (n s z)

multiplication: returns the product of n and m, done by applying the "add n to yourself" operation m times to 0. let * = λn. λm. m (+ n) 0

natural number exponentiation: raise n to the m power let pow = λn. λm. m (* n) 1

Lists
subtraction is trickier, so we need to define pairs first let pair = λfirst. λsecond. λbool. bool first second

extract first element of a pair let first = λpair. pair true

extract second element of a pair let second = λpair. pair false

cons, car, cdr: to think of pairs as lists instead let cons = pair let car = first let cdr = second

Subtraction
now, back to subtraction: the key idea is to start with an operation that takes in a pair of numbers (a, b) and returns (a+1, a) let next-pair = λp. pair (succ (first p)) (first p)

now notice that if we start with (0, 0) as a zero, and next-pair as the successor function, applying the successor function n-times yields the following:

times applied  value of pair   value of pair in terms of n -   -   --- n =        0   (0, 0)          (n, n) n =         1   (1, 0)          (n, n - 1) n =        2   (2, 1)          (n, n - 1) n =        3   (3, 2)          (n, n - 1) n =        4   (4, 3)          (n, n - 1)

Note, then, that (n next-pair (pair 0 0)) yields the pair (n, n - 1) for n >= 1, and (0, 0) for n = 0. If we want the predecessor of n to be n - 1 for n >= 1, and 0 for n = 0, we just need to take the second element of this pair! That's exactly how we implement predecessor: let pred = λn. second (n next-pair (pair 0 0))

subtraction: return $$n - m$$; but if that value would be negative, 0 is returned instead let - = λn. λm. m pred n

Relational Operations and Division
now that we have subtraction, we can compare numbers:

is n greater than or equal to m? let >= = λn. λm. is-zero? (- m n)

is n less than or equal to m? let <= = λn. λm. >= m n

is n less than m? let < = λn. λm. not (>= n m)

is n greater than m? let > = λn. λm. not (>= m n)

equal: are n and m equal numbers? let equal = λn. λm. and (>= n m) (>= m n)

not-equal: are n and m different numbers? let not-equal = λn. λm. not (equal n m)

div: given a numerator n and a denominator d, returns the quotient let / = λn. λd. (if (< n d)     0          ; -- (n < d)      (if (equal n d)         1          ; -- (n == d) ; subtract d from n until the value is < d -- (n > d) (n          [λn'.             (if (< n' d)                n'                (- n' d))] n)))

mod: given a numerator n and a denominator d, returns the remainder let mod = λn. λd. (- n (* (/ n d) d))

The Y-combinator
the fixed-point Y-combinator (call-by-value), for implementing recursion let fix = λf. [λx. f (λy. x x y)] [λx. f (λy. x x y)]

Y: alias for fix let Y = fix

Lambda Calculus Extended with Primitives
[TODO: Discuss this extension. Typically by extending lambda calculus we make models of programming language. An example is Feather-weight Java, which was used to prove that Java was a secure language (in theory; the model did not take into account implementations, which may have bugs that result in security holes).]


text:
Programming Languages/Functional Languages

Functional Programming Languages
The idea of declarative programming is to define rules for the working of the environment and then to let the language figure everything else out. This contrasts with procedural languages where one tells a machine exactly what to do. Functional programming can be one of the ways to achieve a declarative programming style. The classic example is a factorial function. The first step in defining a new function is to handle the trivial cases first. Factorial of 0, then, would be defined as 1. The next step is to define non-trivial cases in a way such that they will eventually resolve to the simple cases. Factorial of n, then, would be defined as n multiplied by the Factorial of one less than n:

fac 0 = 1

fac n = (fac (n-1)) * n

A naive implementation like this uses more memory and processing time than a 'for' loop (it uses O(n) stack space), but this can be fixed with a simple change, using an accumulator parameter to enable the compiler or interpreter to eliminate the function-call cost:

facb 0 acc = acc

facb n acc = facb (n-1) (n*acc)

fac n = facb n 1

Functional programming has great uses. One might use a functional language as a prototype of code --it is in many cases easier to write functional code and prove that it will generate the desired result than with procedural languages-- and then optimize it by using procedural techniques. Functional techniques can be very efficient at traversing binary trees.

 * TODO: Just describe how popular functional languages differ from lambda calculus, importantly side-effects (but mention Haskell)
 * Scheme and ML both have built in types, like integers, floats, lists and string
 * Scheme has tail-call optimization
 * Scheme has multiple argument functions instead of currying
 * Scheme uses the functional notation for all constructs, requires the parentheses
 * Scheme has hygenic macros
 * ML is statically typed with inference
 * ML has pattern matching constructs
 * ML has only single argument functions, but simulates multiple arguments both with currying and with tuples
 * ML uses the lambda calculus notation for function calls (i.e, no parentheses needed), but uses keywords for built in constructs (i.e. it does not use the functional notation for if)

Because lambda keeps references to the variables referenced in the outscope, yet these functions can be stored and called when the calling function has long returned, languages that use lambda have garbage collection. Functional programming a subset of declarative programming that focuses on writing “pure functions” The functional programming paradigm was explicitly created to support a pure functional approach to problem solving. Functional programming is a form of declarative programming. In contrast, most mainstream languages, including object-oriented programming (OOP) languages such as C#, Visual Basic, C++, and Java, were designed to primarily support imperative (procedural) programming In computer science, functional programming is a programming paradigm—a style of building the structure and elements of computer programs—that treats computation as the evaluation of mathematical functions and avoids changing-state and mutable data. It is a declarative programming paradigm, which means programming is done with expressions or declarations instead of statements. In functional code, the output value of a function depends only on the arguments that are passed to the function, so calling a function f twice with the same value for an argument x produces the same result f(x) each time; this is in contrast to procedures depending on a local or global state, which may produce different results at different times when called with the same arguments but a different program state. Eliminating side effects, i.e., changes in state that do not depend on the function inputs, can make it much easier to understand and predict the behavior of a program, which is one of the key motivations for the development of functional programming.

Combinatory logic is an equivalent theoretical foundation, developed by Moses Schönfinkel and Haskell Curry. It was originally developed to achieve a clearer approach to the foundations of mathematics. Combinatory logic is commonly perceived as more abstract than lambda and preceded it in invention.

 * Lexical versus dynamic scope

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


text:
Programming Languages/Imperative Languages

Imperative Languages

 * Some common examples : C, Algol family of languages, Pascal.
 * More on "Imperative programming": in wikibooks and in wikipedia.


text:
Programming Languages/Object-oriented Languages

Object-Oriented Languages

 * Smalltalk has closures, based on Lisp and Simula67. Squeak is the modern implementation
 * Modern OOPLs are Java, C# (both inspired by C++), Dylan (inspired by CLOS), and Python (inspired by Smalltalk).
 * Ruby more than Python is an example of a modern OOPL, also Squeak.

 * Some common examples : Smalltalk, Java, C#, Ruby

Hybrid languages allow object oriented and classic programming. Examples of such languages are Ada, OO-COBOL and C++. (Object Oriented Paradigms) Object-oriented methods are design and programming techniques that use the concept of class and object. Object-oriented real programming is based on identifying categories that represent organisms with well-defined characteristics and function. Object-oriented models include three main principles: Encapsulation. Data Hiding. Inheritance. (Polymorphism). Applications based on object-oriented methods and computer programs that consist of layers with their interactions: There are many and modern programming languages that support object-oriented methods, the most important of which is Java language where it is fully supported Languages that support object-oriented programming typically use inheritance for code reuse and extensibility in the form of either classes or prototypes. Those that use classes support two main concepts: Classes – the definitions for the data format and available procedures for a given type or class of object; may also contain data and procedures (known as class methods) themselves, i.e. classes contain the data members and member functions Objects – instances of classes Objects sometimes correspond to things found in the real world. For example, a graphics program may have objects such as "circle", "square", "menu". An online shopping system might have objects such as "shopping cart", "customer", and "product". Sometimes objects represent more abstract entities, like an object that represents an open file, or an object that provides the service of translating measurements from U.S. customary to metric


text:
Programming Languages/Scripting Languages

Scripting Languages
These languages are oriented toward single tasks of limited complexity, varying natures, perhaps spanning across networked systems. Scripting languages are chiefly evolved toward the goal of increasing programmer productivity, which can often mean sacrificing efficiency and elegance (because scripts might only be run a couple of times anyway, or only periodically and for short amounts of time). For example, many tedious tasks can be automated, freeing the programmer to do more creative activities. The 'Scripting' derives from the everday occupation of UNIX (and other) system administrators who write adhoc scripts to perform various tasks such as report generation, file copy and installation across a network etc. These scripts vary from a loose collection of commands listed in sequence in a batch file to full programs in scripting languages like Perl.

Shell scripting may be considered as the first programming activity in this genre leading to dedicated languages embodying these principles. Scripting languages typically have simplified but powerful file-handling constructs, regular expression constructs, associative arrays and other data structures built in.

Python, Perl, TCL, Ruby, PHP, JavaScript


text:
Programming Languages/Logical Languages

Logical Languages
Logic programming languages such as Prolog state and query relations. The specifics of how these queries are answered is up to the implementation and its theorem prover, but typically take the form of some sort of unification.

title: Programming Languages/Logical Languages


text:
Programming Languages/Aspect-oriented Languages

Aspect-Oriented Languages
[TODO: talk about AspectJ]

 * More on "Aspect-Oriented programming" : in wikibooks and in wikipedia.


text:
Programming Languages/Domain-specific Languages

Domain-Specific Languages
[TODO: Talk about SQL, Lex, Yacc, and answer why these languages are so commonly used, even though general purpose languages can do the same.]


text:
Talk:Japanese

Wow. This is a mess
No offense to those involved but this book is a total mess. Any one think I would be distracting from this book too much if I started a new book? More along the "quick and dirty" learning thing. This book seems like if it is ever pulled together (its pretty scattered right now) it will be super intensive and scary for learners who just want the basics so they can communicate. Thoughts? Nesnad (talk) 16:20, 9 December 2007 (UTC)
 * I agree. The chapters on the contents page are all over the place, and it would be very hard for a beginner to find their way around the book. In my opinion, it requires a major overhaul. Helpfulstuffnz (talk) 05:01, 23 December 2007 (UTC)

 * Ditto! But I'm not sure where you were going with your overhaul, Helpfulstffnz.
 * What's the difference between a "basic" and a "starter" lessons?
 * I think we should move away from the numbering of lessons, and towards naming them according to contents. An electronic book doesn't suffer the same limitations as normal books. Pages can be interelinked and content accessed in a non-linear fashion. That isn't to say that we can't have a linear structure, but naming pages "Lesson 1" is, I think, of little use and possibly a hindrance to its development.
 * While the current state seems to be partly due to people trying to fix this book by restructurning, but not following through, I'm going to suggest we do just that once more.
 * How are these for ideas to simplify the process and reduce the risk of pitfalls:
 * Start the new book at Japanese, moving the current content to Japanese/Cover.
 * Use Japanese/Contents as a scratch-pad to list all of the material available (and boy, there's a lot).
 * --Swift (talk) 05:05, 10 June 2008 (UTC)

I'm tired of people revising this book. I think it's been revised over four times already. Everyone sees that it should be different in someway, and they totally revamp the page for a few days, and then stop. The latest person to start restructuring this book won't be the last.

As for removing linearity, this is rather pointless. Unless the desire is to make this a phrasebook, it's difficult to teach a language or learn a language without building on subject points that you've learned from prior lessons. Removing "Lesson 1" and keeping "Aisatsu. (Greetings)" doesn't make a difference to the development. The hindrance is the flow of "Lesson 1" to "Lesson #" from Starter to Advanced. I've been meaning to change this format to "Lesson 1" to "Lesson N" for each section rather than across the board. A book discussing the language in any detail would need linearity so that each chapter/lesson/whatever is a building block to the next lesson.

If there's going to be multiple sections, there needs to be a complete lesson plan for each section. If this is to turn into a Japanese phrasebook as some people have suggested, the title should be changed as such, or a bookshelf should be made like the English bookshelf. The fact that there's no lesson plans remains a problem. I suppose the JLPT could be used as a guide.

As for the meaning of the different sections, I believe the "Starter" section was used as a phrasebook. It's probably meant for tourists to get around slightly in Japan with minimal understanding of the language. I understood Basic as Japanese 101 - or for people who are really interested in learning Japanese on their own. I didn't like the previous suggested syllabus for Basic, so I started to make a new one, which can be seen here - User:Retropunk/Japanese_Cirriculum. Whether another approach is decided, I really don't mind. I rather not see this book changed into YAPB (yet another phrasebook). --Retropunk (talk) 06:37, 10 June 2008 (UTC)

 * I believe that, to really be useful for people with little experience learning languages, the lessons should follow a "bite-sized" approach. This means basically:

 * 1) grammar sections mustn't be longer than 1/2 of a page; only one point of grammar per lesson
 * 2) no more than 15 new words per lesson
 * 3) most vocabulary for beginner lessons must be taken from among the 500 most common words and none from beyond the 1000 most common words
 * 4) no vocabulary that is introduced through dialogs or exercises without being taught in the vocabulary list
 * 5) there may be an optional vocabulary section with words that will interest only part of the students, for example country names and professions
 * 6) plenty of exercises, remember that people can always skip them if they are comfortable with the material already, but they can't invent new exercises if they are still confused

 * It is possible to create easy lessons without following these rules, but for people not used to writing lessons they are a very good guideline. Also, the European Reference Framework for Languages may be a very good tool in defining Beginner, Intermediate, Advanced series and so on, as it clearly states what students should know and should be able to do after completing each level towards fluency. Most language tests in Europe are based on this framework now.

 * Just my two cents. Junesun (talk) 07:25, 10 June 2008 (UTC)

 * I agree with your points, Junesun. Short and concise, they should maybe be a start replace the overly long Japanese/Contributor's Guide. Maybe you could have a look and suggest something on the talk page.
 * The CEFR you mentioned might be a good tool. We could consider creating categories to reflect these. Alternatively we could try to use some sort of JLPT sorting system. --Swift (talk) 08:22, 10 June 2008 (UTC)

 * I feel your pain. The current situation we're faced with is that the project is in disarray and goes nowhere with it's sudden bursts of activity followed by periods of inactivity. Starting anew or going with the old won't fix anything since, as you said: "Everyone sees that it should be different in someway" and each revamp creates a whole new set of redundant material. One of the ways we can reduce the damage is by modularising the book and making it easy for new editors to add their content without having to reinvent the wheel.

 * Moving away from the "Lesson n" convention will allow users to order existing material in their own way. Yes, users will need some sort of path to trac, but that path doesn't need numerical naming as one moves from one to the other using hyperlinks, not modifying the URL.
 * Several users, including yourself, have come up with their take on restructuring pages (e.g. Balloonguy, Telamon, Helpfulstuffnz, Mkn and Retropunk). Balloonguy and Helpfulstuffnz seem to have tried to link to existing pages and make some sense of them. I think that in similar vein we can create parallel versions of structuring the contents.
 * While not necessarily useful for users and certainly not a goal in itself, I think it's good for the future of this book, allowing people to draw on existing material rather than having to recreate it. Until we have enough contributors agreeing on a common vision, we need a way to turn these scattered contributions into a synergic collaboration.

 * Certainly not all content can be used in parallel, but things like introductions and pages on specific grammatical points can be shared. The main problem (and point of proliferation) seems to be on the conversational part where each editor has their own view of what is a useful approach. I think it's fine to let users add their own flair on this, but simplifying the process of peiecing other modules into their book will benefit everyone.
 * Currently there is no path or curriculum — only bits and pieces of past attempts. The future of this book is rather bleak if we continue on this practice of rebuilding things from the ground up. I see it as a much better approach to start from what we have, make all of it accessible (yes, all of it, even the crappy stuff) and foster rewrites and contributions that don't follow a rigid curriculum.
 * I'm not advocating the abolition of structure or curricula. I'm arguing for making them optional; a support rather than a shackle. --Swift (talk) 08:22, 10 June 2008 (UTC)

 * So, you're wanting link to all different grammar points that have some relevance?

 * For example, わたしはロバートです.

 * Have grammar points going to the copula, the pronoun, and the topic marker? Did you plan on doing this like a glossary, or did you plan to link to another lesson? It may be because it's getting a little late that I don't fully understand, or I may just need to see your concept on here to fully understand.

 * I'm not sure if I agree with Junesun's ideas. One grammar point per lesson? Talk about a lot 'lessons' that can be generated with that.  And such a small vocabulary?  I believe the average student learning Japanese will learn around 800-1500 for their "Elementary" course.   They also learn around 300 Kanji.  Yay for polite and plain versions.  As for the other points, I totally agree with them.  Retropunk (talk) 09:12, 10 June 2008 (UTC)

 * I wasn't quite thinking of quite such aggressive interlinking. In fact, I didn't plan on doing much at all as far as specific lesson structure goes. I was more interested in detaching things in a manner that would make it easier for individual editors to locate material they are interested in.
 * I'm playing around on the Japanese/Contents page, listing many of the pages that comprise this book (though not part of the previous contents page having been deprecated through previous revolutions). I'm interested in collecting similar pages together to see what we have available. Rather than hiding lessons like "hiragana" inside a series of "lesson n" I'd like to have a collection of
 * Japanese/Pronunciation
 * Japanese/Introduction/Reading Japanese
 * Japanese/Lessons/Lesson 6 — Hiragana Lessons
 * Japanese/Kana Chart
 * Japanese/Japanese writing system
 * Japanese/Reading Hiragana
 * Japanese/Kana
 * for users and editors to choose from and modify as they see fit; refactoring content to reduce redundancy and increase reusability through modularisation. This is, of course, more difficult to achieve with conversation lessons (and grammar to a lesser extent) but these will already have fewer contributors and thus isn't as serious an issue.

 * So, how does one take these small bits and turn them into a book? Firstly, I don't think we have to string every page here into a single linear narrative. We can create seperate such paths, each with it's own topic.
 * Secondly, we can have parallel narratives that share content. I really like the Japanese/Practical Lessons but that page has been dead since September 2006. The kana lessons it links to are however much older, have more development and aren't subject to that any particular lesson plan.

 * I understand you may seriously dislike my proposition since in a way it brings us further from a single Japanese book. While I too would like there to grow a good book out of this, I'm more interested in making this as useful a resource as possible. So far, all attempts to build something on the ruins have failed and unless we see a fundamental change, no book will grow out of this mess while it's being driven by individuals who only survive a little while before burning out. Let's break this up and let the pieces fight for popularity. Let's collect the usable pieces from the rubble and create a little market for users to easily identify pages of interest and contribute where they can.
 * With incremental improvements we can renovate the dingy shacks and identify the redundancy in function. While this will not yield a consistent plan, any attempt to start with the plan and build from there has failed. Let's toss the plan, build up the bits and string them together later.

 * Once we have a better base to build on, we can merge these and concentrate on fuller narratives. As a first step I think we should find the pages that we can share, make them easy to find and then allow users to develop their own linking system through them. If we can foster collaboration even while there is respectful disagreement in how to best chain these pages toghther, we can move away from chaos to create a more accessible resource.

 * In conclusion, I really appreciate your comments and hope you'll give this suggestion critical consideration. I don't propose that I've thought every angle through, but think this is a strategy we can use to build something on. --Swift (talk) 10:51, 10 June 2008 (UTC)

 * One of the things I'd like to do is collect the various closely related or redundant pages together so as to not toss out the hard work or previous editors. Continuing with my example above with the various hiragana pages, there are a couple that are very similar, but still have lived parallel lives. I don't see that there is any need for this redundancy. If there is, both pages would benefit from seeing the others' perspective.
 * Japanese/Grammar Lessons/Chapter 0/Hiragana group ka
 * Japanese/Kana/Lessons/Hiragana/Lesson 2
 * At Japanese/Contents I've gathered a few pages that touch on the matters regarding the structure or contents of lessons. Some of these present a lesson plan while others are more collections themselves.
 * I found Japanese/Reference closely relates to what I've ended up using on Japanese/Contents. I suggest that we use something similar to categorise the available content. One thing that is missing from that page and constitutes much of the available content is a category with conversations introducing vocabulary and illustrating grammar.
 * I think the next step is to go through these, check redundancies and identify incompatible but intelligent approaches. From there we can start construct lesson bundles. --Swift (talk) 17:55, 10 June 2008 (UTC)

：May want to invite a few others. As you have noticed, people normally stay around a few weeks and jump ship, but maybe some people still linger around. Retropunk (talk) 09:27, 10 June 2008 (UTC)

 * Who might? I? Invite to this discussion?
 * I left messages on User talk:Retropunk, User talk:Balloonguy, User talk:Helpfulstuffnz, User talk:Nesnad and User talk:Kadamczy. Do you have anyone else in mind? --Swift (talk) 10:51, 10 June 2008 (UTC)

 * Add anyone who modified the pages in the last couple months, User talk:WongFei, User talk:Cysaki, User talk:Luis Sergio Moura are a few more that may be interested. You could also try the Yahoo group, but it's been rather dead.  76.22.11.133 (talk) 13:50, 10 June 2008 (UTC)

 * Done. Also: User:Shinjitsu, User:Ian78, User:Ikarsik, User:Zoey473 and User:Hayson1991. --Swift (talk) 15:07, 10 June 2008 (UTC)

 * Thanks for telling me about this, I'm still just a novice learning Japanese, so if you want to use me as a guinea pig to see how i think learning this would be I'm fine for that, or if you need me to do research about how the language is in current use, different definitions about how it works, or stuff in general thats just looking stuff up and finding the information I'm good, just send a message about when we'll start doing things, or if like I said, you need me to see how learnable the page is just send a message or a link of some sort Cysaki (talk) 01:46, 11 June 2008 (UTC)

 * Thanks also for telling me about this. Just to make sure I understand correctly, are you proposing to create self-contained modules so that readers can follow their own learning path, similar to the wikiversity Web design learning projects, or are you proposing to modularize the content to clean up the book so that it is easier to continue forward and create a unified book?--Balloonguy (talk) 20:34, 11 June 2008 (UTC)

 * I'm suggesting the latter: modularising so that current and future editors can more easily build upon existing material.
 * The "learning path" idea is very interesting, though. Furthermore, we should perhaps be looking to integrate better with Japanese. Some of the lessons have excercises with answers. Perhaps these belong on Wikiversity? --Swift (talk) 02:27, 12 June 2008 (UTC)

I think a language wikibook should start by teaching the reader the alphabet, grammar, then vocabulary, then lastly by example. The way this book works, it's very confusing. The reader does not even understand how the は particle works and is told to read わたしはロバートです... With no sense of which part of the sentence is which, the reader would be very confused. -- H  A YSON1991  15:06, 12 June 2008 (UTC)

How much to teach (was: what a mess...)
As the discussion goes into many directions right now, let's make a separate discussion point for this. I still believe that 15 new words and one grammar point covering no more than half the page should be the guideline. Yes this will translate into a lot of lessons: assuming 500 words for the elementary course (not counting optional ones), this means 33 lessons for the elementary level, 25 at the very least. However, I believe it will translate into a much better course:
 * you have a much better idea of how much to teach per lesson - unlike other courses, you won't wind up having taught all the elementary grammar after 10 lessons and still be 400 words behind on the vocabulary target
 * plenty of opportunity to include exposure to the Japanese language (comparatively more texts/dialogs per taught item) and exercises
 * each lesson will correspond to two or three hours of study, not 40 like some textbooks assume
 * teachers can complete lessons faster and there will hardly be any half-finished material lying around
 * students can complete lessons faster and won't have to keep coming back to the same lesson over and over again, as high school classes do; moving on quickly is motivating and it's better in that each session will leave students with whole knowledge, nothing half-explained half-understood; whole knowledge will not be forgotten as easily

As for burnout among lesson writers: I believe this can be prevented if this is a community effort with several people working together and commending each other. For this, a lesson plan would be a good idea, so that several people can work at the same time and there is more overview of what was/is to be taught when. Otherwise I guess the development would have to be linear, everybody waiting till the previous lesson is finished to see what and how much is covered. Of course the whole idea of a community effort relies on people agreeing on a common methodology, target audience and goal for the lessons.

Junesun (talk) 14:43, 10 June 2008 (UTC)

 * I really don't have a problem with making one grammar point per lesson. However, I think it should probably be decided on the target audience before we have vocabulary restrictions.  If it's decided to make a bookshelf, then I can go with the 400 words.  Just for future reference, the JLPT Guide has over 600 words for JLPT4 (or basic Japanese.)  Most JLPT guides will suggest learning around 800 for JLPT4.  Retropunk (talk) 06:13, 11 June 2008 (UTC)

 * I guess that small lessons won't be such a hurdle. One can, after all simply go through them faster if one wants. Smaller "lessons" would also be simpler to build (especially collaboratively). --Swift (talk) 16:43, 12 June 2008 (UTC)

 * I added the beginning of a curriculum to User:Retropunk/Japanese_Cirriculum as he seemed to have left space for me there ;) Let me know what you think. Junesun (talk) 09:41, 2 August 2008 (UTC)

Categorisation
Thanks, Retropunk, for finishing the sorting. The list of pages we started with were, however, taken from |Category:Japanese not Special:AllPages/Japanese which was a mistake on my part. Sorry. We may be missing some pages. I would suggest just re-doing it, but don't want to piss anyone off. I guess this is good enough.

Anyway, how best to treat these. I've come up with a categorisation scheme with four overlapping categories (or topics) and three "stand-alone" ones.

Overlapping categories Each of these overlaps with their neighbour. While kana is under "Reading and Writing", kanji and reading practice falls under both "Reading and Writing" and "Vocabulary". Vocabulary and phrases will always touch on one another as will phrases and grammar.
 * Reading & Writing
 * Vocabulary
 * Phrases
 * Grammar

How to present these overlapping categories, I don't quite know.

Stand-alone categories
 * Introductions
 * Linguistics
 * Dialects

Links A notable absence is: I don't think we should have a page with links. I don't think many ever go to a links page until they have exhausted themselves searching a site. We should aid the user by linking to external resources at the point where they would normally go to find these.Anki is flash-card software that can help you memorise kani For example, rather than collecting software and links at Japanese/Software and Japanese/Internet Links we should link to these at points of interest. Kanji flash-card software in the Kanji part and online texts in the reading practice. This can be done either in sections at the bottom of a page, or in special external-link/further information boxes.
 * Links and resources

Lessons The lessons would be kept seperate from this scheme since they will often cover all of it in a single lesson. Over time, the lessons will hopefully build on these and take the front stage, possibly pushing these categories out of sight.

As for sorting the lessons out in order to get an overview of what we have. I think we should rather sort them by level and style than by how much work has been put into them.

 * Reading practice shouldn't really be tagged under vocabulary. While you may learn vocabulary while reading, the focus of a reading practice is not vocabulary, but language comprehension.  The current reading practice need to have them overhauled.  Removing the vocabulary sections and having just a translated section.  I don't see how Kanji can be seen as reading practice.  While two pieces of Kanji can be made to a different word, it's still vocabulary.  In the Kanji pages, we can state the meaning of each Kanji or word (since Kanji and Kana can make up a word.)
 * Points of interests for the links sounds like a good idea.
 * The current categorization of the lessons is not my intended end result. I did not know what to do with a majority of them, and since they encompassed way too much, I just threw them under stages of development.  We may need to wait for others to join (if any more do so), and see if they agree with Junesun's idea.  I suggest learning more vocabulary than she suggested, but if the majority of people would like to see less, I'm willing to do that.  --Retropunk (talk) 11:27, 12 June 2008 (UTC)

 * I put "reading practice" under "Vocabulary" because for comprehending the text one needs not only to be able to read it, but also the vocabulary to understand it. I have a feeling that we may simply understand what constitutes reading/writing differently and a semantic debate is maybe not the best use of our time.
 * Kanji, however, is still under the overlap. I guess we could put it under "Vocabulary" for simplicity (where it belongs far better than "Reading/Writing").
 * Lesson categorisation: I wasn't sure how to sort them either (which is why I left them 'till last). I'd say we should just leave them be in one long list and let people deal with them as they please. Maybe we could string them together into versions (like the "Konnichiwa" lessons etc.). Each one could be a lesson plan on its own. Contributors can then compare and choose which they like best and contribute there, getting ideas from the other. Possibly even merging content where possible. Different learning paths could then start sharing pages and eventually merge if viable.
 * Wikiversity: Again, I do think we need to think about how to interface with Wikiversity. It sounds really tempting to just settle for small booklets that are strung together into a course on Wikiversity. Tempting because it seems so much more do-able than to create comprehensive wikibooks on this topic. However, keeping everything here at Wikibooks might make more sense in order to better mold the content to the lesson arch. --Swift (talk) 15:15, 12 June 2008 (UTC)

Templates

 * I've just deprecated this. It's basically a shorthand for two but saves only one or two keystrokes keystrokes and has no benefits when being displayed. --Swift (talk) 20:09, 23 February 2010 (UTC)

Levels
I was reorganising the lessons according to levels. I made "Introduction" for elementary stuff like reading and pronunciation (stuff you sort of have to learn before diving into anything juicy), and then "Beginner" and "Intermediate. I wasn't quite sure where to place the boundary between the last two. Maybe once students are able to engage in a short original conversation? Maybe we need finer levels.

Anyone care to offer their suggestions? --Swift (talk) 00:46, 2 July 2008 (UTC)
 * From the previous attempt to overhaul this book, the group came up with [[Japanese/Practical Lessons/Syllabus|

this syllabus]]. It is pretty comprehensive. --Balloonguy (talk) 20:01, 2 July 2008 (UTC)

 * Thanks. Looking at it, it seems that most are taking the same approach. I sorted the Structure/Lesson Plans/Syllabus section a bit, leaving only the really useful pages, moving the others into the lesson sections. If we can now merge these or choose one and toss the others, we're well on our way. --Swift (talk) 03:07, 4 July 2008 (UTC)

 * I believe using JLPT as a guide would be a good idea. Here's an extensive guide  using the JLPT Test Content Specification book as a source.  The grammar, vocabulary, and kanji competency may be integrated into any conversation difficulty you wish to pick (e.g., short concise sentences to long narratives.)  So, JLPT 1 - Beginner, JLPT 2 - Intermediate, JLPT 3 - Advanced, JLPT 4 - Near-Native.   Japanese/Practical Lessons/Syllabus is a good starting point, but it really needs a grammar point list, which I think the JLPT would suffice.  --Retropunk (talk) 08:32, 4 July 2008 (UTC)

 * more inspiration for grammar points
 * http://www.e-japanese.jp/grammar.htm
 * http://www.csse.monash.edu.au/~jwb/j_gram_summ.html
 * http://www.guidetojapanese.org/
 * http://kimallen.sheepdogdesign.net/Japanese/
 * http://www.jgram.org/
 * http://maktos.tripod.com/jip.html
 * http://mercury.ecis.nagoya-u.ac.jp/WebCMJ/contents.htm --Retropunk (talk) 08:54, 4 July 2008 (UTC)

Vocabulary
As I was looking through the list on Japanese/Vocabulary I found pages that are just that: pure vocabulary list. The problem with those list, such as Japanese/Vocabulary/Government and Politics, is that they are competing with the category list formed by wiktionary's Category:ja:*Topics, and in the case of the example above, ja:Government. So should they be deleted?--Balloonguy (talk) 22:03, 4 July 2008 (UTC)

 * Duplicating in some ways, but maybe not really competing. The Wiktionary lists seem to be listed according to their Japanese entries. wikt:Category:ja:Colors is a good example. There, the novice will have a hard time looking up the words he's interested in. I think these two can co-exist; the categories on Wiktionary for grouping Wiktionary entries (and for populating lists here on Wikibooks), and the Wikibooks Vocabulary lists as (possibly trimmed) English indexed references for language learners. Cross-linking would be highly useful. --Swift (talk) 00:20, 5 July 2008 (UTC)

 * The categories on wikt are good for Japanese->English if you already know the category. They're not good for English->Japanese.  However, unlike the Japanese portion, there are no English categories to the granularity as the Japanese words.  There may be another way of connecting the two lists, but I currently do not know of any.  --Retropunk (talk) 03:50, 5 July 2008 (UTC)

 * Precisely. Since we don't really need much more than lists of terms, indexed by English, to help students of the Japanese language build up their vocabulary and look up terms to practice their phrases and grammar points, I think we should make do with linking the Japanese words in the vocabulary lists to their entries in the English Wiktionary. It would also be helpful to link from topic pages in the vocabulary section to their relevant categories to make it easer for editors to repopulate the vocabulary lists and get an overview of what terms are available on Wiktionary. --Swift (talk) 13:24, 5 July 2008 (UTC)

I split up the "Date and time" on the Vocab list to Horary Time and Days. However I'm wondering if the list should be merged together as one large list or kept as I have them now. Let me know what you think.--Retropunk (talk) 08:43, 13 July 2008 (UTC)

 * I think it could be useful to keep these separate. They are different enough and I think short vocabulary pages are better. We can add relevant-pages links to these for cross-reference.
 * Minor detail suggestion: How about calling stuff like Japanese/Vocabulary/Numbers/Time (Horary Time) simply "Time" while Japanese/Vocabulary/Days could be "Date". I think that's close to the colloquial meaning as few really think of days, months and years as time except in a very abstract sense. --Swift (talk) 19:12, 13 July 2008 (UTC)

I believe I have all most of the vocabulary completely moved to the template format. Thank god for regex editors. The pages still need to be cleaned of translation errors, misplaced text, and deprecated text and the alike. We may also want to merge some things. While I guess we could add superfluous text like the Japanese/Vocabulary/Banking on the Chemistry and Biology pages, I don't see the point. Be it as it may, we could always split them again if they get too gaudy. --Retropunk (talk) 04:59, 16 July 2008 (UTC)

Interlinking
I made Template:Japanese related vocabulary and added it to a few pages (Japanese/Vocabulary/Biology, Japanese/Vocabulary/Chemistry, Japanese/Vocabulary/Animals, Japanese/Vocabulary/Sushi, Japanese/Vocabulary/Food and Drink). It's a rather ugly template, but what do you think about this approach? --Swift (talk) 04:15, 3 August 2008 (UTC)
 * Adding vocabulary sections of interest seems okay to me, but be careful with entering the template to the pages. Some pages have TOCs, so if you're not careful, you'll have vocabulary above the TOC.   Entering  before the vocabulary should fix it, or you can make the vocabulary a section.  An example of this is on the Japanese/Vocabulary/Dates page, which I just pushed the vocabulary down a level.  Retropunk (talk) 21:15, 3 August 2008 (UTC)

 * Actually, I did that on purpose. I don't think it's necessary to have the TOC on top of everything. Not that there is any need to have a list of terms above it, either. --Swift (talk) 00:55, 4 August 2008 (UTC)

 * has now been deprecated in favour of . --Swift (talk) 04:10, 12 April 2009 (UTC)

Broken sound files
There seem to be two main authors to the commons:Category:Japanese pronunciation sound files on Commons; commons:Special:Contributions/Marsian and commons:Special:Contributions/Spacecat2. When I play the Spacecat2 files, the beginning seems to be cut off. Can anyone confirm this? --Swift (talk) 03:42, 1 October 2008 (UTC)
 * I would be wary of the Spacecat2 sound files. I was going to use his files, but they screamed copyright infringement to me.  --Retropunk (talk) 06:14, 1 October 2008 (UTC)

 * What gives you that impression? Spacecat2's uplaods seem to have two voices, one male and the other female. They're about the same age so it seems likely that they are by a couple that has added voice recordings to articles they felt would benefit from them.
 * Do these play OK on your computer? I don't find these as high a quality as Marsian's, but we have to work with what we have. If the files are corrupt, however, then we should consider deleting them. --Swift (talk) 13:09, 1 October 2008 (UTC)

 * They sound fine on my computer. Make sure you have a player that handles OGG files, or they may sound garbled/cut-off.    I'll see if I can get anyone on Lang-8.com to produce a wav, or some other sound file, for us.--Retropunk (talk) 05:04, 7 October 2008 (UTC)

 * You'll find that both users whose contributions I linked to upload OGG files. Sorry to be a bother, but just to make sure that we're on the same page: Do these files, for example, sound OK, or are they cut off at the beginning?
 * The sound of "ら"/"ラ": [[Image:Ja-Ra.oga]]
 * Nikon: [[Image:Ja-Nikon.oga]]
 * I've only played the files with mplayer (using the FFmpeg/libavcodec audio decoder) but since Marsian's files play fine, suspected that this might be a problem with the files, rather than my player. Suspicion is a far cry from certainty, and thus I brought it here. --Swift (talk) 16:07, 7 October 2008 (UTC)

 * I used mplayerc, and it did cut it off. When I used winamp and Cortado (Java) with Firefox, they sounded fine.--Retropunk (talk) 05:49, 8 October 2008 (UTC)

Grammar List Points
I've started a list of grammar points for JLPT4. This are by no means a progressive list. This would need to be addressed at a later time, but I'm just taking talking points and putting them in a list such that we can really start a syllabus/lesson plan. There will be some things that absolutely need to go first before others (copula, topic/subject markers, question markers before adjectives, conjuctions), and this would probably need to be more collaborative than a single person. I'll probably move the points to separate pages, but for now you can review it at User:Retropunk/Japanese_Curriculum. Please put any suggestions on the talk page. If you see a mistake, fee free to modify it. --Retropunk (talk) 21:52, 19 October 2008 (UTC)
 * I think I'm done with this list. It's still not progressive to be used as a syllabus.  The list is derived from the Test Specifications for the JLPT test.  As we clean up the actual page, we should look to see how we would like to make a syllabus, or if we should even bother (i.e., we could use a group of topic points and let contributors use those, or we use a strict step-by-step syllabus.)
 * The group of topic points would allow extreme flexibility, but if other information is dependent on the topic point (e.g., you need to know desu, topic particle and such), this group of information or points may not have been covered yet. There is also a problem with no continuity.  However, there could be links for each topic point to multiple lessons.  People can pick a point they're interested in, and find multiple lessons/entries on it.  It's easy for contributors to add topics.
 * If we go with a strict syllabus, we're forced to decide what information should go before other information. This can be a tough task and is very subjective.  It can be difficult for users to add topics as they need to incorporate whatever amount of topics into one lesson.  However, there's a defined progression list.  People can skip a portion of the list if they're not interested.  Nothing is really forcing contributors to follow a list as they can just go to another lesson, and they could just do a portion of the lesson if defined well enough.
 * Let me know what you think. If you know pros, cons for either side.. There may even be a solution where we can use both.  Let's discuss them. --Retropunk (talk) 17:43, 30 October 2008 (UTC)

 * I like the idea of mainaining this list with links to relevant lessons. This also allow for multiple, parallel learning paths. It would, furthermore be a great resource for reworking existing material (if one were to link to these as well.
 * Also; how about moving this to the existing JLPT Guide? It could be a very useful addition to that poor book. --Swift (talk) 12:11, 16 November 2008 (UTC)

Main page colour scheme
As Retropunk has tactfully touched on, the colour scheme on the Japanese page is dreadful. I've never been terribly good at coming up with these. Anyone have any ideas to make this somewhat more aesthetically pleasing? --Swift (talk) 16:35, 17 November 2008 (UTC)

 * I've done a bit of work on this and am fairly happy with the result. Comments and critisism welcomed. --Swift (talk) 15:43, 2 December 2008 (UTC)

 * I think the new color scheme is much better. -- Retropunk (talk) 07:21, 10 December 2008 (UTC)

Categorising grammar points

 * This was brought up in a topic that is now discussed on User Talk:Retropunk/Japanese_Curriculum/Outline. Since it is relevant not only to the outline itself, I'm adding this here. I apologise for any confusion.

I'm not sure how best to implement these — or even whether to do so at all. If we are to go down that road we could set up a hierarchy of categories. They would all have to have the akward "Japanese_" prefix as not to impose on other book categories, but that's mostly an aestethic rather than a functional hurdle. Pages could then be placed in the categories relevant to the grammar points they contain. That way users can look up other lessons that also cover those points.

I'm not sure it would be a good idea to set up this hierarchy before writing the lessons. I'd advocate an ad hoc approach where we use cateogries to connect the material we have as it gets added.

Another way is to just interlink those lessons directly. This requires some more work since that method links pages directly to one another. On the other hand these links can be made more prominent by placing it in a nice box to the side, given annotation and one could select the most useful pages to save readers having to go down dead ends. --Swift (talk) 04:28, 18 November 2008 (UTC)

Whether a progressive verb category gets made first and the lessons last, or a lesson with a progressive verb gets generated and the category afterwards, it doesn't matter to me. --Retropunk (talk) 09:19, 23 November 2008 (UTC)

Keep it up!
A corner of encouragement. Clearly this book isn't finished, but the contributors are already making it easier to "leaf" through. I think you're all wonderful. I am rooting for you. --74.130.244.188 (talk) 03:56, 19 November 2008 (UTC)

I wanted to encourage you guys, too! I've been looking over this for about a week and while it is disjointed, I think you all are doing a good job. This book is very helpful to use in addition to other self-learning guides. Castrophicus (talk)

 * Many thanks for your words of encouragement. Seeing people use this book helps to both motivate and help focus on the most useful areas. Even the random anonymous spelling correction is nice, but short notes like the above are great. Thanks for taking the time to write them. --Swift (talk) 02:34, 29 November 2008 (UTC)

Furigana template

The Ruby template at Wikipedia recommends that users use language specific versions in the case of Han characters due to differences in font rendering. I've created the furi template which also renders the fallback (in the case that a user agent might not render ruby) as a smaller character to better distinguish it from the main text.

Figuring that it's a stylistic nuance which people might want to comment on before moving to it, I thought I'd leave a mention here before switching from one to the other.

I think we should not simply redirect from ruby as it is still useful as a generic ruby template. --Swift (talk) 04:07, 5 December 2008 (UTC)

 * Okay, so instead of using the ruby template, we should use the furi template because the furi template addresses potential font display problems seen with ruby? I don't mind the changes. I don't use ruby on here as I thought the font was way too small. --Retropunk (talk) 23:42, 5 December 2008 (UTC)

 * Yes, that's right.
 * One of the reasons why I wanted to mention it is that the furi template fallback is parenthesised readings following the kanji, just like ruby. The former, however, has a smaller font than the latter. I figured this was OK since the kana are that much simpler than kanji that novices would need that much bigger kanji than kana. So, if they aren't able to read the kana, they can't read the kanji adequately, either. Do you have any suggestions for alternative solutions? How are you explaining the reading of kanji? --Swift (talk) 15:16, 6 December 2008 (UTC)

 * I haven't thought about explaining the readings for the kanji right now. I'm just not sure if this book needs furigana. There was a discussion about furigana in this book.. somewhere, and I believe there was some legitamite reasons to remove it. I'll see if I can find it. The only problem I can see with furigana is the ruby text can be too small for long readings. This is my only concern on it. -- Retropunk (talk) 07:19, 10 December 2008 (UTC)

 * The current version of Japanese/Lesson Relative Clauses shows two methods, one is the "ruby" furigana characters, while the other is to place the reading (and meaning) in tool tips which one can then reveal by hovering over the character(s) with the pointers. --Swift (talk) 17:40, 5 January 2009 (UTC)
 * ... and I've just added a screen-capture of that page as rendered by Opera with a user defined cascading style sheet. Unfortunately support for ruby characters doesn't seem to rank high on user agent developers' list of priorities, but these style sheets do a fair job. --Swift (talk) 09:42, 6 January 2009 (UTC)
 * Judging by the picture, this was my original complaint. The kana text is too small. To a novice, he wouldn't know if water is mizu or misu. I don't think there's a real solution to this problem. Even without the ruby text, it's still hard to read. Personally, I use rikiachan, but I don't know if it supports Opera... or any others. --Retropunk (talk) 06:43, 7 January 2009 (UTC)

 * I agree that the kana in that picture are too small. My argument for the furigana, however, is that so are the kanji. The person who cannot recognise the kana, can't recognise the kanji either. Normal font sizes are aimed at those who know the characters — not those who are seeing them for the first time. I was thinking about this and wondering whether we could fairly gracefully increase the font size of the Japanese, without incurring akward line spacing or comically large English text. I'm not sure about that...
 * One of the reasons that I like furigana is that it looks so good on paper. Then reading your comment above, I remembered: this isn't paper! I haven't tried the Rikaichan Firefox extension, but I'm not sure if we should require something like that since unfortunately it's browser specific. We could see if we can somehow create fall-backs for people with different setups. I'll install Rikaichan and try it out. --Swift (talk) 02:45, 10 January 2009 (UTC)
 * Not knowing the Kanji and not knowing the reading are two different problems. There are compound kanji and irregular readings for compound kanji, which can further complicate things. If the novice can read the individual kanji and understand its meaning, he can probably guess the compound kanji meaning - and MAYBE the reading. There will probably be problems with kanji, too... the really complex kanji, but I'm not sure if the same problem wouldn't exist without the furi.  Anyways, I don't know if there's any real solutions to this.  A person could always just remove the ruby/xhtml input if they wish, so I don't think it's hurting anything. --Retropunk (talk) 03:57, 10 January 2009 (UTC)

 * I never said that they were the same problem. I said that "[t]he person who cannot recognise the kana, can't recognise the kanji either." Note that I differentiate between reading and recognising. If a student's level is high enough that he/she can recognise the kanji at that font-size, then the student will easily recognise the smaller kana to see the reading. On the other hand, if the student can't recognise the small kana, then the slightly larger kanji are still too small to be of much use. What I'm hinting at is that the problem you identify applies not only to the kana, but to the kanji as well.
 * Still, I have yet to form an opinion as to what might be the best solution. I'm happy with using the furigana template for now. As you said: it can be hidden and it should be simple enough to convert the markup to most other solutions we might come up with. --Swift (talk) 02:38, 12 January 2009 (UTC)
 * You're misunderstanding the context of "reading". I meant the reading of the kanji (i.e., the kana).   A person with mediocre knowledge of kanji can probably see/recognize/know the kanji rendering is water, but may not know the reading is mizu - and when they try to read the kana, they can not because of the font-size and can not recognize the kana due to the rendering.  This will be very typical with people who know Chinese and people who know radicals or lots kanji, but not some compound kanji.
 * I just noticed that the non-ruby version is about the same size (if not the same font) for the kana. So, the problem still stands, and maybe even worse in printed form.  Electronic versions are different in the sense that you can have other sources (e.g., changing the default font size, dynamically changing font size (which I guess is possible on most)), but this may be problematic for some people.   Regardless, I think we've both see a problem in the font-size, and the only easy fix would be to either increase the font-size in the template (or page), remove the furi template, or put the burden on the reader to increase their font-size.   -- Retropunk (talk) 08:58, 12 January 2009 (UTC)

 * I understood what you meant about "reading". While your example of a person who reads kanji but not kana is a clear possibility, I think it is beside the point. Until someone suggests that we start expecting students to know kanji better than kana, the legibility of kanji is as much an issue as that of the kana. --Swift (talk) 09:53, 12 January 2009 (UTC)
 * No, it's a valid point.  I'm not sure why you continue to discount it.  In it's current state, the kana is so much smaller than normal that it's near illegible for some readers.  Removing the reduction in the size when someone does not have ruby html enabled is the best solution that I see.   In non-ruby html, the kanji is not affected.  Keeping the size restraint on kana in ruby-html is fine as it's just an option.  Forcing a person with the same size font, or any equally tiny font, in non-ruby html is ridiculous.  -- Retropunk (talk) 10:40, 12 January 2009 (UTC)

 * I continue to discount it because it is irrelevant. You say that "the kana is so much smaller than normal that it's near illegible for some readers." You don't need kanji proficient readers to make that point. In fact, you don't need anything to make that point since there hasn't been anyone to disagree with you on that. You may remember that I said earlier in this discussion that "I agree that the kana in that picture are too small." --Swift (talk) 13:38, 12 January 2009 (UTC)
 * I gave the kanji proficiency example because your statements that if a person can't recognize the kana, they can't recognize the kanji. I've stated many times that I don't care about the ruby-html because the user can just turn it off.  However, the user has little choice but to increase their font size to recognize the kana in the non-ruby html to read the reduced font size of the kana.  Anways, I'm done with this.  I've already stated the same thing three times in a row.  -- Retropunk (talk) 16:35, 12 January 2009 (UTC)
 * Good. Let's move on. --Swift (talk) 16:38, 12 January 2009 (UTC)

Review
Please review the following pages and give input on their talk pages. Please do not comment here, as I'll just move the comments to those pages.

User:Retropunk/Japanese_Curriculum/Outline
 * User:Retropunk/Japanese_Curriculum/Outline/Using_This_Book

User:Retropunk/Japanese_Curriculum/Outline/Beginner_Lessons
 * User:Retropunk/Japanese_Curriculum/Outline/Beginner_Lessons/Using_This_Level
 * User:Retropunk/Japanese_Curriculum/Outline/Beginner_Lessons/Lessons

-- Retropunk (talk) 07:06, 10 December 2008 (UTC)

Conversation template
I created Japanese Phrasebook conversation and think it could help with conversation formats. I reckon there shouldn't really be any difference between conversations in the Phrasebook and the Japanese book, in which case this would better belong at Japanese conversation and simply shared between the two books. Comments appreciated. --Swift (talk) 14:01, 2 January 2009 (UTC)

Under heavy reconstruction
when will the "heavy reconstruction" be done? I want to learn japanese! :D

77.127.54.121 (talk) 11:36, 13 January 2009 (UTC)

 * Not for a while, I'm afraid. Still, the current Japanese page has some content that you can use right away.
 * The Japanese/Contents page has more material, but most of it is incomplete and some pages are redundant. Feel free to browse around, though.
 * We're busy reworking these into useful pages that should slowly find their way onto the front page. Thanks for dropping by and good luck with your studies! --Swift (talk) 11:52, 13 January 2009 (UTC)

Japanese sentence patterns and examples
I just created the Japanese pattern and Japanese example templates to highlight these. Suggestions, comments and criticisms are welcome.

[ Edit: nowiki-ed this. I've changed this template to work differently. --Swift (talk) 03:39, 15 February 2009 (UTC) ]

There is much room for improvement on their look! Maybe a solid background is a bad idea. --Swift (talk) 06:56, 18 January 2009 (UTC)

 * I've added the Japanese example to Category:Japanese templates and Japanese/Contributor's Guide. Though it may not look so great right now, it is still a good idea and we might as well start using it right away. --Swift (talk) 16:16, 20 January 2009 (UTC)

 * I've been putting the patterns in a table. I might modify Japanese pattern to produce a table heading or style declaration. --Swift (talk) 10:54, 6 February 2009 (UTC)

Japanese todo
I recently created Japanese todo which places pages on which it is included in Category:Japanese todo. Please use it if you find it useful. --Swift (talk) 06:58, 18 January 2009 (UTC)
 * As part of normalizing category names, now /todo. --Pi zero (discuss • contribs) 14:04, 9 December 2016 (UTC)

Related content links
A while back I created the Japanese related vocabulary. As we're slowly moving towards lesson pages, I figured we might benefit from expanding the scope. I've modified the template and moved it to Japanese related. The new template takes two arguments. The first determines the box style. The latter is the same as before. See the template page for usage and examples. I haven't spent any time on picking nice colours yet. --Swift (talk) 10:51, 6 February 2009 (UTC)
 * I would use these sparingly on grammar pages to lesson pages. Linking directly to lessons, while a good idea, will be a maintenance nightmare.  I still contend that a categorization of the grammar content would be the best approach.   This way, the user can see all the lessons that are in that category and the contributor can just add the category link within the lesson.  Although, the grammar content link on the lesson page would not be that bad.  You can't really have a ton of links on a grammar page to lesson pages.  It would be nice to have people contributing to this book without someone putting a dozen or so links on the Verb page.
 * The categorization has its own evil side. The category will need to be made.  It'll have some nasty name like "Japanese_Grammar_Copula", the contributor needs to know about it (but this is not unique), and other things that I'm sure I'm forgetting.  I suppose we can look at this more another time.  -- Retropunk (talk) 17:05, 6 February 2009 (UTC)

Japanese verb style
I've just fixed the template and updated Japanese/Verb conjugation table to use it. My idea behind this was two-fold: To make it easier to navigate and update the verb conjugation table, and to be able to highlight verb forms in the text. This way, we can write:

These are then synchronised with the conjugation table. The latter motive was partly just a neat idea and I'm not sure how much use this could be. --Swift (talk) 09:06, 20 February 2009 (UTC)

Default font
My main browser displays Japanese by default with a "serif" font, as opposed to "gothic" (both of these terms used quite liberally as I've not found any better used for Japanese font-faces). Gothic fonts tend to be popular for computer use as some feel they render somewhat better on screen. The VL Gothic font is one example.

I've set up a copy of Japanese/Lessons/Introduction/Ogenki desu ka/Na-adjectives at User:Swift/Font test and (re-)raised the issue in the feature request reading room of adding book stylesheets. That way we could set the font book-wide. --Swift (talk) 06:41, 4 March 2009 (UTC)

Sugu ni Hajimemashō
I've been dabbling with the list of grammar points that Retropunk put together a while back. There now is a list of about sixty sizeable points that could make up the first step into Japanese. In contemplating where to place this, I first considered  but then figured it might become complicated if someone wanted to add lesson pages outside the scope of that plan.

So, I figured I'd just split these lessons out of the book. I've always considered it completely unnecessary (not to mention highly unoriginal) to name a book on Japanese simply 'Japanese', and harmful to construct too monolithic books. I've therefore placed the grammar point list at Sugu ni Hajimemashō where it can grow and prosper along side whatever other Japanese lesson plan may spring up; using content from Japanese as well having its own added. --Swift (talk) 23:12, 9 May 2010 (UTC)

 * I really don't mind the two books being split, but sooner or later, someone is going to discuss the likeness of the two books and suggest a merge. I suppose as long as everyone agrees that one book is more of a "grammar book" and another is more of a "progressive lesson book" then the two books should work well split up.

 * I was hoping to find a copyright-free book, but most of the Japanese books that are in this realm are way too old.  I've given up looking for one for quite some time, but I suppose I can start looking again.  I think splitting the ground work would be nice, and should start a book, but it's getting contributers to support the book.  Retropunk (talk) 18:46, 15 May 2010 (UTC)

TODO: Begin Writing Lessons
Hello, I am a student of Japanese, and would like to contribute the the wikibook. Specifically I would like to begin filling out some lessons. As the number one complaint of this wikibook seems to be "too many people with too many ideas," I wanted to get the blessing, so to speak, of someone who has been working on this project for awhile. My plan was to start at the begining and follow the lesson plans laid out at the lesson plan. Because there exists an extensive hiragana/katakana section already, I would probably begin with Dialog Lesson 1. Do you have any thoughts or suggestions? Is this lesson plan solid enough to build upon? Has this already been done and the convoluted nature of the book cause me to miss it? I have tried to read as much material on the wikibook as I could, but I am still digesting what exists.

Would it be best perhaps if I began fleshing out some other section? I have taken a look at the todo section, but am unsure what edits have priority. Elaeum (talk) 04:30, 15 June 2010 (UTC)

 * Hey Elaeum, Welcome to Wikibooks and nice to hear that you're interested in contributing to the Japanese wikibook. If you're interested in writing lessons, I suggest that you think about the scope of the content you'd like to cover and what approach to take. Then see if one of the lesson plans fits your approach and start work on it or create your own.
 * I personally think the Japanese/Practical Lessons lesson plan is a bit incomplete which is why I set up Sugu ni Hajimemasho. They also differ a good deal in content and organisation (SnH doesn't touch on reading and writing but concentrates on the grammar aspect).
 * If you have any other questions or would like feedback on your work, please let me know. --Swift (talk) 20:36, 18 June 2010 (UTC)

 * Hello Swift. I've been busy filling out lessons using the lesson plan, syllabus, Retropunk's grammar to be covered, and the JLPT4 Vocabulary List.  I've based the lessons around the format created by Retropunk.  They are on my user page.  If you take a look, please keep in mind that they are very rough yet, I laid down a very rough ordering to the grammar sections, and am filling them out to get a rough idea of how long they will be.  I'll post to the book when I have a better draft done, and after they've been checked by a few friends of mine.

 * Really, there's no order of precedence on the TODO list. Add what you want.  Fix what you want.  Add things to the TODO list.  Add things anywhere and put a new TODO list.  Doesn't matter.  If you want to add lessons, that's cool.  I'm not really contributing much, but I come around and check out the book every once in awhile.  Good luck, and thanks for contributing.    Retropunk (talk) 01:44, 8 July 2010 (UTC)

 * Thanks for replying. I've been building off the lessons that you created.  They're on my user page right now, and they'll probably stay there until after I get a chance to cement down some of the format.  Right now they could be considered a very rough draft, so that I can work on ordering, and sizing.  Take a look if you like.  I hope to have them brought to the book for group revisions in two or three weeks.  Hopefully someone will want to help me edit them... Elaeum (talk) 20:39, 9 July 2010 (UTC)

Book Title
This is really not an issue at the moment, (there seem to be much bigger things to concentrate on) but I agree with what Swift said about naming a Japanese lesson book "Japanese"  Somewhere down the road, after things have been fleshed out a bit, maybe new names could be proposed? This is a mainly a reminder note for the future. Elaeum (talk) 17:06, 15 June 2010 (UTC)

Pronunciation indication
I think some indication of pronunciation is required. This is usually done in dictionaries. 10:23, 23 December 2010 (UTC)

 * I suggest looking at the Japanese/Pronunciation page.  It's a good starting point.  Retropunk (discuss • contribs) 20:14, 11 September 2011 (UTC)

Japanese/Reader
It would be very useful if someone who was a native/high level in Japanese read over a few of these to check if they use modern Japanese. Also if they could check if it's easy to read, I can re-style them all if make some sort of official Manual of Style. Hethrir (discuss • contribs) 19:07, 18 October 2011 (UTC)

This is a good start!
It seems no one has been here in a while, so I am going to put in a little work..

I'll start putting together some draft lessons in keeping with the theme of the Spanish Wikibook.

It will hopefully read like a textbook a complete beginner would use, i.e. starting with no assumed knowledge. Any advice along the way will be greatly appreciated.

I'm new to Wikibooks, so be kind! :)

Ed345 (discuss • contribs) 01:31, 3 September 2012 (UTC)

Letter-Writing-Instructions Images
Why did you replaced the images which explains how to draw the letters with an animated version? It cannot be printed. The images are still exist and wasn't deleted. They're located at commons:Category:Bw.png stroke order images.

Here's a comparison of the differences between the versions:

Galzigler (discuss • contribs) 17:29, 31 January 2013 (UTC)

/Transcribing English to Japanese
This page was an orphaned transwiki in need of a good home. The best place I could find was this book so I've moved it and added it to the contents. It needs to be dewikied and formatted in the style of this book. If it is unwanted then please nominate it for deletion.--ЗAНИA talk 22:31, 21 March 2014 (UTC)

Topics for the appendix

 * Japanese writing system
 * Romanization of Japanese (including an explanation about Romanization)
 * Japanese language and computers (including Japanese input methods)
 * Horizontal and vertical writing in East Asian scripts
 * Japanese punctuation
 * Japanese script reform

These can be added as links to Wikipedia - downloading the book as PDF or ordering it from PediaPress should allow these pages to be added to the book. Galzigler (discuss • contribs) 17:09, 28 April 2014 (UTC)

Proposal for correction
Sorry for bad English. I read these pages and found some improvements. (Some of sentences are too difficult for beginners. so I didn't edit.) Please edit if you think it's necessary to modify--Мизхо ( abwp / ab-discuss /  jawp /  ja-discuss ) 16:39, 3 January 2019 (UTC)
 * Japanese Phrasebook/At the hotel
 * ひと晩いくらですか. → 一泊いくらですか.
 * In japan they don't say 一晩 but 一泊(いっぱく).
 * Japanese Phrasebook/At the bank
 * 交換( exchange the money) → 両替(りょうがえ)
 * 交換レート (exchange rate) → 為替(かわせ)レート
 * 両替 is better. ex.両替機 change machine. In japan they don't say 交換レート but 為替レート or レート.
 * Japanese Phrasebook/At office
 * 私は会社へ資料確認に帰ります → 私は会社へ資料の確認に戻ります
 * I thought 帰る can only say "return to home or the place you sleep". For other place 戻る is better. (but other japanese might say 帰る expression...)
 * Japanese Phrasebook/Conversation essentials
 * How tall are you? (身長はいくつですか？) ― I'm 180cm tall. ((私の身長は)180cmです. )
 * 私の身長は is option.
 * もう一度、お名前を…… → もう一度、お名前を伺ってよろしいでしょうか
 * 私は毎朝６時半ごろ起きて、シャワーを浴びて、朝ごはんを食べて、会社へ行きます. 私の会社は工場の会社で、＜どこ＞にあります. 家から会社まで２０分くらいかかります. 毎朝うちから会社まで自転車に乗ります. 仕事は８時から４時半までです. 土日は休みです.
 * →私は毎朝６時半ごろに起きて、シャワーを浴びて、朝ごはんを食べて、働きに出かけます. 私の職場は工場で、＜どこ＞にあります. 家から職場まで２０分くらいかかります. 毎朝うちから職場まで自転車に乗ります. 仕事は８時から４時半までです. 土日は休みです.
 * removed redundancy,重言. 職場⇔workplace
 * Japanese/Grammar/Comparisons
 * はい、寿司よりです. → はい、寿司よりもです.
 * I thought they don't abbreviate adjective in compartive sentence.

title: Talk:Japanese


text:
C++ Programming/All Chapters

= Appendix A: Internal References =
 * List of Keywords
 * [included next to The Compiler]

 * List of Standard Headers
 * [included in The preprocessor Chapter (next to the #include keyword)]

 * Table of Preprocessors
 * [included in The preprocessor Chapter]

 * Table of Operators
 * [included in the introduction to Operators]

 * Table of Data Types
 * [included in the introduction to Variables]

To prevent duplication of content references are removed you may find them on the given locations.

= Appendix B: External References =

title: C++ Programming/All Chapters


text:
Talk:Turkish/Pronunciation and Alphabet

Keep in mind that Turkish is mostly unaccented, except for a slight stress on the last syllable (in most cases). This can be a challenge for English speakers - we have a natural inclination to accent our words in the middle, the beginning, whatever. That's why when you're listening to a native Turkish speaker, it can sound like one long string of syllables. In Turkish, the words aren't broken up so strongly by accenting a part of them. Work hard on this "no stress" pronunciation. It's key to being intelligible to a person listening to your Turkish.

title: Talk:Turkish/Pronunciation and Alphabet


text:
Rueda de Casino/Para el Medio

There are two moves with this name, both danced at different times in the rueda. The first version listed here is at the start of the rueda, when the leaders are facing counter-clockwise. The second version is for the main part of the rueda, when the leaders are facing clockwise.

The call can be shortened slightly to pa' el medio.

From the starting position
Leaders face counter-clockwise, and followers face clockwise, one between each leader. Normal partner hold.

Everybody steps into the middle of the circle with the inside foot, and then closes the other foot to it. Then they step to the edge of the circle with the outside foot, and close the inside foot to it. This happens on beats 1, 3, 5 and 7, so it is slower than most moves.

The idea is to lean into the centre, and out of it, repeatedly. This usually continues until the group is formed and the caller has been decided upon. Also, it is usually not called out, as it is always the start of a rueda.

From the main rueda
Usually called as Enchufa y para el medio.

Enchufa y Dile que no, and then the leaders do mambo basics into and out of the circle, while the followers do the same, but the leaders go into the circle on 1, and the followers on 5. Usually everybody claps twice when they are stepping in.

Other moves from this position:

 * Treinta y tres (33)
 * Flor (flower)
 * Levántala (lift her)

title: Rueda de Casino/Para el Medio


text:
Arabic/Book/Authoring Rules

These are rules, subject to change, and capable of being broken.

 * 1) Teach mainly the Standard Arabic (often known as "fuS-Ha"). Parts explaining more local language should be distinct from the Standard. Links to pages about learning another dialect may be linked to the appropriate sections.
 * 2) Provide exercises for lessons. Provide keys (pages with the answers for the exercises).
 * 3) An Arabic word must be represented in Arabic Script.
 * 4) Transliteration should be provided, for the beginner levels (i.e. Most if not all levels).
 * 5) Phrases should have each word translated, along with the whole phrase translated. This will be explained in an article.
 * 6) Keep it simple. If you can teach it without using grammatical terms, do it. Grammatical terms should be included where they would be helpful, to experienced language learners, but the text must be understandable, that is, without the user needing to understand the grammatical terms.

title: Arabic/Book/Authoring Rules